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.

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.

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.

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.

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.

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.

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.

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.

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.