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

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.