Featured Post

First year of development under my belt. More to come!

New Monsters!

This month marks the first year anniversary of development for my desktop/mobile 2D RPG game.

At this point it isn’t as much of a “game” right now as it is a game engine of which I intend to build the game upon in the very near future now that it is reaching a stable state.

This article is about my trials and tribulations of developing the engine over this past year, what I’ve learned and what I wish I had learned better before starting on it.

TLDR; (since this is a rather long article)

Things I think I’ve done well so far:

  • Memory management.
  • Final version of effects engine seems solid now.
  • Final version of visual sequencing seems solid now.
  • Entire engine has kept to the “configure everything” design we first aimed for allowing us to start building an actual game from the engine.
  • Unit testing. I’ve gone hog wild here. Almost 200 unit tests covering over 80% of the core library when executed. Although as time has gone on, I’ve been slacking on adding new tests for newer code, so this number has been dropping sadly. These tests are run constantly whenever changes are made to the core library to ensure nothing has been broken (and I do break things!)
  • The core decision tree engine used for maps, monsters, character etc (any AI really) worked quite well right from the start and has only required minor tweaks from time to time as I continue to expand on it’s requirements.

Major time sinks:

  • Core/Effects engine design and implementation took far longer than desired due to having to revisit the entire design on several occasions.
  • Visual on-screen sprite sequencing required several rewrites as I learned more about how to manipulate sprites better.
  • Android screen sizes. This one although not a lot of time lost, was a major pain!
  • Character pathing. I find myself still wanting to improve on this area. I might need to revisit it entirely at some point later on.

Future work:

  • New artwork and animations are on the immediate schedule.
  • Continued expansion of the AI and character/monster balancing (current work now)
  • The game itself ! Yep, the time is coming close and I’ll start producing images and video’s of game play from the game itself instead of just functional demonstrations.


As with many personal projects, this game started off as a “Hey, let’s start a new project together” with my brother (my twin!). We’ve always worked together on projects over the years but this one was going to be our first game.

We started off with the concept that we weren’t entirely sure what the “story” would be just yet, but we knew what style we were going to aim for (classic 2D turn based RPG).

So, how does one write a game without actually knowing what the game will be? Good question.

One major thing we decided early on would be that we’d try to keep everything as generic as possible. Design everything with the intention that we’d want to be able to configure it later for actual usage and not require a significant amount of code changes once that process starts.

By building the game engine entirely with the purpose of being reusable in any form was going to allow us to wait until later to actually decide what the “content” of the game would be.

In the beginning the plan was that we’d both be working on the major components together, but as life has it, he and his wife decided to start an entirely new chapter in their lives: sell old home, get new jobs, move to new city 600 miles away, rent place until new place is ready, move into new home, start major renovations and end up with a nightmare of a contractor. Needless to say, he’s been very busy this last year!

So, off I continued with the work 99% by myself. The plan was that I’d work on the core engine parts and he’d chip in with “idea’s and feedback” as much as he could. This has continued to work quite well for us in his absence.

And before you ask, nope, still no story and still no name…we’ll get to doing that, I promise !

Tools & Libraries:

I’ve been in software development for over 15 years covering many different languages over that time. Although I must admit, as my time at work has been chewing on my heals, my free time available to learn new technologies has been rather limited. With that in mind, I decided to work with a language I’m fully skilled in: Java.

Once I decided I wanted to work in Java, I then looked around for various graphics engines that could be used. This lead me down the path toward LibGDX, which has been a great library for my uses allowing me to develop for both Android and desktop using the same code. I’ve also left the door open for compiling onto iOS later on once I get access to a machine that I can do so with.

Tools/libraries I’ve been using up until now:
  • Java
  • ADT (older Android eclipse, not sure I like the new Android Studio, but that’s a different topic)
  • LibGDX
  • GSON
  • Tiled
  • Spriter
  • GIMP

Time sinks:

Oh where to start. One thing I can say for a fact is that I seriously underestimated the amount of effort some of these major components would actually take. I am glad that I was not on any schedule or deadline as I believe I would have long missed it. Lot’s of reading online of articles on all kinds of various game designs etc, it has been quite a learning experience that is for sure.

I’m going to cover some of the major time sinks I ran into over the last year:

Core/Effects Engine

I’ve probably lost the majority of time in the area of the effects/abilities engine that controls almost everything. This engine is the basis behind how combatants interact with each other and everything else. Everything from spells, weapons, character stats etc are covered by the same “effect” design.

