Animations can go bone themselves.

Skeletal animations tend to have some drawbacks. Aside from being one of the biggest drains to framerate, creating them is as complicated as modeling a 3D character. Once the skeleton is made, and the object skinned to it, creating the keyframes can be a bit daunting. Creating the animations isn't too hard, with a few tips.

0: doing things by the tens:
You only need to make a keyframe at specific intervals. I suggest every five to ten frames. (1,10,20,30,40) 

1: Most things can be done a few bones at a time:
Head bobbing and tail wagging can be done after the major (walking) animation is done. This also goes for arm swinging.

2: ANIMATE ALL THE LEGS!:
Yes, do them in pairs. Each leg of a pair should have the same exact animation, but each pair should have a different animation. Front pair of legs should cycle forward while the back legs cycle back. Then just grab opposing (front_left, back_right) and drag them back two keyframes. Then take the keyframes that hang off and move them to the front. This offsets the leg animations.

3: Bugs are not that hard:
For 6-8 legged creatures, assign pairs of legs to a bone. Assign the front and rear left legs to a left bone, then the middle to a different left bone. For spiders, left legs 1&3 to one bone and 2&4 to another. Now just animate those bones like you're rowing a boat. Simple and creepy.



Of course, when you import them to a game engine, they can still get wrecked.

Remember to have the mesh and skeleton centered (world and object) properly to avoid some pitfalls.

If the characters need to be rotated, apply transforms and delete older versions of the export and import files (to be safe).

If it works, save the animations files before you break it.

Keep the hierarchy as much as you can when preparing the actual character for use in-game.

Keep calm, or find a punching bag.

What a suck up

This entire first month was a bit rough so I haven't done much on my projects. I'm attempting to add new habits (good ones) like drawing. Gardening is something else I enjoy and I'm getting prepared for spring, when I can.

For this blog post I'll be going over a few things from Little one, such as the vacuum, crafts, and material drops. Should be a lot of fun, or at least interesting for other developers.

Vacucel:

The vacucel is the item that vacuums and collects items. Objects that can be sucked up are in a group called "Vacup" and they're all rigid body objects (nodes). In the player's script I use apply_central_impulse(power)  to pull or push the objects. Power need to be a Vector3(), so here is how I calculate it:
var power = (grabber.get_global_transform().origin - scIns.get_global_transform().origin)*-200
Grabber is the node (area) that collects the objects. There is a spatial node that I "emit" objects from. The scIns variable is the object being "emitted". This "shoots" the object after it has been added to the scene.

To attract objects, I have another area on the vacucell that adds objects that enter it to an array (list). When the mouse button is clicked, I go through the list calculating and applying the power. I replace the scIns variable with the objects I'm looping through and change the -200 to a positive number. Care has to be taken on how much power is used, lest the objects go flying around.

Crafting:
I'll start with a craft recipe:


partCraft["SignalRadio"] = {}
partCraft["SignalRadio"]["Iron"] = 2
partCraft["SignalRadio"]["Plastic"] = 5
partCraft["SignalRadio"]["Silicon"] = 1
partCraft["SignalRadio"]["Carbon"] = 1


There is a dictionary of the materials that uses the material names as the keys with the amount being an integer. I just loop through the partCraft["SignalRadio"].keys() and check if the same key in the materials has enough. When all the material needs are met, the item can be crafted with a single click. Then the materials are subtracted and the menu is refreshed.

In my next projects, crafting will have more limits on materials, this one would be fine though.

Material Drops:

These are spread throughout  the map, three for each material. A few should drop items each day. Items dropped are children of the material droppers. These child objects are counted and that number is saved. On load the material dropper will drop the saved amount of items.

Code Down Vector Y Up

That's how we develop.

This month has been slammed to the wall. I've just now gotten everything corrected from how the holidays wrecked it. Since the year started in such a [expletive] state, I'm going to finish up Little One. It didn't help that rushing myself can cause chest pains and I don't know how exactly they are triggered since I'm keyed up with no pains right now.

For Little One I've got some things added. Thorns (they hurt) are added, but I haven't spread them around the maps. Grass is mostly done, but not in the map yet. There is a tent with beds to sleep in when you click on them. Press forward [w] to get out of the bed. The beds speed up time, restore health, and fill energy. I'll probably work on the beds a bit more later.

I've modeled most of the parts for Little One. They'll be added later, but at least I only have to make the textures. These parts might also be used in other games I make. Little One also has the lose conditions added, but I've unlinked them since there is no way to avoid those conditions.

After I add the parts I'll finish the plants and start on the critters. The building upgrades still need to be modeled and added. I still have to do the opening, ending, and possibly losing images. Beasts will also be added, but that could be a while away.

For the thorns, I used a multi-mesh node to populate an area with the meshes. An area causes damage when the player enters or exits. The grass has a material with a greenish layer. When it rains I intend to have the grass turn greenish, then slowly brown over the days. This will be done via a single copy of the material. Since materials are shared between objects, modifying one copy alters all of them. Materials can be copied as a new instance that is not connected to the other copies if needed.

Mechanically Disinclined

You've got a fantastic game idea, don't you? Listed all the things you want to be in it and put in a little planning, right? Maybe you've planned the maps and resources needed as well? Now you are just sitting there, wondering where to start. Enemies, crafting, inventory, which mechanic should you start upon?

The place to start in any major project is the foundation. In games, that would be the core mechanic. There are several types of mechanics in games, core, supporting, challenge, and extra/other. I'll go over these mechanics so you can better identify them and choose the actual core mechanic.

