Basic Kanji Game Dev Diary

Hello, I am creating a game for my diploma about practicing kanji. The game is called Basic Kanji Game (a reference to the Basic Kanji Book). I am planning to adapt exercises for kanji practice in a video game format. Visually, I want to make something like a JRPG, but for now, the gameplay is like a puzzle game. The platform is PC. I plan to finish the game in April (2025). As a beginning, I want to demonstrate my current progress. I started working on this project and exploring Defold in February.
Video with current progress:

4 Likes

This week of development, I started with adding a new window in the UI - Inventory. I focused on its “details” part with info about the player’s resources. Also, I added there a “diary” button; I want to build my narrative around small texts in this section.

After adding some bits of data that will be changing through the game, I couldn’t escape thinking about saving and loading this stuff. So, I started to plan a whole save system for my game.
Firstly, I created a separate game object “SaveManager”; the plan was to give this guy information with messages so he could save it in a needed file. But then I found out that I couldn’t transfer a lot of info with messages, so I read about a possible solution - creating a Lua module. That’s what I did after.

I connected this module to some game object that would manage any info for its file. My rule for files is simple - one file for each map (collection/level) and one for the player, because I don’t want to transfer the player’s data from one level to another.
It was simple to save or load the player’s data, BUT for objects on my map, I needed something different, some other object that would store data from the whole map.
I called this object a “WorldObjectsManager”. From the beginning, this “guy” simply stored only data of those objects that sent him a “register” message, and when he received a message to save or load data, he did so. But there was one problem - too much unused data.
In the first try, I registered ALL objects that might be changed, and this solution made it impossible to save events, because I needed to store URLs of some objects and what should I do if this object was deleted or replaced by the manager? That is why I decided to give the ability to save the game only at specific points in levels, like flag of progress or rest room between level sections. But still, I wonder, what if the player decides to go back to rehash something? And then, for some reason, the idea of possible optimization came to my head: I can register only those objects that were changed and that exact solution will allow me to mark in the event that was triggered and the manager may delete it.
The player still can’t save when they want, but I think, it is allowing me to make saves safer (?)…

I will know for sure only when I put it in the game and make some tests, which is my next task, because all this time the save system was controlled by the player’s input and now I need to implement it inside the game’s world. That is the reason I have almost nothing to show in this note. The week was frustrating and hard - I don’t like working with game data :sweat_smile:

Ah, also, I made a scene manager to load or restart the game world - it makes it easier to restore changes on loading.

Thank you.

4 Likes

Hello, it’s me again!
This week I focused on three things: saves, localization, and inventory.

I finished working on the save/load system. It just does the thing and the player can save only at special places, such as sleeping bags and anything where you can sleep.there is nothing to show here, really…
image

Next, I worked on localization. I don’t have full scenery for the game, but from my experience, I know that localization of the game is easier if you plan it from the beginning by adding any text in the game. I decided to make a Lua module with a table of all localizations, each element being a table of texts in one language. When I need to use any string, I just address this module to get a localized string. One downside here: when I update a language, I must make extra updates in every script that uses localization, because… well, I don’t exactly know. Ideally, I can just change one link inside the localization module, which is global, and all other scripts will use the new link, but it doesn’t work like this - I have a little problem with understanding this moment in Lua. But here are the results:
image
image

And the last thing I worked on was an inventory.
I am planning to add different items to the game and for this, I decided to make an inventory. While playing, the player can buy a new backpack to have more space in their inventory. On the left, you can see filters; by clicking it, you can change the appearance of filtered items (for now, it is only in plans). In the center, I placed inventory cells. I was just messing around with the form of it, so it might change in the future. And on the left of the screen is an information zone with a diary of our character and information about the chosen item. Now you can pick up items and even use them to restore some resources, but I don’t have sprites for such things yet. Here is the image of the inventory screen:

Next week, I am planning to make some changes to the basics the gameplay and finish working with items for Level 1. Also, I found an artist for this game, so visuals will change soon.

Thank you.

4 Likes

Hello, today I’m going to talk about my (mostly) programming work in this project.

Firstly, I decided to clean up my folders and improve the project structure. While doing it, I truly understand why strings are pain in programming, but, for example, to get a node in gui_script, I must use string to get a node by name :frowning: I decided to make script-local constants with strings, so it will be less painful in case I need to change some strings.

Secondly, I implemented a resource similar to ammo - inks. Player use them to draw, so sometimes I feel like I’m balancing this game with Resident Evil as an example.

Also, the new puzzle is almost ready to be used in the game. It has no sprites yet, but all algorithms are done. This puzzle literally similar to puzzles from RE where you press buttons to maintain liquid in a container. I’ll show it when the sprites are ready…

Lastly, I made a step into the future by planning the next levels and content for the game. The narrative part was hard for me to plan, and here “Gamedesign” by Shell helped me a lot to at least start working on a story and the game’s world.

2 Likes

Hello, almost one month I have been working on a simple dialogue system and small improvements.

I will start with a dialogue system here. I had an idea of window for dialogues, which adapts its size to the size of the text, but then I decided to make a fixed size of the window. Firstly, it was hard to make all the logic because text behaviour depends on its content, which changes a lot through the game. Secondly, I then decided to look at this problem from the design point of view: it would be uncomfortable for the player to have a dynamically-changing window while using dialogues.

Also, dialogue must have some options for player to choose. I knew from the beginning that the dialogue system might be used just as an information window for events like “You gain 30 coins!” where the player presses one button to close the window when ready. For these reasons, I made dynamically created options when the dialogue needs more than one button for the player.

All my problems were solved when I decided to make a static-sized background for the dialogue phrase and its options.

The result looked like this when I finished all the logic(probably I will redraw all the background here):

But the font was hard to read, so I decided to find a new font! My choice was - Cosmic Sans MS Pixel

Now all the texts look more readable:

After that, I wanted to finally make improvement in visuals.
Here is a new look for the ink bar that shows the available amount of ink for drawing:
image

And a this is the sprite for the pack of ink:
inkPack_25-export

This is it! Next, I am planning to make the first use of the dialogue system.
Thank you.

3 Likes