Originally the concept of being able to use these effects was very basic. An effect is applied to a character, that character can then apply effects onto another (weapon attack and damage). Then we introduced such things as reactions (react to an effect being applied), triggers (invoke an effect through means other than directly), delays, recurring, duration, catalysts (apply an effect, but have the person it was applied to cause it to trigger by doing something else) and a whole slew of variations based upon available targets (myself, my ally, my enemy; scopes (all, group, single) and many combinations thereof.

This resulted in many, many, many rewrites of the core code. Far more hours lost there than I would ever like to admit. Although over time it has become an extremely robust system to use and all fully configurable allowing extensive and almost unlimited options.

Sprites, animations and general on-screen pain

Another massive time sink happened once I started working on the visualization of the effect instructions onto the screen using sprites. Up until this point all my “mechanics” were only being tested using unit tests and visually reading through the logs to verify the results.

Once I started creating the “sequence engine” to read the instructions from the effects engine things started to really become complicated. I ended up spending a lot of time working out the finer details between timing of sprites for displays, damage numbers, animated effects (lightning bolts etc) and being able to keep all actions properly displaying in the correct order (attack->reaction->counter->run away kind of thing).

Combine that with the fact that I also wanted to be able to control visually how these were presented on the screen. Some instructions were to be simultaneous, while others required to be sequential. This resulted in an interesting design of the sequence engine that now allows me to create any one of these combinations and simply “plug it in” to the rest of the sequences without too much additional work.

The sequence engine continued to grow but also required several full rewrites until I finally came up with the design that allowed future expansions on it without having to rewrite over and over any time something new is needed to be added.

Many nights of sleep were given up for trying to work out some of the major issues at the time, which funny enough, most of that work got scrapped during the final rewrite phases; go figure.

Path generating

Creating the code for my path building has been fun, although I believe I may need to revisit it a few more times before I stick a fork in it. Right now it is a variation of the typical A* design but with some minor differences that (at the time) I felt was needed. It works great for the most part, but still from time to time sends my little guys onto some very odd paths (although they do get to where I want them). So for now, I’m accepting it, but will come back to it later during polishing stages.

Android Screen Sizes

Handling multiple Android screen sizes started off as a nightmare. Although I didn’t lose much sleep over this one, I did end up having to revisit it many times over the last few months. I realized near the end the entire problem I kept running into was actually caused by my misunderstanding how to properly use libGDX’s viewports. Despite reading the documentation over and over again, I was still using them incorrectly. Once I made that realization, things came together quickly. Hard lesson learned there, and I believe I have the issue fully resolved, but future testing on more “real” mobile devices will tell for sure.

Memory Management

Memory management has always been very high on my list of things to try and keep an eye on. Any time I finish up any major code changes I run the application through a series of memory usage tests monitoring it for any spikes and significant memory allocations and making improvements to the code as required. Despite the amount of time spent here, I believe it has been time well spent.

Being a perfectionist

I find myself constantly wanting to “improve” sections of the code as I work on additional parts. This can be healthy in development; or so I try to convince myself. I find there are times I spend a lot of hours on something only to realize I really didn’t improve things much, just changed how they “worked”. Overall though, despite being a time sink, I believe most of it has been a worth while effort.

Going into the future


Right now the majority of the artwork I’m using has come from www.opengameart.org (big thanks to everyone there).

I will be purchasing some stock art here shortly and will be spending a significant amount  of time on creating animations using that art. I’m not an artist, and can’t even “fake it”, but I have worked with Spriter and really enjoy working on animating existing artwork.

I’m looking forward to making all kinds of custom animations since my engine can allow me to do almost anything I want. Stay tuned, in the coming months I’ll be posting  about all kinds of new animations I hope.

Artificial Intelligence

Although the AI engine was written many months ago (and wasn’t a time sink !), I’m planning on continuing to expand on it in the coming months as I design more robust and interesting monsters. Right now the engine does allow for a large amount of customization and “personality” development so I’m looking forward to seeing how much I can push out of it.

The game itself !

Yep, the time is coming. I’ve been putting this one off because I’ve been hoping to pull my brother back into the flow for this part. He’s always been more of a “game play” person that I have since he’s been designing non-video games (card/board/strategy etc) for fun for many years and has a lot of great idea’s for content and story line.

A few months ago I did write a short article about a larger vision on how the game might work. At this point I believe this is still, for the most part, the goal in mind:



Demo Video’s

Over the last few months I’ve been producing small mechanical demonstration video’s. Today I’ve made a small “Adventure” showing off some of the key parts of the game engine.

If you wish to dive into more of the mechanical video’s, here are some you might find interesting:






And without further ado, here is the adventure video !

Short Game Play Demo
Short Game Play Demo


Well, this article has ended up being far longer than I had expected. I guess there is a lot to say to cover an entire year worth of development. Hopefully it hasn’t been too dry and you actually made it to the end.

Overall, this project has been a great learning experience and loads of fun. I wouldn’t have traded all those hours for anything else as I believe the knowledge gained will stay with me and has improved my skills in development as a whole. (and kept my mind from rotting from the repetitive assignment I get from work!)

Thanks for reading everyone and feel free to write and ask any questions.


Weekly Wrap-up #12
Weekly Wrap-up #13


  1. Thanks for the kind words. It really has been a lot of work, but I’ve been really enjoying it all so far.

    The video above is actually a bit older now. The biggest changes are in the sprites/monsters themselves. The combat sequence engine has been pretty stable since this article and has had only minor updates since then; so I’m pretty happy with how it finally turned out.

    If you’d like to see some more “current” examples of the game, feel free to poke around the previews section:


    I’m continuing to do additional features, but in the coming weeks I believe a lot of focus will be on monsters (sprites and AI’s), maps and game balancing as I attempt to work toward a playable demo (finally!)

  2. I’ve built an JRPG engine / game myself so I can appreciate the amount of work that has gone into this! Really impressive. (And my efforts are far less feature complete than your own :D)

    I also use something like the sequences you’ve described but I’ve called them storyboards (they’re used for cutscenes and combat special effects. Basically every that has a number of events occuring over time)

    Your video looks really nice I’ll be keeping an eye on how the game progresses 😀 Good luck!

Leave a Reply

Your email address will not be published / Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.