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.

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.