And everything changes again.

I LIVE!

A week after the Covid-19 lockdown my laptop's HDD died, and swapping it out was a pain. A few other problems arose and my three-year-old HP laptop dies completely. I was able to cobble together a desktop without internet access (no service where I live). My cousin's phone gets crap reception in my room (but it gets reception); a dongle and tether later I'm able to access the IRS webpage.

Let me spell it out.

Due to my heart condition\s, and the Covid-19 crisis, I'm unable to have gainful employment. I'm also not disabled enough for any kind of help (major vital organ, really?).

My heart is good, just has some electrical problem due to a previous surgery from birth, and other developing problems (my left arm is a bit numb).

I have a lot of aggression. I'd consider it "anger issues" if I didn't have control (I'm being reminded that laziness isn't control). Sterilize-the-planet levels of wrath. This aggression is great for my focus, not so great for my health or control. After the loss of my laptop (and most of my data) I'm livid.

The government stimulated me, so I have a new laptop. I'll spare the details, it's last year's model so I could keep some money. I've meds to buy and plans to lay.

Now where was I?

Little One may have had some files corrupted, I need to re-assemble the project from backups (Always keep multiple backups). I've got some ideas for Adventures' EDGE (I didn't plan well enough for that) and ideas for future projects.

For now I'm just going to try putting all my focus into my projects, and hoping it doesn't hurt me too much. My focus and aggression can cause chest pains, but I'm not sure the precise trigger. Time for some pomodoro rushes.

Pomodoro rush:

The use of several pomodoro intervals (four or more), each focusing on a different task (two or more) in rotation. Breaks optional, but suggested.

So now, my plans:

Little One need to be brought back up and finished, need to ease into that.

Adventures' EDGE might be going 2D. It'll probably get a turn-based battle system as well.

Resources (2D & 3D) might be created and uploaded to OGA.

Eclipse

This post will contain gamedev tips, some concerning Godot, after my depressing rant. I'll pound the area around the rant with some octothorpes.


###   ###   ###   ###
Shortly after the corona virus restrictions went into place, my laptop died. First the HD, after I replaced that the wireless and memory failed. In the end my HP laptop fully failed and I lost most of my files. Thankfully, I had backed up the most important files.

I pieced together a desktop running windows 7 for now. I don't have the money to get internet access where I live, and last I checked I don't get service here anyway. I live in a dead zone and have to choose specific phones and services to even get a small signal. After using my phone at a WI-fi hot spot in town to gather drivers and service packs, I was able to run the godot engine and play some games. During some gameplay on my cousin's Xbone, we discovered his phone gets signal in my room, in a very specific area. I'm now connected to a hot spot that isn't much better than dial up.

I'm going to gather my files and try working on games again soon, but with my more limited resources, I'll have some difficulties uploading updates until I can either get better internet or a laptop. It doesn't help that my focus seems to cause delayed chest pains. Since I have no idea how to avoid that, I must fight my own coping methods, ignore the pain, and push myself. While not the best idea, I haven't many other options.


Aggression is great for forward momentum. More dangerous and stimulating than coffee.

###   ###   ###   ###

Since I'm slightly depressed I guess, not feeling myself, I'm going to take a break from Little One and fiddle around with Godot some. I'm interested in procedurally generated maps, mostly 2D tile maps. There are great tutorials on using noise to make these maps, mostly.

I found using the help search in the script section of the editor rather useful. Mainly I just generated a flat map that sets either dirt or stone based on the height. This is slightly randomized and doesn't use noise, but noise could be used. I've got a function that makes noise for the caves and removes tiles based on the value when I get the 2d noise of an area. It has seriously reduced the amount of code I need and the map looks better.

For ores I'll be using different noise, choosing an area, and setting ores by height. Overlapping the ore heights will make things look more natural. I'll mostly be replacing solid blocks in chosen areas, with numerous areas randomly sampled or sampled through another method. Once I have the noise modified the way I want, I'll use different noise to shape the hills.

The map will be in three layers; land, fluids, and backgrounds. Fluids will be randomly placed and filled, but will also rely on the land map for placement and flow. Trees and plants might be on the BG area. I'm not concerned with good-looking details, and much of the gameplay will be a mix of minecraft (water,trees), starbound (mining, tools) and terraria (combat, weapons) with some mechanics from interesting mods and myself thrown in (tool modifiers, bombs).

For falling blocks (sand, gravel) I'll most likely remove the tile and add a kinematic object that becomes a tile again once it stops falling. Liquids will be handled as closely to minecraft as possible. Block placing will remove liquids and infinite pools will be planned. Mostly this is because I'm lazy and I don't think godot has fluid dynamics.


There are ideas and plans for this project, but for now it's just me tinkering. Now for some tips.

The noise seed can either be randomized, or you can use a specific world seed.

Write different noise functions to generate noise for different parts of map generation.

Creating functions to generate noise based on parameters will allow easy modification.

Tile Maps can use kinematic physics, or the parent  node's physics. This should allow an area to be used for the liquids.

A tile map's tile set can be changed or modified during game play.
 Swap a tile and nobody cares, swap a sprite in the tile set and the whole map updates.

"invx128y32" Use similar keys in a dictionary of inventories to keep track of chests at almost any position. I just hope some player doesn't try filling the world with chests. X & Y should correspond with the chest's position.

If the map is modified by the player (mining, bombs) write a function to check surrounding tiles for any actions they need to take (flowing, falling).

Liquids should try flowing down first, then sideways. I'll most likely place iquid tiles below and flow tiles to the side

Create dictionaries and lookup tables to keep track of tiles and what can affect them.


And finally:

Map generation can take some time with all the loops and actions. Rendering the map as it is generated can cause even more lag and freezes.

Set the tile map's visibility to false before generating the map, then back to true after. The map generates far faster with no visuals.

The Wall

Every single time. Every Single Time!

I keep finding new bugs in Little One. Recently I realized there were problems with the critter loading and egg dropping. It took a day to fix them, but I wanted to get so many other things done. The object loading also caused a bit of lag in the beginning, so I distributed the loading over several frames. Basically, instead of looping and loading a list of objects at once, I just loaded one object per frame. Many process functions are just infinite loops.

Constant bug-fixing is starting to get depressing. With a library of resources and assets, game creation might be faster. Sure there are many different asset sources, but the assets must fit with the game you are making. Some assets are too common. Dozens of barrels and crates can be found easy, but a fully animated character or enemy is rater hard; especially if you need a specific design.

I'm considering re-using assets from my projects, and even releasing them under permissive licenses on open game art. Asset creation can become boring if you need to make a lot of assets. Creating assets randomly for others might not be the best idea. Having a plan, or creating a full asset set is a better idea.The main reason I prefer to use my own assets is the licenses. I don't mind giving credit, but I don't want to forget to give credit.

My plans after I'm done with Little One will be to slowly release select assets first. I'll focus on planning a few different games with cross-asset use. Minor assets will be modified or created during the planning stage. These assets I make might be released publicly before the game is done.

Every month Little on isn't completed feels like a failure. I keep plugging away at it, but the downloads still remain at zero. If others did play my game, they might not like finding crashing bugs. While I'd like to have help finding bugs, I know there will be toxic people who would hate finding a bug in their game. That could become even more stressful.

Size and complexity also makes game creation take longer. Lack of planning also makes game development harder. I'm going to try detail-planning my games and trying to simplify the mechanics as much as possible. Useless or over-complex things will be dropped or modified.

The next game I'll be working on will probably be Blue Bloom. This will be the game I create and refine my planning process. The idea will be to use numbers under ten (0-9) to structure the planning. I think having restrictions from the start might help the planning process.

There is a link here where you can get Little One. Get it before it updates and all the good bugs get patched.

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.

Naughty Plot

This post will cover ideas and tips for the more mature game types, however I'll be avoiding vulgar or descriptive bits. Not like I'll ever make one and most of these tips can be used for virtual pet games.

Rub-a-dub:

Touching, poking, or petting is relatively straightforward. Either an invisible collider or area is attached to a bone and may have metadata attached. This attachment is usually set to detect mouse or touch inputs. Using signals connected to a script can turn that input into variable values to change a character's mood. This is usually the easiest mechanic to make, but the longest to perfect.


Designer "pet":

Character creation systems are nothing new, but how they are handled relies on numerous factors. Doing them in 3D is easiest, but layering sprites or using 2D animation skeletons allow customization in 2D games as well.

You'll first want one or more protoform characters without hair, skin color, or defining features. Their looks can be altered easily with textures and extra items (accessories). Shape keys (vetex animations) can be used to define other body features (nose, hands, etc.). Using clothing textures can be faster than 3D clothing, but can have a few restrictions. 3D clothing can allow inside objects to clip outside. With just a few characters, textured clothing offers few benefits, and combining both can be useful. If there are more than ten animated characters, clothing textures can help with lag if you have it.

This mechanic has many parts to it, don't become discouraged if things don't always work as intended.

Pose this way:

Custom poses can be done in most game engines. There are several ways to do it, even if the engine doesn't allow direct access to the skeleton, blending animations can be useful. Godot allows skeletal access and bone manipulation via script and allows animation blending. Creating a pose can be done by making a dictionary, using the bone names as keys, and adding the bone vectors to it.

Poses are nice for a screenshot, but what if you want the player to make their own animations? Godot allows full access to the animation data via scripting, and should be able to create and save an animation. Of course, building and saving the animation(s) would involve even more work, so providing plenty of animations yourself is a good idea.

If an engine does not allow access to animation data, consider hacking your own in with dictionaries or json files. The mark of a good developer is how obstacles are handled, not avoided.


Make the camera dizzy:

Camera controls can range from great to abysmal, which is why I like first-person cameras. For any "pet" game, it is best to center the rotation nodes on the character themselves. Have two spatial nodes for 3D rotation (and rotating them on individual axes) gives the easiest control. Remember to add a camera reset button to reset the camera position and node rotations (in case the player messes up the camera).

Camera zoom can be done either through movement, or changing the FOV. Checking the camera's distance from a specific point (one of the axis or gimbal nodes) allows you to set limits to how far the camera can go.

This is relatively easy to implement.

Mods mods mods:

Creating or adding mods to the game is usually *technically* possible. Since any engine *should* be able to read their own data formats even after compiling. I'm not entirely sure how to go about it in godot, but there is a way to load, modify, and save almost anything within run. The main problem is making sure resource scenes have everything they need and are organized. While I'm not sure how Godot feels about zip files, a json file in a mod folder could help.

Here are a few ideas:

Putting the mod and associated files in a folder with a json file. The json file would tell the game about the mod, resources needed, and type of mod (character, object, prop, scene).

Having a zip file, with a json file. It's really the above tip, but zipped.

Using  self-contained scene file and putting these files in the appropriate mod folder.

Using a scene compiled to a pck file by the engine, however I'm not sure how this could work. This could make mods easier to load.


###   ###   ###

Warning: inhibitor 34 unstable

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.