AZL GAME DEVLOG 06/21/2025
==========================
I haven’t been on Hive much lately. I wrote and published several books, created a Redbubble account and built a portfolio there, and then I sold a bunch of my stuff and bought a Steam Deck, thus ending my productive phase and transferring into lazy gamer mode.
After playing through the first two Zeldas, beating Trine 1 and a few other games, I found myself searching for the perfect game. Buying games with my fingers crossed got expensive quickly, so when I ran out of cash and still hadn’t found what I was looking for, I decided to make it for myself.
* * *
INITIAL CONCEPT
===============
To start with, I wanted to make a game that had an open world map with villages and dungeons, etc. Zelda 1 and 2, Final Fantasy VII vibes, but I wanted to implement a few other concepts such as Diablo-like treasure storage, Trine-like character swapping, Rogue-like overworld combat (at least in zones) and some features I haven't seen in other games, such as:
* The Trine-like character changes would have a different element. Instead of switching between three characters strictly for their different skills, the player would actually shift dimensions.
* The map/scene changes in appearance. Sometimes there may be NPCs that are useless in one dimension but quite powerful in another, or there may be chests or obstacles in one dimension that aren't present in the others
* The character would have a different appearance and abilities depending on the dimension, as would enemies and NPCs.
* Player can create item caches in empty treasure chests. They have no limit on holding and once created, they show up on the map.
* Local AI for intuitive conversations. I haven't yet decided whether or not to do this, but the idea was that the player could type their own message when interacting with NPCs, and NPCs would basically have a class and location that would determine the voice of the AI response. Game critical information would be stored in json format along with information about when and how the information should be shared, and by who or what class of NPC.
* Each NPC would have in their metadata a list of related NPCs. If the player acts badly towards an NPC, their family will hold it against the player and be less helpful or forge a vendetta, friends have 65% chance of following suit, and enemies have a 40% chance of joining the player or helping them.
* Local AI for generating levels.
* One of the key elements in my plan was that I don't particularly have interest in making a game to sell it. Although I will probably put it on the Steam store when it's done, I really just wanted the challenge of creating a game, and the joy of playing it myself...which would be a little bit lame if I personally designed every level and placed every object. So if I take this approach, a local AI engine will generate the levels from materials and information in the source files. Each area will be represented by an entry in another json file.
* * *
\*\*\*
FIRST STEPS
===========
When the idea first hit me, I wanted to write the game code in something that was at least vaguely familiar, so I did the first start in Python, using the Pygame library, but after about a week I discovered the Arcade library, which had many functions to help with sprite animation and menu creation. I restarted with the Arcade library and had a working Start screen which took you to the screen to Start New Game or Load Saved Game. If you tried to load a saved game and no save files were found it would take you back to the selection screen. When you selected Start New Game you would enter your name just like in all the old RPGs and it would create an entry in the saves.json file. This file stored all the player data including saved state, which made it simpler when it came time to load the game - whether you were loading a new or saved game, it always loaded from the json file - but in a new game, the default start location was automatically appended into the json file when the player hit accept.
Anyway, that was working decent and I did have a character moving on screen by the second day (I only work on the game usually from 10 PM to about midnight), but I could already feel that developing a concept of this size in Python was going to impose limitations that would cramp my ability to develop the game I want to play.
I tried Unity. I took the free courses on developing in Unity, but they left my head spinning and, even after I'd completed several of the tutorials (which are really nice, by the way), I still felt like it was too much to learn. I wanted to get this concept out of my head and working in the quickest way possible. I bought a copy of RPG Maker MZ, but without much time spent on it, I realized I was going to feel too limited in this platform as well, and that, like Python, patching over the limitations was going to add challenges in the later phase that would most likely lead me to quit. I tried a few others I can't remember, and finally realized that Unity was the engine I would need to learn in order to bring my vision to life.
* * *
WORKING IN UNITY
----------------
Unity is like a giant tool box. It contains the tools you need to create better tools, but leaves that part up to you. For example, when you make animations of a character walking left and walking right, you don't just add them to a character object and call it a day. You have to add them, but afterwards, you still have to define how the software will transition from one animation to another. Although this creates a steeper learning curve, it is precisely the freedom I need to create the depth of characters that I want - it is the way around the RPG Maker MZ goofy looking combat sequences, although it means I'll have a lot to learn.
I took some free sprite sheets from online and spent a night just learning how to slice the sheet and build animations. By the end of the night I had a character walking around on a blank screen, but it wasn't _my_ character. To get that, I was coming to realize that I would have to learn a thing or two about pixel art.
* * *
SPRITED AWAY ;)
===============
In the earliest phases of testing, I managed to get a character animation moving on screen - but when I started using sprite editors and pixel studios to create my own animation frames, I found myself up against a breaking point. I don’t have any history in creating pixel art and will already be picking up a ton of new skills to pull this all together, so I had to pivot to a new plan - I would create my sprites by hand, the old fashioned way.
I created a partial set of sprite sheets animating the bare minimum a character would need in order to believably walk around in the game.
SKULLIE\_WALK\_LEFT\_01
SKULLIE\_RUN\_LEFT\_01
SKULLIE\_JUMP\_LEFT\_01
Notice, although this jump appears to be super lame, I tried to center each frame around the hips for this one. This means that seeing it on its own and seeing it animated in the game will be different, as the character will move upward on screen as this animation plays out. Timing the jumps to land when the animation lands will be a challenge when I come to it, and currently I'm not sure if I'll adjust the jump to match the animation, or if I'll adjust the animation to match the jump, but probably the latter.
SKULLIE\_DEATH\_FLIP\_01
I created Skullie, the above stick figure, as a reference to create basic animations, I would then trace over him to create new characters. This way I could build a single "characterMovement" script, but all the animations would have the same number of frames and fps rate, so I could write the characterMovement script once and just reuse it for all the different characters. It's not as fast as generating sprites the way we can do online, but I understand the basics of how to draw, and I think hand drawn animations in a video game made just for me would be super rad. I think pixel art is super cool, but it also is a whole new form of art and I don't want to halt development to learn it.
I don't want standardized animations to make the game feel dead, which is why each movement (ie walk\_left) is numbered. Once things are settled in and basic functionality is achieved, I will animate different walks, runs, etc, and update the character movement script to cycle between different walks either randomly or based on various criteria like location, light quality and status effects etc.
GLITCHYBRO\_JUMP\_LEFT\_01
For final processing of the sprite sheets on a super zero budget, I scan them in as pdf, then save as png. I open the png in Paint, increase size by 500% and save as gif. Finally, I save it as a monochrome bmp before scaling to 20% (back to original size) and saving as png. This gives me a strict black and white base image with decent lines. Then I have just been using Paint to fill in colors. It’s a bit tedious, but it’s free and so far I’m still enjoying myself :)
UP TO DATE
==========
That's it for now, that's all I've got. So far I've been using a piece of scrap plexiglass and my cell phone camera as a tracing table, but I ordered a nicer one on Temu and should have it next week. I think the fully illuminated backdrop will significantly speed up the process, so for now I'm just dragging my feet and penning out some of the other sprite sheets not shown here today, like the running jump, the spin move and a few others.
The plan has already changed so much, but most notably, the plan to finish as quickly as possible is gone. Currently, I'm focusing only on getting together enough animation sheets to give me the working material I need to begin developing character movement algorithms, so programming has had to fall to the wayside while I stay strictly engaged in learning the fine art of animation.
I created a Discord to go with all this, because I’ve seen people do that so I guess it’s what you do?
[Join the Discord!](https://discord.gg/ZD4CReZS)
Also, I will try to keep a running list of all devlog entries [here](https://ecency.com/azldevlog/@hive-174589/azl-game-devlog)
* * *
* * *
* * *
<center></center>
hiveblocks