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

Grain Drain

I added a save function to Little One. Most of the data was just easy to write to the file, but the buildings had to be formatted. Writing the dictionary for the buildings didn't take long, but I've had to add values throughout. A dictionary for the wild plants was also needed. Then I had to make sure the build platforms saved their own values while the buildings saved their values.


The fields seemed like a good start, both wild and domestic. They mostly went off without a hitch, but I had some bugs when I programmed out an exploit. Storage was next, and I gave it little thought before moving to the critter pens. Those pens had a few bugs, but the critters were missing. I had to modify the re-parenting function so they'd work, but the critters never seemed to load. Turns out, they did load, but kinematics and rigid bodies don't like each other and critters got flung.

Last night I checked to make sure everything was working, and the storage buildings were not. I was trying to get values from an empty dictionary within a dictionary. Putting the storage cell generator in the global dictionary worked, but I had to modify a few things. Today I added a few new grain plants just for something new. Most of the plants are modeled, but I need to tweak them.

After all that, I'm going to rest before I add more content. This whole project has taught me valuable lessons I'll carry into the next project.

Saving Games

Godot Engine already has a tutorial about saving games here, but it may not be for everyone. Basically, it grabs all the nodes in the “Persist” group and writes them to a file. It does this line-by-line, but you might just want to dump a dictionary to a file and grab it again.

I'm assuming you are using a singleton (preload) scrip that holds the game data. Singletons are scripts that load before any others and can hold persistent data for the game. Dictionaries are a complex datatype that can keep things organized. Since dictionaries are passed by reference, they are easy to keep updated.

func save_world():
    var saveFile = File.new()
    saveFile.open("user://savegame.save", File.WRITE)
    saveDat["Cells"] = cells
    saveDat["VacDat"] = vacDat
    saveDat["PlayDat"] = playerDat
    saveDat["Storage"] = storeDat
    saveDat["MatDat"] = matDat
    saveDat["BuildDat"] = buildDat
    saveDat["RingDat"] = ringDat
    saveDat["WorldDat"] = worldDat
    saveFile.store_var(saveDat)
    saveFile.close()
   
    pass

 Everyone will tell you that you don't need the "pass" keyword. They are correct, "pass" is used to skip empty functions and does no harm at the bottom of a function. I usually start two or more functions at once and use pass so I don't get errors or red lines as I work on individual functions.

First I created the "saveFile" variable and created a new file. Then I opened a file I intended to save to. The file does not need to exist if you are writing it, godot will automatically create a new file. It is best to use the "user://" location as this is a location that the game is allowed to write to. Now I assign the different variables I want to save to a single variable I initialized at the top of the script. Then the variable is stored in the file and it is closed. Remember to close the file to avoid memory leaks.

func load_world():
    var saveFile = File.new()
    if not saveFile.file_exists("user://savegame.save"):
        print("error, no save file")
    else:
        saveFile.open("user://savegame.save", File.READ)
        saveDat = saveFile.get_var()
        cells = saveDat["Cells"]
        vacDat = saveDat["VacDat"]
        playerDat = saveDat["PlayDat"]
        storeDat = saveDat["Storage"]
        matDat = saveDat["MatDat"]
        buildDat = saveDat["BuildDat"]
        ringDat = saveDat["RingDat"]
        worldDat = saveDat["WorldDat"]
    saveFile.close()
   
    pass

Now to load the data back. First we need to create a variable and open a new file. Variables initialized in a function can only be used by that function. Next, check to make sure the file actually exists, since we are getting data from it. I don't check to see if the file has any data since it should be in there.

Open the file and assign the data to another variable, the one initialized at the top of the scrip should work. Now we just apply the different key values to their respective variables. I'm not sure if different keys are passed by reference, but I think it depends on the variable's type. Finally, close the file to prevent memory leaks.

Feel free to reference godot's save tutorial if you want to try different ways of saving data.