Support Me on Patreon

Tuesday, December 31, 2019

Fragmented Post

I'll be posting on a few different subjects in this post, so scroll to the bolded area that interests you.


Game Optimizing Tip: Conga Loading

Adding and removing objects from a game can cause a bit of lag. This is evident when dealing with numerous objects that need to be loaded/unloaded. This is why I usually just move existing objects around, like raindrops or particle effects. The bigger problem comes from objects that have to be swapped out, like NPCs or monsters. You don't want enemies milling about hundreds of units away from the player, and capping the spawn rate makes this worse. Still, removing all those unrendered  monsters and adding fresh could cause a dip in frame rate. Why not deal with them singularly?

The idea is to connect signals between the monster and a router node. The router node can be anything, but it needs a script to handle signals and connecting them. Signal connection via script is a bit tricky, so I won't go over it here, but it is a great skill to learn.

When the monster/NPC need to be unloaded, or a node needs to load an entity, it first polls the router with a signal containing itself and a request for the action. The router then adds this node to a list of either incoming, or outgoing. While running, the router swaps between out or in (boolean value) every tenth or twentieth of a second. If there are nodes queried,  then a signal is sent allowing the node to either add something, or remove itself. This allows for a single-in single-out entity loading system, reducing load.

To do something every second, or second-fragment, use a delta timer. This is just a variable that has the delta, or frame time, added to it. Once it reaches a specific amount or greater, an if statement allows some code to be run and the timer variable is reset to 0.

Who Duolingo: Tips for Duolingo

I use the Duolingo app to learn Spanish. While it won't make you a pro, it will give you the skills to converse a bit in another language. Here are several tips and things I've noticed.

Start with small daily goals until you get used to the app. Daily goals can be changed in the app settings, usually a gear or those three dots. I started small and worked my way up to the highest amount.

Double mint lingots.With a few exceptions, you get lingots when you meet daily goals or complete a level. You can sometimes watch an ad to double those lingots. When on wi-fi, go ahead and double the lingots. On data I don't watch the ad unless I am doubling two or more lingots. Lingots are useful for doing tests, getting a few extras, and getting more lingots. If you have plus, lingots lose some of their value. I think you can also give lingots to others by upvoting their comments on a lesson (the speech bubble when you complete a lesson).

Gotta do my stories. Sometime around the second section, I unlocked the stories.These are short stories that are easy and short. They tend to give over twenty XP for each one and usually take a few minutes. Since you can re-do the stories, this is the bet way to get plenty of XP. However, reaching the daily goal this way will NOT earn any lingots. Using it to get close, then doing a lesson or practice for the remainder, will give you lingots. XP boost does not work with stories.

Double XP may not be free. Occasionally, the shop will allow you to get double the XP from your lessons, but it is a bit complicated. Reaching your daily goal under this juice won't net you any lingots. reaching another level will get you lingots. Using the XP boost doesn't work on stories. I'd avoid using the XP boost until you have reached the daily goal, to maximize points and lingots.

Testing 1-2 testing 1-2. When you start a lesson, or course, there is a light-bulb and a key. The light-bulb opens a primer on the lesson, giving you tips. The key allows you to take a test and level-up the course. For just five lingots (or zero with plus) you can level up your skills. This is useful if you are good at a course and are getting bored, but sometimes it is better to do the entire course instead. A successful test nets twenty points, failure nets a disappointed Duo. If you fail, either finish the course normally, or try again later (like a day or more).

The hard easy is an easy hard. You may notice that some lessons are harder than others. Tests are no exception, so it is better to take a test after a hard lesson. This gives a greater chance that the test will be a bit easier. There is no guarantee, but it can help.

Slow and steady wins the test. Slowing the dialog on lessons that have dialog may be annoying, but don't take chances during a test. You may think you have the listening skills down cold, but some vocalists are better than others and I've let my pride fail me a few times. Personally, I'd take every hint that Duo gives, especially when I'm a little unsure. Since tests don't have many hints, I'd slow the dialog for a slight edge.

You know nothing, and the birb knows it. Each section has several courses. At the end of a section, there is a test. In my foolishness, I assumed I knew some Spanish. From ZERO to TEN I chose one and was promptly put in my place for my pride. Starting at zero, especially for the first section test, is advisable.

Report it. Duolingo isn't perfect. Sometimes it gives you wrong hints or an answer you give should be accepted. At the end of a lesson, you can ether see user's comments (text baloon) or report a problem (flag). If there is a problem, flag it and explain it. Together we can make Duolingo better. Try to be respectful, unlike me; I tend to have a temper.

Green and red. Correct answers get a green popup while wrong answers get a red popup. Those popups can obscure your answer, hindering learning. Touch a blank area of the popup to slide it down. Now you can check how wrong you were and learn from it.

Play for me, Little One

I had a plan to finish Little One by the end of 2019. That didn't pan out like I had hoped. Most of the items left to add are minor and I could add two or three per day. Since there is another project I wish to get started upon, I'll probably default to adding an item to Little One each day and focus on my next project. For now I'm just trying to make sure Little One is in a beatable form before the next update. The ending will be sparse, and I'll add both it and the opening later, but it should be completable.

My plan is to rest for New Years (eve, day, and day after). I'll try to upload a build on the last day of 2019, but I have to pick up some medicine that day and this post won't be tweeted until that day or after. On the days I'm resting, I'll flesh out the plans for my next project. The ending scenarios are planned, so I'll work back from those. Mostly, I'll be listing the mechanics and writing pseudo-code for them.

The openings and endings of my project may be done with vector art. It seems easier to make several panel images and flip through them like a book. Text will probably accommodate the images. Since I'm doing this alone, and some days are better than others, I'll take the route of least resistance.

Aside from the story images, there are a few things to add before Little One is feature-complete. The critters need animations and additional coding. Beasts need to be planned, modeled, ect. Several parts will need models and textures before being added. Part droppers need to be coded and added. Player damage, sleeping, and recovery needs to be coded. Several props and a couple dialog elements are still missing. I'm going to try getting the vacucell to suck up other liquids, and the critters will bring several items to the game. Many of the building upgrades are unfinished as well, and need models, textures, and programming.


Better as of late than never.


 Yesterday (12-29-19) I felt like I was moving through molasses. I managed to get the material droppers done and in the game. These drop a few materials daily to assist with building and part creation. After a nap I felt much better, but I usually relax after I take my meds at six.

I've added quite a few things to Little One. Mostly the parts and upgrades crafting. The upgrades seemed to work well without any extra coding in other areas. Sometimes I'll go to add something just to learn it's either there already, or I've done the preliminary work; making a feature easier to add. Keeping future and related features in mind as you program will help you add the needed functions and code to support future additions. Planning can help immensely as well, and I should have planned Little One a bit more.















Friday, December 27, 2019

End of the Month Plan

I've been adding the menu systems in Little One. So far, the parts needed to win the game can be crafted, so can player upgrades. Stats, materials, and parts can be checked in the menu, and there is a save button. Now I just need to add the part objects and material and part dispensers so they can be collected. Several of the parts use a ton of materials to craft, so those will be retrieved via deployable drones.

The critters are modeled and textured, but have no animations. I might be adding them into the game late. Beasts may have to wait until much later to be added, along with difficulty. Opening and ending images need to be created, probably vectors that will be used like a comic to illustrate the story.

There are many things I want to add, and may add later if I have time. Changing the music for each area, allowing music to play during menus, difficulty, beasts to fight and get resources from, ship interior and monoliths. I'll add these features if I have time while I'm doing a new project next month. My main goal is to make Little One beatable and add the story elements.

