In last week’s report for my second Freshly Squeezed Entertainment project, I was updating my project’s infrastructure and figuring out the way I wanted to persist data from one play session to the next.
I found myself adding needed functionality since then.
Sprint 5: Pre-production and initialization
Planned and incomplete:
- Finish initial design document
- Create save file
- Create player character
- Create [redacted] environment layout
Last time, I realized that I couldn’t move forward with my save file work until I had something more substantial to save in the first place.
So I focused on creating the player character. I wanted the player to be able to customize their main character to their liking, so “Create player character” above has the following tasks:
- Main player character gets a default name, nickname, gender, pronouns, portrait
- Player can enter custom name and nickname
- Player can choose pronouns from He/Him/His, She/Her/Hers, They/Them/Theirs, and (perhaps a few other major ones?)
- Player can choose portrait from list
- Create portraits
Some of these tasks turned out to be quite large. I did not do anything regarding portraits because my time was spent focusing on creating the ability to modify the player’s name.
If I was using an existing engine, much of this work would likely be provided for free with some framework. I would throw up an input box and be done.
But I’m using my own code that I’ve been working on for many years, and I didn’t have a ready-to-use text input box, so I would need to implement it myself.
In a previous project, I had hardcoded a text input box to let a player name a save file. My implementation was a little hacky, but I only needed it in one place, and the code was fairly isolated.
For this project, I knew I was going to need such functionality in more than one place, so I needed to create a reusable widget. I test-drove the functionality in, which required a few changes to some lower-level code to support it, and by the end of the week, I had a text widget that I can throw into my existing menu code. With it, I had the ability to rename the player character.
It’s exciting because from now on my own code lets me throw a text input box into a menu for free going forward, and all because of the investment of a few hours.
I expect it will take me almost no effort to change the player’s nickname, but I did find myself thinking, “What’s the point of the nickname?” Originally, I anticipated the nickname being a fun bit of personalization you can give you and your party members that otherwise serves no purpose. If you can give yourself an arbitrary name, then the name already provides personalization. So is a nickname redundant? Do only certain characters in the game refer to each other by their nicknames, and is that compelling enough? Should nicknames not be player-chosen but show up later in the game based on how the characters develop, such as a character who learns how to swim really well being called “Fish” or “Froglegs” or something like that?
It seems like a small thing to worry about, but there are clearly some questions here that are relevant to the game’s design. I might hold off on nicknames until I answer some of them.
The neat thing to see this week is that a lot of hardcoded things are starting to become less so. For instance, I started with a hardcoded text box that introduced the player. Then the text box and associated menu is generated depending on which script is being shown. Now the game keeps track of which script to show, so that when the customization menu closes the game can pick back up from where it left off. In the coming week, I anticipate that I’ll be able to demonstrate saving and reloading a game at an arbitrary point so that a dialogue being shown can be reloaded.
This game is going to be a lot more content heavy than my previous games. The work I’ve done so far may sound overly technical and even unnecessary in a world with free game engines and tools, and I’m getting impatient to put some game play together, but I’ve been investing in making the development of this project easier and faster for myself, and it is already paying off.
For now, I am very interested in making sure that players of this game can see themselves and their friends in it, and so allowing the player to customize their characters to represent themselves is important enough to not gloss over. I just hope that with my limited capabilities and resources that I don’t do too little.
Thanks for reading!
Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!