Core mechanics, although there is usually just one, are used throughout the game; or to beat the game. Minecraft is obviously crafting, since you have to craft tools, weapons, and armor to progress. Mario games have Mario's base moveset (jump, punch, kick) as the core mechanic. Fighting games have character movesets as the core mechanic. Can you guess Pokemon's core mechanic? It's not capturing, but battling. You have to battle to progress or win the game, like any base RPG, but capturing is needed to get more characters to battle with. Capturing is a support mechanic.

Support mechanics are used to support the core gameplay. Minecraft has mining. You have to mine wood to get materials to craft tools for more mining. Mario usually has support pickups (mushroom, fire flower, tanuki) while most fighting games just use the core mechanic. With Pokemon, capturing is the support mechanic to get characters to battle with (no capture nuzlocke anyone). Most challeng mechanics are used to control the games pacing or make it more fun. If you could just beat Bowser without collecting the macguffins and unlocking the worlds, Mario games would be boring.

Challenge mechanics are used to give the player a challenge. For most games, this is usually the enemies you fight. Sometimes the challenge mechanic is a support mechanic as well, like in Pokemon. Minecraft would be even more boring without the mobs to kill, but it would still be nice to explore. Timers, puzzles, goals, and achievements are usually challenge mechanics. Anything that is used to determine/cause a losing scenario is usually a challenge mechanic. Player stats are a great example of a simple challenge mechanic.

Now for the final type of mechanic. Extra/other mechanic usually don't affect gameplay much, but it can add to it. For Pokemon, the trading mechanic is extra. All the Pokemon could be in a single game, but trading was added to expand the game. Similarly, items in Super Smash Bros. and Mario Kart are extra (but fun) mechanics. Wile these extra mechanics add to the game, too many can bog down the game or expand development times (going to ludicrous dev time). If it isn't a core or support mechanic, work can usually be delayed upon it.

Some things to consider about mechanics. Some games are just a core mechanic (fighting games). The advertised mechanics are not always the core mechanic (pokemon). Some games can have either two core mechanics, or core/support symbiosis (minecraft) where the core and support mechanics work together to hold up the game. Core mechanics can also support other mechanics. Extra and challenge mechanics should be the last worked on and the first to be cut. Online play is almost always an extra mechanic. Inventories are almost always a support mechanic.

You should almost always work on the core or support mechanic first. As a developer, you can give yourself the macguffins needed to use the core mechanic. Unless the core mechanic really needs a support mechanic, start with the core mechanic. Mechanic don't have to be perfect, just working; polish can come later.

Little One just had two main mechanics when I started, the vacucell collector and farming. Item collection was the core mechanic and farming was actually supposed to support a challenge mechanic. Those were the first two mechanics I started with.

Blue Bloom has several mechanics, more than Little One. I was confused at first what mechanic to start upon, but crafting will be the core mechanic. Resource collection will be a support mechanic with the flora and fauna being challenge mechanics. In fact, Blue Bloom will have several challenge mechanics.

A Fungus Among Us

I'll be starting on my two-month project, but it may actually take three or four. It's a sci-fi "horror" game called "Blue Bloom". You'll have to clean a planet of an infectious, parasitic, fungus while stationed upon an island. This means that most clean-up efforts will be long-range. Cures will have to be analyzed and built via a crafting and modular building system.

This project will use resources from my two previous projects, along with adding more resources. while it will draw from previous experience, I'll be learning new things as well. Currently I'll be setting up a basic player and testing distance. I'll be adding a LOD system to this game for optimization. I think large faces render slower when they are close to the player, so this should break that up.

There will be several different spawn caps for creatures, both soft and hard. The soft cap is just for normal spawning, while the hard cap controls "event" spawning. Since creatures may be spawning in/out regularly, I'll be using signals to coordinate the spawns; reducing lag. This entire project is me seeing how fast I can put a game together when I have numerous resources.

Little One will still be worked upon, and updated. Many ideas from that game will be adapted for Blue Bloom. Not only the vacucell, but the crafting materials as well. A few materials will be added in Blue Bloom, making the count about twelve or more. If I use preexisting resources, most of this project will just be coding.

The map for Blue Bloom will be comprised of smaller scenes, also comprised of smaller scenes. Each map piece will be made of cells. The idea is to make a handful of specific cells and use a lot of them to build the map pieces. These pieces will be controlled via scripts to change their mesh or visibility as needed. I think the map will run a bit faster if I set the cell visibility even outside the player's view. I'm not sure if the creatures will have navigation abilities, but I'll try to include that from the start.


The map will be 8x10 areas in size and the areas might be roughly 10x10 cells. That's 800 scripts running a loop of 100 each frame to handle cell visibility, or is it? If I only check one cell per frame, I eliminate all those loops. The script can get through all the cells in 1.5-3.4 seconds (depending on frame rate). This will cause some problems with low-frame rate or lag.

While a single script could handle all the map areas, iterating all the cells of all the map areas every frame or X-frames could cause lag. To reduce even more lag, I might just check the nine map areas around the player.
To do this, I'll probably surround each map area in an area node and give them all grid coordinates. When the player enters an area, the current grid coords will be changed and I can write a script that organizes and acquires the map areas.

Creatures will change their own animation progression and visibility since they'll all have scripts. They should spawn within a pair of ranges from the player, to be changed by other factors. Any critters spawned will be direct children of their spawner and should only travel a set distance from their parent before returning/despawning. To keep the pressure on the player, I'll be playing fast and loose with the spawns.

Major hard points will include the sky, navigation, creatures, collision shapes, and map handling. I'm in no way ready for this project, but I'll be doing it anyway.

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.

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.

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.

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

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.

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.