Engine or Game?
One of the eternal debates in amateur gamedev is the distinction between a game and an engine. After making RPGs for twenty years, I’ve come to the conclusion that I do have an engine, it’s just not very engine-y.
If you take a look through every game I’ve ever made, you’ll find that I tend to use a lot of the same code. The menu system for Dungeon Monkey Eternal, written in Python, is a port of the menu system used in GearHead, which was taken from DeadCold, which was a Pascal translation of the menu system for the unreleased game Age of Adventure, which itself was a translation of the menu system I made for Realm of Sendai, and that’s as far back as I can remember.
Similarly, the main game loop of GearHead and the event processor are pretty similar to the game loops and event processors of all those other games. If it ain’t broke don’t fix it.
When taking parts from Dungeon Monkey Eternal, I’m going to organize them into proper Python modules, which basically just means throwing the related units into a folder so you don’t have ten thousand script files cluttering up the main directory.
Improved Map Handling
I want the map handler for the next GearHead to do a couple of things that Dungeon Monkey Eternal doesn’t do. First off, I want seamlessly scrolling endless maps, as in GearHead Arena-R (the abandoned attempt to recreate Arena with Lua scripting, aka the GearHead we shall never speak of again). This should be easier to do in Python than it was in Pascal; the “endless” map just needs redefined lookup methods that retrieve tiles and things from the constituent scenes.
The second improvement is that I want sub-tile placement of sprites. In every isometric game that I’ve done before, sprites can only be placed exactly in the center of a tile. This is most obvious when watching missiles skip jaggedly across the battlefield. For the new GearHead, I want to smooth out the missile trajectories and maybe even show the motion when a character/mecha moves from one tile to another.