NPC dialog is in the game, but I'll be modifying it to output different dialog from dictionaries. This will give the player tips, as well as adding some character to the NPCs. Most of the dispensers are done, and much of the coding is also done. I'll be setting up the last mechanics by copying needed code and modifying it. Actually, I might just take the mat collector/storage for collecting parts and dispensing built drones. One less thing to model/create (It's really just a collector attached to a giant egg).

Little One took longer than I thought, but it was interesting and I learned a lot. It has also given me numerous resources to use in my next project, and I can modify those objects for more resources. The next project will use many things from Little One, but it will have many new additions. This will allow me to reuse many elements and mechanics from Little One, making creation faster and easier.

I'll probably make a sequel or two later on.

The Next Project:

Blue Bloom will be a game full of monsters, crafting, and adventure. Using different items, you'll be able to modify the function of different workstations.  Different workstations may even assist each other. Hydroponics allows the player to grow needed food indoors, while the repellent globe wards off vicious monsters.

The vacucell from Little One makes a return, and may have extra upgrades. Joining it are numerous weapons to insure your survival, or hinder it. Modify your environment suit for different challenges. Repair laboratories and get them running again for extra advantages. Use the technology at your disposal to help clear out an invasive fungus.







Monday, December 23, 2019

Rush is quite a drug.






You've put it off long enough. There is a stack of work to do and the deadline is fast approaching. Past self has played and laughed and it's time for future self to pay up. In a fit of panic you get started and do three days worth of work in a single night. The quality is fair, the efforts exhausting, and there is little time to rest. At least you had fun until then.

Usually this can be avoided if you just start small and work your way up, but it was my favorite way to work. That strung-out feeling is adrenaline, a chemical your brain produces in response to threats. I'd agree that a deadline is a threat, but it was made that way through the magic of procrastination. While I enjoy rush jobs, I have a problem.

The adrenaline my body produces causes chest pains. Sometimes it's discomfort when I slow down, other times it's terrible pain a day or two after. Here are the two major problems. Little one has about a week and change to be completed, and I'll be trying to build a bigger game within the space of a month. Add to that the last bits of planning for my next project has to be done this month.

Little one doesn't have too much more. The NPCs are done, player seems solid, critters are coming along. I'll have to finish up the critters, add some props, add the parts, and program the upgrades and part fabricators. Most of the programming is already done, I just have to make a ton of assets to add.

Textures and animations will take the most time. I might drop some features and add them later. Beasts and difficulty levels seem like the first to be dropped. The parts needed may be dropped to 20. Simple upgrades will include inventory cells, energy and health boosts. This week is going to be hard.

My next project was to make a game in two months; one bigger than little one. I wish I had spent more time planning, but I should have plenty of resources. Some of the things made for it will be added to Little One and vice-versa.  The map needs added detail and grid separation. For brevity, I'll put together the endings and work backward from there. This game's current design is just a list of notes.

The final two days of this month will be used to flesh out Little One a bit. I'm hoping I can get the opening and ending scenes together, but they'll probably just be vector images. New year's and the day after will be filled with numerous tests and final planning to get my next project up. Once done, I'll furiously prep the player and several resources, mostly from other resources I have. My collection of failures will help this next project succeed.




Friday, December 20, 2019

Everything is burnt.

The wired mouse I normally take with me is failing. It could only be used on flat surfaces, but now it keeps disconnecting. I'm currently using a wireless mouse, but its middle button doesn't really click with me. There is another wired mouse at home, but I don't want it to fail. Either I'll have to acquire a new mouse, or deal with the wireless one when I'm in town.

I haven't been doing much on Little One these past two days, mostly my fault. Pushing myself too hard in any endeavor causes chest pains and burns me out. A health-protecting system my subconscious uses to prevent this pain is just to use burnout and depression against me. Sure, the pain isn't good, but I want to finish Little One this month.

The NPC accessories, animations, and textures are mostly done. Importing and assembling won't take long, but the dialog should still be written. Saturday I'll rest a bit, but I'm just going to ignore my body's protests and slowly pick up speed. The real problem is getting started, once I get momentum, I'm near-unstoppable.When my coding reaches 88 lines per hour, you're going to see some serious bugs.

I'll probably do a ton of planning on my two-month project this weekend. I'll have to get the planning done on that by month's end as well. Normally that would add more work and stress, but zero-sort is another stress reduction method.

Zero-sort operates on high-low impact balancing. If something causes higher stress than benefits, ignore it or break it down. Low-impact (result) options can also be chucked. When the value isn't worth the effort, postpone or chuck the idea. Bundle many smaller tasks into a relaxing time of fixing things. This is the low-stress low-value tasks that seem too small until enough pile up; it's like dusting off crumbs.Blog posts are low-stress but can have a nice impact. Rushing a few features to get a timely release is high-stress. If you have been regular with your updates, skipping one isn't a big deal.

This method is useful in decisions or cleaning/sorting items. Mainly, make any indecision into a specific answer, like yes or no. If I'm undecided, I almost always choose NO. When cleaning/sorting keep the things you want and get rid of the rest. If you just get rid of the things you don't want, you'll have a lot of maybe items that take up space. If it's clearly useful, keep it. If someone else can use it, pass it on.

I may be my own worst enemy, but I'm one of the few people I can fully depend upon, even if I cant always understand myself.




Tuesday, December 17, 2019

Yadda Bla Bla Bla Bla







Dialog systems tend to be as complex and as varied as inventories. Once you've created one, others are easier to make. Giving the player choices, branching dialog, or changing variables from the dialog system all make it more complicated. Little One's dialog system is just going to be a direct info dump. There will be text, and a done button when you are finished reading.

Godot has two of my favorite nodes ever, EVER!. The resource preloader contains assets for later use so you don't have to write all the paths out. The rich text label is a force unto itself. With BBCode, word wrap, scroll bars, and metadata links, you only need this node for dialog output. Text can be set as a meta-link that can pass a value via a connected signal. You can then do various things depending on the meta value passed.

My main dialog output setup consists of a panel with the rich text label as the child. The panel has the script, but the rich text label does all the work. I usually set a custom font since Godot only has one tiny, terrible font. The meta link is underlined by default, but I add BBCode color and center it to make it more visible. Several meta links can be added to the dialog and consist of the data passed and each attaches to the next text or BBCode string added.

The worst part of a dialog system is actually creating the dialogs. I'll be using a preload script with dictionaries and functions to randomly select text strings. Day zero will mostly consist of hints and tips for the game. Just make sure that if you pause the scene, you don't pause the dialog output.

I usually connect a signal from the player to the NPCs and from the NPCs to the player. If you have limited NPCs and everything is grouped correctly, this can be done at the start of the level/game. If the NPCs are numerous or randomized, this can be done when you interact with the NPC. Just remember to check if the signal is connected, godot doesn't like reconnecting existing signals.

With this basic setup I signal the NPC (and pass a value so only that NPC answers) to talk. The NPC then gets the text and signals the player with the required information. Now the player passes the data to the dialog system to format and output the text. I've started just calling a function from the dialog system in the player's script. Since I've learned that you can just call the functions from a node's script I might connect and use signals far less.

Direct-calling functions might replace generated signals, but it cannot replace all signals.





Friday, December 13, 2019

Player: ReLoaded

Finally got the player model imported with animations. At first, I just added the animation setup to the player scene, but I knew I'd need to refactor the player. Starting with a copy of the animation setup, I copied the script and test room then started working. Referencing the original player, I added all the accessories and gave them the groups and signals needed. Since so much had changed, minor edits were required for the script's copy.

Initial tests went well. Objects fired at near-lethal velocities, so I had to scale back their speed. Vacucel aiming was a bit off, so I adapted it. Items were collected slightly better and faster. All the buildings and menus thus far work.

The major problem came from the water pools. Water was being spawned, but it kept falling into the pool before collection. Most times it wouldn't seem to appear. After some debugging (print statements) the problem was located. For some reason, the water was spawning too low. I just added an extra unit to the spawn's Y axis for a quick fix.

I'm not looking forward to adding the dialog system, but that may come next.

Tutorial, How to Debug Code:

Most times when there is a syntax error, you either get a warning or a crash. Most script editors take you somewhere close to the offending line so you can find the problem. With godot, the error is usually above the line indicated. Most flaws are within a few lines of the line indicated, if not the line itself. Remember, these editors are making a best guess, so they can be a little off.

However, sometimes something doesn't work for any number of reasons. Sometimes you cannot see the error because it's logical (and that skill may need a few levels). If a specific mechanic isn't working in a game, your first option is to check the area of code for that mechanic. Usually, this is contained in a function for ease of use. Often, just looking will reveal the problem.

If not, I like to add print() statements in the code and output different strings or values. hen the statement at the top of a function doesn't print, then the function isn't being called. More code to check, but you could have forgotten to call the function. This is also useful to check if statements in a similar way. When the requirements of an if statement are not met, it won't activate.

Printing variables can help determine if they have the correct values, or that they are being used. An errant or empty value can cause much mayhem. Bad incoming variables are also problematic, so check them if you have them.

If all else fails, get a rubber duck and read the code's lines to it. Then kick yourself smartly when the solution is obvious. The solution is almost always obvious.







Tuesday, December 10, 2019

Doing things by half

Lately I've noticed something odd in the godot engine. My framerate dipped to 20fps and the max for an empty scene was 30fps. Sure, I've been adding stuff to Little One, but that frame drop was uncalled for. Clamping the framerate at 30fps was a bit unusual, so I did some digging.

Checking my laptop's processor in the task manager, I noticed that only half of my processor's power was being used. I'm pretty sure this was new. My screen's refresh rate was set at 60Hertz, so that wasn't the problem, or was it. Looking on the internet, I found a solution that worked; but I had to change a couple registry values.

Little One's frames went back to full, but "full" is still 30fps. Somehow the refresh rate indicated in the graphics settings is not the rate of my actual computer. With vSync on, godot runs at a max of 30fps. Without it, it could be more, but it still seems to be 30fps. Even with my processor now running at full, I'm still mired at 30 fps. I'll be checking my graphics drivers to see if I need to update.

Either an update fouled something up (most likely), or this is intentional. Why would Microsoft truncate the processing power of a computer? Is it to keep the PC from overheating or crashing? (LOL, I doubt that) Could it be because my laptop is over three years old? I'd assume it's because I have an AMD processor, but intel processors are also being slowed.

Personally I despise my laptop's speed being reduced which is why I messed with the registry settings. The hobbled refresh rate is another matter, but that's difficult to notice unless you're an indie dev.

Speaking of Little One, I've been editing the maps to make them easier to navigate (at all). I'm also testing out shadows, may have to add a flashlight. The caves should be navigable and the spire fields are actually explorable. The player model is in and has animations, but I'm not using the animations yet. I might have to refactor the player or create a secondary version, but that can wait. There are gates to destroy throughout the map, and their destruction is saved with the game.









Friday, December 6, 2019

The Panic Mechanic

I'll just go over some game mechanics and the basics of how I'd do them. These are just ramblings, there is no guarantee they'll work in any engine and I'm not providing technical details or code.

Delta Timer.

Just a variable that starts at 0.0. You can add the delta or any number to it each frame during any process that runs each frame (or at specific times). Once it gets to an amount you want, do something and set it back to 0.0. They have a majority of uses and you can have as many as you need.

First Person Shooter:

I like FPS and first-person cameras. They're easy to do since the camera is the player. You don't need any complex camera mechanics to keep the camera with the player. Godot's engine docs have nice tutorials for this. Mostly you just rotate the player L/R with mouse movement and the camera U/D with mouse movement. The other movement keys (WADS/Arrows) are mostly for strafing. The only problem is making sure the strafing is affected by rotation.

The guns come in two main types, hitscan and projectile. Hitscan is mostly for bullet and energy weapons while projectile is for grenade/s and rocket launchers.

Hitscan:

I know it's a projectile weapon, but if the projectile moves at sonic speeds you'll want this. It mainly uses a raycast or other pointer/area/collider. When you "fire" you check if the raycast is colliding and check if what it's colliding with is in a specific group or has a specific variable/property. Groups are great for this. Now just reduce that target's health. Adding a muzzle flash helps.

If you hit a wall, get the hit position and add a hit decal. These are mostly 3D planes with sprites on them. To avoid Z-fighting, you could have the decal raised a bit from the object center. Getting the rotation right is a bit tricky, either use the face normal or invert the player's Y rotation.

Protip: Keep several hit decals in the scene and grab them all in a list. Move one where the wall was hit. Use a variable to keep track of which decal you are using and loop through them. No adding/removing of objects needed.

Muzzle flashes are ether 2D or 3D objects that appear for a second. You can use timers, but here's a better idea. Spin the flash and make it visible when the player fires and invisible when the player releases. The flash can also turn invisible based on a delta timer that increments while the player is pressing the fire button.

Projectile:

These weapons "throw" an object. Rigid bodies are great for most of these. You just have to add the object to the end of the weapon and give it some speed. Just be careful it isn't too close to the player or they blow you up, BOOM!

Most of these projectiles have an area that detects "hits". You'll have to use an explosion animation or particle setup and cause damage to the hit object. I'd have several of these setups in the map, move them to the collision, and use an area attached to them to determine what gets hurt. This can play a single animation or particle effect, sound, cause damage, and then go inert and be moved away. This is similar to the pro tip with hit decals.You'll also have to remove the projectile.

Tip: An object playing a sound cannot play the sound when it's removed. Timers can help, but other object setups are useful too.

For sticky grenades, try making them a child of the thing they hit.


Sit, Stand, Lean, and Crouch:

Crawling on the floor looks fun, but doing it in a game is easier than you think. First, you'll need different collider setups or collision shapes for each position. A state machine will help, but I've never done one of those yet. When the player/NPC changes positions, just enable the appropriate collider and disable the other colliders. You'll have to use different animations when prone, but this is a simple way to do it.

Sitting is just making the character either a child of the seat, or positioning them appropriately. Disabling the character's or the seat's collider helps.


Inventory:

There are many different kinds of inventories. The most basic one is a list or array. I personally use dictionaries that either contain arrays or other dictionaries. You really only need the item name and amount in any slot. More complex item data can be held in another dictionary. Selecting, picking up, and using items are all more complicated.

I'd use Godot's ItemList nodes, then iterate through the inventory and add the items. The docs can cover more than I. For picking up, you'll have to iterate through the inventory to check if you have that item. If the slot isn't at the limit, add the item's amount. Otherwise, start a new slot. Those if statements tend to get rather long and loopy.

Time:

Also know as a clock or a day/night cycle. Mostly it's just a delta timer that increases the "minutes" once it gets to 1.0. Once the "minutes" reach a specific amount, increase the "hours" and make the minutes equal zero. You can figure out the rest.

For showing the clock I use a label on the HUD and use a custom font. Godot's normal font is small. You'll want to format the text output a bit, but that's easy.

The day/night cycle requires either animating the sky or animating a material on a sphere. It is very complex and I'll only give one tip.

Tip: If you need to use a sphere/dome for the sky, make it change its position to the player if it's smaller than the map.


That's pretty much all I'm going to post today. There might be more later.











Tuesday, December 3, 2019

Burnout 2019

I probably won't release a new version of Little One this week, or at least not today [12-03-19]. I've been fixing thee map some and adding features to the save/load system. Gates and pools will be saved so you don't have to break or drain them every play. There was a cargo spacecraft I've modified and added. It was an old resource I made for another project. This is why I encourage you to keep resources of failed projects.

The player and NPCs are coming along. They have simple animations and textures, but lack accessories or a good material. I'll try adding the player and getting them fully working in the game, but the Vacucell needs textures first. Ramps and a few other things need to be added to the maps, and the caves need editing. Resource droppers will also be added, they already exist in the next version's save file.

The old save file will probably be useless, but I doubt many people have played the game. I'm also feeling a bit of burnout from pushing myself so hard. There haven't been many chest pains, which is good. I want to complete this game so I might cut corners and add those later.

There are several ship parts planned, both recovery and crafting. I'm thinking of having twenty to forty, but I'm not sure how many yet. The player will also get upgrades. In the end it should be a light, easy, game to play.

Not like the horror of my next plan.

Tuesday, November 26, 2019

Grain Drain

I added a save function to Little One. Most of the data was just easy to write to the file, but the buildings had to be formatted. Writing the dictionary for the buildings didn't take long, but I've had to add values throughout. A dictionary for the wild plants was also needed. Then I had to make sure the build platforms saved their own values while the buildings saved their values.


The fields seemed like a good start, both wild and domestic. They mostly went off without a hitch, but I had some bugs when I programmed out an exploit. Storage was next, and I gave it little thought before moving to the critter pens. Those pens had a few bugs, but the critters were missing. I had to modify the re-parenting function so they'd work, but the critters never seemed to load. Turns out, they did load, but kinematics and rigid bodies don't like each other and critters got flung.

Last night I checked to make sure everything was working, and the storage buildings were not. I was trying to get values from an empty dictionary within a dictionary. Putting the storage cell generator in the global dictionary worked, but I had to modify a few things. Today I added a few new grain plants just for something new. Most of the plants are modeled, but I need to tweak them.

After all that, I'm going to rest before I add more content. This whole project has taught me valuable lessons I'll carry into the next project.

White Powder, the Race to Make Cannabis Dangerous

First off, marijuana is a racist term for cannabis. It was originally coined in the 1920's (AFAIK) to associate it with migrant workers (Mexicans) who would use it to end a hard day,s work on a high note. It, and its legal status, has been used to attack groups that American politicians have found "undesirable". From different races, to protesters.

Cocaine, sugar, caffeine, opiates, crystal meth, alcohol, and various other substances are "WHITE POWDER" drugs.

When I first saw pure THC, it looked like cocaine. Cocaine, sugar, caffeine, opiates, crystal meth, alcohol, and various other substances are "WHITE POWDER" drugs. The more racially (chemically) pure, the more dangerous. From off-white to crystal clear, the danger of abuse looms ever near. So when we legalized cannabis, every corporation wanted a toke of the dope. What is their unsaid mantra? Bigger, better, more potent, whiter. Thus cannabis was purified, the amount of THC increased, and thus the power of addiction.

It is a habit, one I may never escape




Yes, I do use cannabis to end my day on a high note. I've also used it for migraines. But I regulate when I use it and only get high enough for the munchies. It helps me sleep without the effects that many sleep aides cause. It is a habit, one I may never escape, but I chose this habit and keep it scheduled. Letting it get out of hand is unwise, so I fill my day with activity.


Wyler's with one-quarter cup of sugar per gallon

But I'm not as likely to become addicted to substances. When I was told to reduce my sugar intake, I went almost cold-turkey. Considering a substance that is eight times more addictive than cocaine, and is in everything from bread to coke and beyond, that didn't last. So I arranged my addiction by making my own drink mix (Wyler's with one-quarter cup of sugar per gallon) and watching what I consume. Desert should only happen once a day; if at all. You'd be surprised how much sugar is in a can of ravioli (two sandwich cookies per can).

the first OD strain



With the businesses increasing the amount of THC in every puff, how long before we say "ENOUGH"? While it may take a lot of cannabis to overdose, I'm sure Big Pharma or some corporation putting profits over safety will achieve the honor of creating the first OD strain (It'll pop a cap in yo' ass).









meth (it's chemically malicious)


Sure, you can talk about how many people are now addicted to the new "SuperWeed" (coming to a metropolis near you), but how many are also addicted to coffee, sugar, coke (drug & drink), opioids, or meth (it's chemically malicious). The more you purify most substances, the more dangerous it becomes (except water).

Remember, keep your recreation in its proper place so your life can be productive. 




While I'm all for cannabis being treated similar to alcohol, we should treat it similar to alcohol; not water. In fact, we should put stronger regulations on how pure the THC can be, before it's too pure for me. I've been too high, and considered just using all day, but not everyone has the metabolism or control I have. Remember, keep your recreation in its proper place so your life can be productive.

We should learn from previous "WHITE POWDER" drugs that a pure race is a terrible waste.

Thursday, November 21, 2019

Saving Games

Godot Engine already has a tutorial about saving games here, but it may not be for everyone. Basically, it grabs all the nodes in the “Persist” group and writes them to a file. It does this line-by-line, but you might just want to dump a dictionary to a file and grab it again.

I'm assuming you are using a singleton (preload) scrip that holds the game data. Singletons are scripts that load before any others and can hold persistent data for the game. Dictionaries are a complex datatype that can keep things organized. Since dictionaries are passed by reference, they are easy to keep updated.

func save_world():
    var saveFile = File.new()
    saveFile.open("user://savegame.save", File.WRITE)
    saveDat["Cells"] = cells
    saveDat["VacDat"] = vacDat
    saveDat["PlayDat"] = playerDat
    saveDat["Storage"] = storeDat
    saveDat["MatDat"] = matDat
    saveDat["BuildDat"] = buildDat
    saveDat["RingDat"] = ringDat
    saveDat["WorldDat"] = worldDat
    saveFile.store_var(saveDat)
    saveFile.close()
   
    pass



 Everyone will tell you that you don't need the "pass" keyword. They are correct, "pass" is used to skip empty functions and does no harm at the bottom of a function. I usually start two or more functions at once and use pass so I don't get errors or red lines as I work on individual functions.

First I created the "saveFile" variable and created a new file. Then I opened a file I intended to save to. The file does not need to exist if you are writing it, godot will automatically create a new file. It is best to use the "user://" location as this is a location that the game is allowed to write to. Now I assign the different variables I want to save to a single variable I initialized at the top of the script. Then the variable is stored in the file and it is closed. Remember to close the file to avoid memory leaks.

func load_world():
    var saveFile = File.new()
    if not saveFile.file_exists("user://savegame.save"):
        print("error, no save file")
    else:
        saveFile.open("user://savegame.save", File.READ)
        saveDat = saveFile.get_var()
        cells = saveDat["Cells"]
        vacDat = saveDat["VacDat"]
        playerDat = saveDat["PlayDat"]
        storeDat = saveDat["Storage"]
        matDat = saveDat["MatDat"]
        buildDat = saveDat["BuildDat"]
        ringDat = saveDat["RingDat"]
        worldDat = saveDat["WorldDat"]
    saveFile.close()
   
    pass


Now to load the data back. First we need to create a variable and open a new file. Variables initialized in a function can only be used by that function. Next, check to make sure the file actually exists, since we are getting data from it. I don't check to see if the file has any data since it should be in there.

Open the file and assign the data to another variable, the one initialized at the top of the scrip should work. Now we just apply the different key values to their respective variables. I'm not sure if different keys are passed by reference, but I think it depends on the variable's type. Finally, close the file to prevent memory leaks.

Feel free to reference godot's save tutorial if you want to try different ways of saving data.











Tuesday, November 19, 2019

The Rain in the Game Falls Mainly on Nothing?!

There are many ways to do rain and other weather effects. Some games use particles, which can clip through objects. A few just add/remove objects, but the physics needed and constant object flow causes lag. In 2D it can just be a screen effect. A few use shaders or have dedicated weather systems. For newer developers, that don't have the resources or experience, rain systems can seem awkward.

Either you have particles or objects, but those either clip through objects, or cause lag. I've found another way. First, a little advice and an example. Everyone seems to think the rain needs to fall, preposterous. Take two coins, fairly new ones, and stack them between your thumb and pointer finger. Now rub the coins together, slowly getting faster. If done correctly, three coins should be visible. It's an optical illusion, the same as an after-image that some anime characters can create.

How does this help us create a rain system? By taking several rain meshes and shuffling them around the player, we can cause an illusion of rain. I'll walk you through the steps.

First, make two rain objects, a drop and a splash. We'll add them to a parent object/node as meshes with a basic water or blue texture, no colliders or transparency needed, just meshes. I like to add each to a different group or have some other way to grab them from code. Don't try to grab them directly or through paths, we're going to copy them. The scene should be a parent node with a few dozen drop/splash children.

Make a few dozen copies of the drops and splashes. Add the scene to a scene, preferably as a child of something positioned at (0,0,0). Now let's create a new scene with any positional node. Since I'm doing 3D I'll use a spatial node. This can also work in 2D with minor adjustments. Add a raycast and make sure it is casting down (-y) by about 300.  Move it up to +y 200/250, make sure it is active as well. Create copies and change their x/z to whatever you feel like. Keep them relatively close to the center, but not on the center.

About 12-32 raycasts should be good. Add a script to the top (parent) node. The scene should be a parent node with a few dozen raycast children. On ready you should get the splashes and drops from the scene tree using groups. If you've added the raycast scene to the same parent you added the drops scene to, you can just get the parent and then the drops scene's children. Either way is good.

Get the raycasts as well, you can just add the children to a variable. Get the player node/character as well. You should have two main functions, shuffle_rain and unshuffle_rain. The unshuffle_rain function should just get all the drops/splashes and place them somewhere hidden. I suggest changing their translation to (0,-200,0).

The shuffle_rain function is a bit more complex. Grab a random raycast, drop, and splash. Check that the raycast is colliding and get the collision position. Place the splash at the collision position, and the drop at a higher position. You can add a random number to the position's Y axis.  You would do this several times a frame, feel free to experiment.

The final things to do is to get the raycast parent to rotate and change it's X/Z translation to that of the player. Randomizing the Y rotation can help make the rain move more randomly. Now all you need is signals/Boolean to start/stop the rain.

No odd clipping, no lag, no physics, easily editable. It's a good rain system if you want something easy to implement.















Thursday, November 14, 2019

Pulling Together the Last Bits

There will come a time when you are done with most of the major parts of a game. Everything looks like it can just be quickly pulled together. Just finish up a few assets and add them to the game. Finish up the programming and element placement. Then just code the save/load system and you are done; a few weeks, tops.

Have to create a few more assets.
Re-do some more assets.
Forgot I had to program this thing.
Came across a problem, need to fix it.
Why are these assets taking so long.
Is there an easier project?
Who can help me?
That's future self's problem.
I think this other project might be easier.

Before you know it, you have another unfinished project giving you stress. Sure, sticking with a project is a nice strategy, but how long until you burnout. I'm trying something else. Trying to make all the needed assets for a specific area/mechanic is very time consuming. Adding just one is much easier.

Add an asset, finish some code, fix a bug. Staying on a single task is boring, and you need to complete something to feel like there is progress. Don't try completing every asset for an area, just one. It takes less time and adding it feels good. Program a minor mechanic to feel like you are adding something, and prep a few things needed for bigger scripts/mechanics.

Work in a way that has steady accomplishments. Adding assets singly may take extra import time, but the accomplishment feels nice. Now there is something new to show in far less time. Finishing or adding mechanics is good. Finish the small things and add to the bigger things. In this way there is something new every day, and there should be less burnout.

Also Little One has  energy, health, and master storage containers in the build.


Tuesday, November 12, 2019

Youtube can't keep its ads off the children

So it's making us pay. I thought youtube only allowed accounts for people over 13. Doesn't help that the parent's want everyone else to raise their children.


So I'll be looking at my old Vimeo account. I'm sure I can do something with that small amount of data they give free accounts. Not that I have any money, or health insurance, or... you know what?

Would you kindly support me on either Patreon or Ko-fi?

My main concern is that youtube can change the rating of a video at its discretion.That's fine if a video needs to be marked from child-friendly to NOT. But, while I do upload game videos, and some of my projects are child-friendly, I'd rather not have my videos marked as so. I don't want to have trouble because the YOUTUBE AI deemed a video of mine as child-friendly when it isn't. Or worse, have someone claim that gamedev and gameplay videos are indirect advertisements aimed at children. I really hope youtube notifies people when their video rating is changed, but it seems like another way to remove channels they don't like.

***

Little One now has a sky with day/night function. The day cycles a bit fast and it still needs work. I'll have to unwrap my own sphere and not rely on Godot's sphere. Skies are slightly hard to get right and the shaders in Godot don't allow you to layer images. The bad UV layout for the sphere warps things too much.

It made the sun square-ish.

It doesn't help that unwrapping spheres is difficult with all those seams and the sun still has to traverse the sky. That is a problem for later though. I did my best, but the visual shader is still lacking. Layering images, or having several image slots, would help quite a bit. Currently, I need to blend the images with math. Even with all the functions they give you, I had to split it into two materials to get close to what I wanted.

A staircase of material passes would be annoying, but it might be the only way.

Blast it, I'll work on getting the health and energy stats done along with master food/water storage next. I should just focus on getting individual items into the game instead of doing all items at once.


Friday, November 8, 2019

Worst Laid Plans

I'm starting to see the working on video games needs a bit of balance. It takes planning, resolve, and steady progress to complete a game. Little One needed more planning before I started, but I'll put more into planning with the next project.

I should plan the critters and beasts, along with the parts needed. Some parts you'll have to find, others need to be fabricated. I'll have to model, texture, and animate these things as well. Minor static objects are not that bad, but animated, organic, or complex objects take the most time. Tubes and gears are easy, engines and ants tend to be more complex.

The player and NPC animations are simple and mostly done. Usually you can get away with just a walk animation for NPCs and maybe an attack animations for enemies. Bosses take far more work, as much or more than the player. The textures are also basic and need some work, but I still need to model NPC accessories.

Plants and resources need to be distributed across the map for the player to find. I might have a ship somewhere on my PC, along with some other resources. Might take stock of, and arrange all the old models I've made. It's time I gathered my resources and started a collection for later projects.

That's the good thing, even in failure you learn and gather resources. I advise keeping models, textures, and sprites; they may be useful someday.

Posts Versions: RED & BLUE

Monday, November 4, 2019

A Small Matter

It always seems like two steps forward, one step back when you are a singular gamedev. I'm having problems with the textures/materials in Little One and there is still so much to do. Sometimes I wish these problems didn't happen, but I enjoy solving problems. Once the material problem has been corrected, and I know a good way to correct it, I'll start adding and testing the final mechanics.

The dialog system is in another project and needs to be modified for Little one. Player and NPC models are mostly done, just need textures, animations, and a few minor accessories. Critters need some more programming and they'll give way to beasts within the game. Building upgrades need to be modeled, textured. and fully implemented. There needs to be a way to dispense materials from destructible objects. Many of the parts and player upgrades need to be coded and implemented. Opening and ending scenes need to be done along with success/fail conditions. World data and save/load systems need to be finished.

I should do some planning on the final parts needed. Most of the player upgrades are partly implemented. There is a collection on open game art that has resources for Little One, as well as what I'm making now.

Speaking of planning, I'll be planning a project a bit this month. If I finish Little One this month (November 2019) I can work on another project in December. Little One will have taken about five or six months at the end of November 2019.

I wonder if I can make a bigger game in two months if I planned it well.

Thursday, October 31, 2019

Might as well be walking on the sun.

 Match 3 or more, tap that group of blocks, connect every image of the same color. 

Fendish
Tasty!
Slumageddon
Delicious!

And yet, you lost. You still have more lives/energy/McGuffins so try again. Different parameters, power-ups, or strategy and you could win.

Your hearts are full!
Your fiends are full of energy!
Limited time to complete the challenge.
PLAY NOW!

It's all random, just luck based.

You think so, right?

Welcome to being wrong.

Look close at the fun little games you play. That time you should have been defeated, or the time you should have won. Blocks of the color you need are strangely rare this time, or power-ups are a bit hard to find. This is by design. Some games are programmed to help the player, others to hinder. It's not "Surprise Mechanics" it's programming.

I'll share some things I've noticed about Best Fiends. Mainly because I play it at times, and it's generous (except with the gold). You start with a single fiend and have to connect items of the same color to "attack" and defeat slugs. You can unlock\buy other fiends and their styles and level them up. If you lose a level, just ten gold for five moves (terrible deal). Playing over 500 levels I've noticed some things.

Fiends power up differently on different levels. One one level it would take twelve matches to power up a fiend; the next takes two or three times that. Understandable when some levels give you more moves.

Fiends power up differently in general. Depending on the power they have, the color they collect, or even the goals of the level; fiends power up differently.

Some levels start with the same items in the same places. It's not just the bombs or the item volcanoes, I've seen the same "block" patterns at the start of several levels. This shows that not everything is random and things can be controlled.

Items fall behind other items. Items should fall down when you remove stuff below them, right? All nice and orderly? Most people might not notice it, but I've seen an item fall behind another item, breaking a possible grand combo or last-move win. I'm not talking about items falling down a slope of other items; falling directly behind another item. This could be a glitch, but it doesn't seem frequent enough.

Some levels don't have items of a certain color. This happens mostly on smaller levels, making large combos easier. The color is not needed, and neither is the fiend. If a color can be omitted, then the amount dropped might also be controlled.

Needed colors seem rare. Sure, matching small groups of colors to make large combos with other colors is a strategy. But when only three of a particular color have dropped in the last five moves, something's fishy. I'm not talking about the levels where you have to "free" the color from slime and match an amount of it to "unlock" it. Juts regular levels with irregular scarcity.

You have to "unlock" the color before it starts dropping it. Now I'm talking about those levels. There are blocks of the color hidden under slime. Remove the slime and match\blast enough and they'll start dropping. Now you can collect enough to complete a challenge, maybe.

Needed colors seem numerous.They are letting you win, don't you feel special. Sometimes you'll start a level and there are more than enough of the color you need to collect. So many you don't need a converter power-up. Just make sure you complete the other goals for the level.

Some power-ups have exact placements. Usually, on any chain that completes a power up, the power-up drops at the column you started the chain. Sometimes an obstruction will change that, but it's a nice trick to place power-ups (Ru's bomb) at opportune spots.

Facts:
Color drops can be turned off/on even during a level.
Fiends power up at different rates for different reasons.
Some levels start with the same pattern every time.

Rumors:
The amount of a color can be controlled.
Items can arrange themselves when falling.
An entire level's drops could be arranged from start to finish.
The placement of "block" and item drops could be controlled.

Like with any game, the player doesn't know the extent of control the game has. From keeping the player alive, to arranging drops, anything could be controlled. Far more than people realize, and some games are less friendly than others. Some seem innocent, but watch the patterns.

An extra bit of control can make the game more/less challenging, or it can control the player.

Thursday, October 17, 2019

To Kill an Indie Game Dev

For those of you who don't know, I have a heart condition; two actually. I was born with a congenital heart defect called Tricuspid Atresia. This means the tricuspid heart valve is missing or abnormally developed. The defect blocks blood flow from the right atrium to the right ventricle. A couple surgeries, when I was a few months old and again at two years, "fixed" the problem. I was on medicaid until I was about thirteen, or maybe a little younger. I was living with a guardian who felt it wasn't worth it to pursue my medicaid. My God bless his special heart. That's a southern insult/curse.

At around 16 I moved back with my mother, who had remarried (my father died from cancer when I was about eleven). I got my G.E.D. and mostly did physical labor to earn enough for what I wanted. Went to college, the second time I got degrees in networking and web design. This was a community college and it was almost a decade ago. Then, around early 2017 I noticed my heart didn't feel right.

It felt like someone squeezing my heart. I was out of breath, tingly everywhere, lightheaded, and I felt pressure in my chest. After a week or two of this, I went to the doctor. The EKG machine look about as old as me, but the doctor was skilled and nice. She diagnosed me with Atrial Flutter, a type of abnormal heart rhythm. Atrial Flutter is similar to AFib, but the beats are more regular. Basically, the top chambers of the heart beats 2-3x faster than the bottom chambers. I was originally prescribed aspirin and metoprolol.Later I was taken off aspirin and put on xarelto, another blood thinner.

Let's put this into stark relief for those that don't quite get it. I naturally have a fast heart rate and low blood pressure. The Atrial Flutter is triggered by an increase in my heart rate. The medicines I take lower blood pressure and thin my blood. Even standing can trigger my Atrial Flutter if I don't take my medicine. Most physical activity reduces the effect of my medicine. 

I live in the United States.

It is a shame that I need disability to get medicaid. I just want proper medical treatment for my heart, without being slaughtered by debt. This could have been fixed years ago, but the government is dragging this out, hoping I'll die or get discouraged. Thus, I'll be trying to do what I can to get support, but nobody seems to care. Attempted negligent homicide, and I'm not allowed to properly defend myself..

The symptoms are getting worse. Stress now causes near-debilitating chest pains, and my left arm has gone numb twice in two months. My new years resolution is to remove the threats to my health and well-being; permanently.

You have the rare opportunity to support this artist.
Ko-Fi
Patreon
Or just tell your friends about me.

Monday, September 30, 2019

Node of Command

So I told the build menu, to tell the build system, to tell the building; to upgrade. This all while the game was "paused". Any node with a script is able to get another node to run functions within their script. Something like node.function() where node is the node that has the function, and function is the function. Clear as mud until you try it.

This is great in situations where signals may be too troublesome to set-up. I'm not talking about default signals, but custom connections. It is also helpful where you can get or pass a node with w function you want to run. Not sure if you can run a node's functions on another node, but if I can I'd probably crash the engine every day. Might try it just to check.

The game is never truly "paused". Pausing the scene tree in godot just pauses processing functions (process, input, physics). Signals and calling other nodes' functions from an active node still works. (Running the _process function on a node from an un-paused menu node might crash godot) This means I can cause NPC expressions, object building, and general mischief while the game is paused just from a single active node. Cascading function calls anyone? (How to mess with the player, 101)

Arrays (really?) and dictionaries are passed by reference, not copied. This means that if a node's script sets a dictionary as equal to another dictionary, changes are synced across all instances of this dictionary. So my silos will grab the parent's exported dictionary which will be referenced from a global building dictionary (or even a nested dictionary). So updating the silos when you add/remove items will update the master dictionary.

And there are still tricks to find.

Thursday, September 26, 2019

It's a cube, it's a sphere, it's a placeholder!

Added a build system to Little One. I'm currently using placeholders for the upgrades and a couple of buildings. So far it is going good, but there are only upgrades for one building. The upgrades are hidden below the building and moved up once activated.


As you can see, the buildings can be created, deleted, and one can have upgrades. The final version will require materials to create the buildings and upgrades. After the upgrade placeholders are done, I'll add the actual upgrad objects and material requirements.

Monday, September 16, 2019

Petting the sweaty stuff

Been fixing small errors in Little One the past few days.

The vacuum handles water and solids differently, but it was clearing the object refList when needed. When dealing with water, this wasn't needed; removing it made the vacuum mechanics much better. Almost too good, I've had to enlarge a few collision areas and still need to tweak the speeds.

I was originally going to use critters as ammo, but Godot doesn't have a good way to control rigid bodies. That meant I'd just use their products (eggs and the such), but the critters were not laying their eggs anywhere visible. Finally, I just had the eggs placed where the critter was because using the output node for placement didn't work for some reason. Dude, where's my output node's translation?

Speaking of critters, since they now use different physics the game would crash whenever the vacuum areas touched them. So I removed them from the Vacup group and then they stopped being held by the fences. The fences change Vacup object's physics layers so they'll collide with the walls. Just made the fence area also look for Critter groups to fix that bug. Critters walk in, but they don't walk out.

Added carrots because I already had a "fruiting" tree and root veggies seemed harder. Guess what?! I was right! The carrots got "stuck" in the ground. To "combat" this, I just re-textured the rock mesh and added it like a small hill. Using this, I adjusted the carrot height and fudged some things. Fixing the vacuum also helped immensely. This work around is kinda low-hanging fruit though.

I've set the vacuum to aim where you are looking, but the items still have problems being caught by the receptacles. Scalling up the collision areas should work though.

The map is mostly done, and gates are being added. Plant and tree areas are mostly done, but I have some edits planned. Critters move about and can produce items, they need more work. Water needs to be worked upon, but is mostly good. The dialog and storage systems still need to be added, but I'll have that fairly easy.

Support this artist on either Patreon or Ko-Fi.

Thursday, September 5, 2019

And we're stuck, in the map.

Got Little One's map all set up how I wanted it, it looks good, decided to build and play; and got stuck. You can't really get farther that a few areas before you get stuck. Because of this, I won't be releasing today. There is still quite a bit to edit and nudge around.

Walls must be added/removed, ramps placed, and pieces moved. I might have it fixed in a few days, but I'm too hungry now. On the plus side, there are plenty of areas to put gates to control player movement. Most of the layout is done, and I'm using spires to patch holes.

There will be seven to eight areas to explore in this map, all with different features and dangers. Once the map is fixed I'll keep adding features until complete, then get back to Adventures' EDGE. I might fiddle with some mechanics for other games as well.

Friday, August 30, 2019

Artificial Additives.

I've been having some problems lately. The area I live in does not get high-speed internet, and I couldn't afford it anyway. Therefore I either go to a local coffee shop or library to access the internet. The coffee shop is noisy, crowded, and I lack money to get a coffee most days. My heart can't really handle much caffeine, so I get decaf.

While the library is quite, it employs a web filter. Nothing wrong with that, keep people from accessing things they shouldn't. The problem is they block anything to do with games, and their filter recently re-classified numerous websites lately. Did I mention that this library has Minecraft and Roblox installed on their own computers? And they block game websites. Gambling is another category and I'm not sure if they block those.

For the past two weeks I've tried to find a solution, even asking for websites to be unblocked; nothing. Even proxy websites are blocked and I'd rather not use tor. Of course I use firefox, and add-ons are not blocked. I searched for a proxy add-on and installed one with a good rating (not the first in the list). Now I can access open game art, itch, anything. My browser just ignores the filter.

Some will argue the philosophical and criminal merits of this action. I'll be able to update my projects without frustration.

Wednesday, August 28, 2019

Texture Material

Used my phone to take some pictures and turn them into textures. I've used Gimp's cubism filter to make them look a bit better and keep the art style semi-uniform.This prompted me to get the textures finished for Little One's maps. They are mostly done, Just need the caves and matchstick maze.

I'll upload the textures to open game art when I can, and post the map images when they are done. Most of the textures are not tile-mapped, but most can be. Once the map is done I'll do a quick run and see how everything looks and edit anything that needs it.

Finishing the map seems like the best course, then I'll be able to add the mechanics as they are polished. The plant growth mechanic is mostly done. Dialog mechanic will be repurposed from Adventures' EDGE. Critters are just starting to be programmed, and need some tweaks. Beasts, rain, and water pools need to be stated on. The vacuum mechanics need some tweaking, as does the music system.

Soon I'll have Little One mostly done and I'll tweak Adventures' EDGE and work on that some more.

Have a nice day and stay hydrated!

Friday, August 23, 2019

Blocky Pixels

I rather enjoy the library. It's quiet, has internet, and doesn't block any websites I need for my projects. Until they decided to block open game art and any website I would upload my game updates to. I live in an area where I cannot get high-speed internet, even if I had the money. Over the course of a weekend half the websites I used got blocked, but the library still has minecraft and roblox on their computers. Good luck updating them when you block anything to do with games.

Their security system, Fortiguard, is "great". It categorizes derpibooru as pornographic and gurochan as  arts and culture. With derpibooru you have to set the filters to view anything adult but with gurochan it's just a click away, a click away. Because gore is so artistic and cultured. Pixiv is marked as Entertainment, but has similar content as dirpibooru, just in broader categories. And don't get me stated on furaffinity being arts and culture. I guess nobody was logged in when that site was classified.

Fortiguard won't update a website's category, even if you ask nicely with evidence that the category is incorrect.

I know, I'm complaining, but I think I should do that more often.

The local coffee shop doesn't block games. I may not like the music or chairs, but I'll be hanging around there more often. Mainly to avoid The People's Library.

Maybe they'll block blogger next.

Tuesday, August 6, 2019

Maps for Days, Little One

There have been a few good comments for Little One, a farming game that uses vacuum mechanics. Currently I'll be getting a flat version of the map together to explore and make sure there are not any major problems with it. Later I'll add obstructions, ramps, and gameplay elements. The modeling program I'm using is Blender 2.8. After a slight learning curve, I've begun to enjoy the changes. Still have the hotkeys set to 2.7x and right-click for selection.

Controls will go through a small revision, making them more like an FPS and I'm hoping to have health/energy actually play a part in the game. The dialog system will be taken from Adventures' EDGE, along with a couple other things. Farm setup will still have to be done and I might give the player a few resources to make a few plots and other things to start off.

Critters and their products are still in an alpha stage, so that may take a bit of work. Open resources are in a collection, ready to be used when the base map is done. I'll setup chunks of the map so I can have better control of them. The skybox still has to be done, and I'll have a few plans to make it better in Little One.




The map is rather big and might be bigger in-game. Some sections subject to change.

Friday, August 2, 2019

Blender 2.80h no it's something different

Installed blender 2.80 on Thursday August 1, 2019. It looks nice, but over two dozen hotkeys have been changed. The entire program looks and feels like an entirely different program. Yes, I'd like to learn another new program. Fortunately, there are some things you can do.

Upon starting Blender from a shortcut (not a file) for the first time, you can choose the keymap mode.You can use right-click instead of left for selection, and use the old 2.79 keymap. If you'd like to change back later, the preferences have a keymap tab with a dropdown in the top center. Another option (windows) is to go to %APPDATA%\Blender Foundation\Blender  find the userpref and delete it, then re-open blender. The preferences are now found under the edit tab.

There are layout tabs at the top. You can find one that works for you, or right-click one to duplicate it. Modify the duplicated layout to something you like, then double-click the tab to rename it. Remember to save your startup file to keep the layout changes. This can be done under File >> Defaults.

Altogether, it looks nice, but there are new features and changed to old features to learn.

You can fine more detailed information on the Blender Fundamentals 2.8 playlist.

Monday, July 22, 2019

Engine Driven Mechanics.

Tried adding critters to Little One. The critters were supposed to use rigid bodies and get sucked up by the vacuum. Unfortunately, rigid bodies are hard to control. Most functions that move them ignore rotations, and the ones that allow rotations ignore collisions. So the critters; like the enemies, NPCs, and player; will use kinematic bodies. You'll gather eggs and incubate them to hatch the critters. Then the critters will produce resources and ammo for the player.

Why not just use kinematics for everything?

Kinematics need their physics programmed and tend to act like static objects when not moving. Their scripts would also have to run constantly, while rigid objects could be controlled by the vacuum when collected/shot. Having hundreds of scripts running all the time isn't such a big deal, but I'd have to re-do the mechanics already present. So I've chosen to just alter how the characters are used instead.

Thursday, July 11, 2019

Can't have lag from adding objects if you don't add objects.

There are many sources of lag in games. Most notable is skeletal animations. Loops, print statements, and loops with print statements can also add up. One thing most new developers don't notice, is that adding and removing objects can get heavy for lots of objects. Sometimes you have to add objects, like critters and bombs.

Of course, some objects warrant particle effects or sound effects when they hit. Objects, like bombs, don't usually stick around to play audio or particles.Removing objects early can truncate these effects, and programming a wait timer is something I'm too lazy to do.

You could always add the effect or sound objects and remove them after, but let's keep them in the scene. Better yet, add about 5-10 of these setups to the scene; inactive. Make a global variable in a pre-load script to keep track of which FX setup you are going to use. Before the attack/grenade/ammo is removed, move the current FX setup to the current object and activate it. Leave it there and update the current FX variable for the next FX setup.

By the time you loop through the setups, the first one should be done and inactive. Keep moving and using the setups as needed. Shuffling objects or setups can help for anything and reduces load since you don't keep adding these objects. You could even shuffle raindrops around the player for the illusion of rain if particle effects are unavailable or unusable for rain (some don't handle collisions and rain could clip indoors).

This option works for any kind of visual effect, from gunshots to bullet holes. Keep several in the scene and move them around / make them visible/active as needed.

Monday, July 8, 2019

This Post Sucks.

I was going to enter Adventures' EDGE into the fragment jam, but it does not qualify. None of my unreleased projects could be made ready in two weeks; except one. Using simple vacuum mechanics and a first-person view, this project could see a simple demo quickly. After, there will be enough of a mechanics base to quickly flesh a small game. There is a private collection on open game art just for this project.

The idea was to take some simple mechanics and a few things from AE and prototype a game. Then I'd use the curated collection from OGA to quickly pull together maps and content. After release, I'd upload any assets I'd made to OGA and make the collection public. There is a problem though, two actually.

My project qualifies for an unofficial OGA jam and stress causes chest pain. Add a busy week to that and I'm not sure how much I can get done. Yes, I want to see how much stress is debilitating, no I haven't got the resources for medical help. I'll shamelessly plug my Patreon page here, in case anyone wants to support my endeavors.

This year's plans include:
Completing Both games
Getting health insurance
Attaining some kind of income
Removing the useless things in my life
Or removing the life from the useless things

Actually, the vacuum mechanics are done and I'll be working on storage, water, and plant growth.

Friday, June 28, 2019

Map Hatter

The majority of the maps have been made for Adventures' EDGE. Since the player is in every map, I had to position them at the correct entrance. Therefore, I grouped the exits in pairs. Both exits to and from a map share the same group and have a node that I place the player at on map load.

First I gave each exit a letter in an exported variable, then I grouped them based on that letter (Groupa, ect.) and renamed the variable to the group. As you go through the exit, it will set the current map and exit to the values in the exported varables.

Export variables show up in a nodes properties, so you can edit them as needed without making several scripts or massive if statements. I'm only going to save the map exit/entrance data instead of the players position. That map will load on start and I'll avoid players getting stuck in walls if I have to modify the maps.

These will be implemented in the indev 1.00 version as they are ready for the build.

Future plans include
NPC generation and loading
more NPC features
Completion of current lazuna families
New lazuna families
A basic story intro (very basic)


Friday, June 21, 2019

Boot up the door locks

I'm focusing more on Adventures' EDGE. Mostly I'm testing how much stress causes my chest to hurt. Not the greatest plan, but it's for science. The doors are now working well, and will be found in buildings on the next update. The map enter/exit system is mostly done and the player is placed at the proper entrance (mostly). Now I just need to finish putting the towns together and set all the exit destinations. Then I'll work on making specific doors lock at night. Mostly I'll group them and exclude the player from being noticed by the door during those times. If the player gets trapped, I'll have the floor warp them somewhere (map entrance, I'm being lazy). Don't expect door locks on the next update.

Most of the maps are done, but some town data must be programmed and generated. Then I'll start working on the story some. I'll have to make more Lazuna and modify the skills. Sounds must be created and added. The title screen might get some changes, not sure what. Plenty to do.

Thursday, May 30, 2019

Sounds Raw

There are many ways to create sound effects. Recording different sounds and actions, vocalizations, Digital Audio Workstations (DAWs), sfx generators (Bfxr, LabChirp), and sound editing. One option most people are unaware of in importing files as raw data. This is easiest is Audacity.

Once you have installed and opened Audacity, choose 'File > Import > Raw Data' and choose a file on your computer.

There are some things to keep in mind.
Any file can be used, even video and audio files.
Avoid opening files larger than ten megabytes.
Files around five megabytes seem to have the best results.
On average, one megabyte of data equates to about 4-10 seconds of audio.

You'll usually see something like the image below.





This is mostly noise. You'll have to remove the noise to find any potential audio gems. Select a small sample of the noise with the selection tool. The selection tool looks like a giant "I" under the Analyze menu. Now chose with 'Effect > Noise Reduction'. A new  window will open.




Click 'Get Noise Profile' then reopen the noise reduction window. Copy the settings, or choose your own, then click OK.Next use 'Effect > Repeat Noise Reduction' or use Ctrl + R. You'll want to reduce the noise 2-3 times for best results. The noise reduction takes an average of one second for every ten seconds of audio.

The first file I used yielded no results, so I tried a second file.




Installation files and jar files seem to give the most sounds. You'll usually get chirps, horns, beeps, squeaks, rumbles, and heartbeats from this. 'File > Export' the audio as Wav format to work on later. Now you can split and modify the separate sounds to something you find useful.

Your results and mileage may vary.



Thursday, May 23, 2019

The walls are closing in

I finished modeling the buildings last week, but I've been busy with other things recently. The meshes have been imported int Adventures' EDGE and I'll be assembling the parts into the final scenes. Afterward I'll assemble the maps and code in the NPC loader and start wrapping things up.

It is slightly discouraging to work so long without any support. Maybe I'll look over my page and see if I can boost traffic to it. Perhaps I'll ask individuals for support. Just need something big enough to turn heads.

After building the maps, I'll have to code NPC loading. Then I'll start working on a basic save/load system. I'll fix some minor problems and modify the AI and battle systems a bit. Once those are done, I'll be adding more lazunas and making the skills look unique.

I've made a random word generator to help generate creature names. You past a list of words in and it uses two methods to generate a list of words. There are a few minor things I need to add before it is finished (bigger font, instructions, graphics) and I'll want to make sure it doesn't crash from someone adding too many words. It will be on my itch account once done. Check later today (5-23-2019) or next week, I have a few errands to run.

Thursday, May 9, 2019

Doing Buildings in Bleder

You should have a basic knowledge of Blender and Inkscape or similar 3D/graphics programs. Having house textures  ready will also help.


I tend to make both the interior and exterior of buildings as one thing. In the past games had to make interiors as separate maps (and use numerous tricks) due to memory constraints. Today this is not as necessary, so the interior and exterior can be on the same map or object. I usually do three objects; roof, walls, and floor. This makes things easier in single-level buildings. Multi-level buildings would have every level as separate walls and floor/ceiling.

Blender and Gimp are tools of choice when I make 3D objects. Inkscape is used to plan building layouts. I usually make a texture atlas for walls, roof, and floor. A texture atlas is a group of smaller textures in one bigger texture. They are mostly used for animated textures or conserving memory by having one texture shared by many objects.






First, let's use inkscape to create a building layout. I like to keep things simple as layouts can change when modeling. All it takes is a few squares/rectangles. Select them and use Path>"Object to path" then arrange and color them how you want. You don't need complicated layouts or special floor plan software.






I already have a land section to define the max size of the building and some objects to build the pieces from. Most of these were made from extruding cubes or planes and have been measured using the grid. Everything *should* fit together with little problem or editing. You will need to edit some things as you construct the building.






I start with the floor first. As you can see, I've already modified some of the faces to fill some gaps. The player won't notice that much. I selected and joined the objects together. See that red/white banded circle in the center? That is where all the parts will be centered later. Now I just tab into edit mode, press W and remove doubles, then remove the interior faces manually. Using the num pad, or number keys if you have set blender to emulate the num pad, you can change the view to make selecting inner faces easier.





I've unwrapped the floor faces and applied textures. Just choosing to reset the faces and scaling/moving them to a texture works well. Snapping the uv layout to pixels (in edit mode: UVs>Snap to pixels) helps.





I've extruded the walls for a single room to have tabs. This allows them to fit together once I join them. Now I'll remove double vertices and remove interior faces. Be careful you don't remove any faces you need. This will be done for each room, and then the rooms will be joined together. Next I'll begin adding textures to the walls and aligning things. Be careful with your doors and corners.





I've selected the top and bottom faces, reset their UV layouts, and scaled them on a texture to look nice. The player won't see them, but I might have damaged buildings later. Keeping things tidy and looking nice helps. Next, I select the large interior faces, reset their UV layout, and scale them to the texture I want. Scaling slightly smaller then the texture can avoid distance seams. There are three wall colors, and I color the rooms differently. Pink for bathrooms, green for storage/office/kitchen areas and blue for most other things. Feel free to have more colored walls in your atlas, I just like to keep things simple.

I tend to start by putting all the faces on the blue wall first and scaling them correctly. Then I can just select and move other room faces to other colors.

As you can notice, the faces I have left are doors and corners. For doors, I collectively select their faces, change the camera to face the door, and set the UV lay out by view (bounds). Then I scale and arrange the layout to the wall color needed. You can usually get both sides of the doorway at once and move the other side if it needs a different wall color.

For the corners, or slivers, I select them on one side or another of a larger wall piece and do the same thing. Just change the camera view and get the UV layout by view (bounds). Now just scale/move to the texture you want. Once the interior is done, I'll layout the exterior.



For the exterior I unwrap the faces individually by view (bounds). I select the slivers, or corners, with another face and unwrap them together. The door faces are also collectively unwrapped. Try to keep the corner slivers on the same side of another face where you can. Now I select each face and face section on one side and scale/arrange them on the brick part of the texture.


As you can see, there are seems between sections. Just select every other section, go to the UV texture, select and flip the UV layout for those parts. (S,X,-,1, ENTER) rapid succession, no commas. This solves the seams for the brick walls. There might be seams on the corners, but that's not a big deal. Once done with all the walls, the roof/ceiling is made in a similar manner.

After you're done with the walls, select them and set the selection to cursor (shift+s). Now go into edit mode, select all faces (a), and move the walls back flush with the floor. Using the grid, and snapping to it (ctrl), helps. Do the same for the floor, making it flush with the walls. This is best done in wireframe mode (z).

I usually select both and drag them back on top of the land area that was underneath them. This centers the objects together to reduce hassle on importing them to another game engine. More centering, less moving.







I've arranged/modified the roof pieces. Like the walls/floor join everything and remove doubles and interior faces. Then extrude edges to cover the center gaps and remove doubles. Select all faces and reset the UV layout and arrange/scale to the texture.

 


Now I'll select the corner triangles and set their UV layout to view (bounds) and scale them to look better. Afterward, grab the bottom faces and move them to the ceiling part of the texture. After centering the roof with the other house parts, I'm done.

I'll be making a navigation mesh and adding doors later. Since this is dependent on the building and how I'm going to use it, I won't be covering this part. 

Remember to select each part, go into edit mode, and normalize faces (ctrl+n). Having to re-import because you have a hole from an errant face is annoying. Giving your meshes/objects descriptive names helps. I'll probably name them Diner Roof/Wall/Floor/Navi for each part.

That should give you all tips and starting points to make your own buildings.








So many buildings. Gonna take a 3-day weekend.





Distance seams are seams that appear/worsen as the player moves away. This is largely due to textures from an atlas bleeding on the edges of a face.