For those who don’t know about it, GRA was my previous project, a GTA themed rogue-like taking place in a fully simulated (and procedurally generated) city. It featured several thousands of persistent NPC, destructible terrain, several starting scenarios (including zombie invasion), a localized damage system and a powerful game editor. On the other hand it was rather aimless, very buggy and didn’t have a proper save-game support.

I am often asked about Grand Rogue Auto, and I recently reviewed the code to see what’s salvageable and what’s not, so I guess that I might as well explain here what are my future plans regarding this game and while at it do a small post-mortem analysis. This is a long post, and some parts have been written quite a while ago.

GRA Post Mortem

Let’s start with what went wrong. Well, lots of things. If it’s true I have been a programer and a modder for a long time, it didn’t mean I would immediately know the best way to code a game. And, saying that GRA wasn’t coded in the best way possible is quite an understatement. Simply put the code was a mess. It was supposed to be object oriented but how I actually set those objects and their inheritance wasn’t exactly good, leading to a well known syndrome, in the programing world, of “god object“. The way I mapped the terrain wasn’t particularly good either, and the logic extremely hard to follow.

Worst, I didn’t used source control systems like git to keep track of the changes I made. It may not be a cardinal sin in itself for a solo project, but it was coupled with a very bad decision (in retrospect) to avoid refactoring as much as possible, focusing on adding features and completing the game instead. It resulted in a growing code base that became harder and harder to read. As per murphy’s law and as a result of all those poor decisions, what was bound to happen, happened. The code became slowly but surely unmaintainable, fixing something would inevitably break something else. Adding simple features or behaviors became increasingly tedious and difficult.

Becoming increasingly frustrated with my own code, I decided that enough was enough and prematurely announced another game (xcom meet rogue) based on the GRA code. Another obvious error in retrospect. The idea was to refactor, salvage would be a better word here, the code base and restart with something decent. I tried, but it quickly became apparent that it would be a much easier task to restart from scratch than to decipher, and rewrite the code in a manner that make sense.

After that, well, I was a quite a bit discouraged and there was financial difficulties and other real life issues that put me away from coding for a while.

It’s also a cautionary tale to new coders, especially to those who use those fancy UDK and Unity toolkits. You have to plan ahead. No matter how much planning you’ve done, double it and make sure your structure makes sense. The way you handle your data, structures and flow decide for the major part on how easy it will be to write your program. Also, there’s things you can’t simply add “later on”. A good example is crafting, that’s something that must be built from the ground up. Doing it the other way around means you’ll either write crappy code you’ll hate more and more or you’ll have to refactor your code in a major way later. Also, have a goal and stick to it. I had no precise goal when I began coding GRA, it started as a kind of artificial life simulator, and became some sort of free form rogue-like along the way. As a result the game felt aimless, and even as a coder, not having precise goals is pretty annoying and often lead to feature creep.

The Good Stuff

Anyway, let’s get to what went well and to which parts are reusable more or less directly.

First, there’s the city generator itself. It may not make the most realistic city in the world, but it’s still pretty efficient, and leave room for improvement. The road system is particularly good, and thankfully, approximately well written. The block / house placement part on the other hand, and even if it works well, the code itself is a mess that will need a rewrite.

There’s a few things that went so well that they have been used in UG directly, like the way orders are given and handled by NPC, the inventory/cargo system, and the path-finder. I also hesitated about adding the localized damage system to UG, as it’s a self-sufficient piece of code that can be added easily, but I decided against it in the end, because it wouldn’t have added much to the game itself apart from another layer of complexity.

Weapons and armor data and mechanisms worked well, most of the code is bad but the concepts and formulas behind it are okay.

Smoke and fire propagation mechanisms are also keepers. Not very sophisticated but they do their job as expected.

And that’s all folks ! Yep. Don’t get me wrong, the game did a lot of other things well, especially AI wise, but here, we are talking about code that can be extracted directly and reused in a new game. Comparatively speaking, most of UG’s code is reusable (well, the parts that would make sense being reused, of course) and modular.

Future Plans

Once I am done with UG, or at least the heavy lifting (1.0 reached), I might resume work on GRA, at least as a side project. Given what I have learnt, the amount of code I can reuse, and the tools I am using now, it could be a good rogue-like. More to the point, I already have most of the graphical assets ready.

As explained it needs to be rewritten more or less from scratch, but all things considered, it’s likely to be a good thing, the following addition wouldn’t be possible otherwise:

• Multi-platform: The design decision to go with very few keys and to mostly use the mouse in GRA means it can be ported to Android and iPhone devices relatively easily.
• Graphics: Even if it’s not the main appeal of rogue-likes, I learnt a lot about graphics when developing UG. Adding animations to things like smoke and fire, having the ability to zoom in and out, display the bullets traveling and so on will be possible now.
• Good coding practices: Lots of code from UG can be reused and for the rest I am pretty sure I can achieve much better results and performances with 2 or 3 times fewer lines of code.
• Multithreaded: GRA 1 was a bit sluggish despite handling “only” a few thousands NPC. With what i learnt while coding UG, having much more populated cities ranking in the 10.000 people or more is likely to be possible.
• More Focused: Giving a clear goal to the player while keeping the freedom aspect more or less intact. A prison-city from which something/one must be extracted and to do so you’d have to roam the city and complete a few “dungeons” might be something to work with.

That said, there’s an issue: the money. Yeah, it’s a sad world we live in. Simply put, I also have to make a living out of this. There’s the website hosting to cover and the licensing costs for the tools I am using to make the games. UG in itself is and will stay free, but a “deluxe” version will be available to those who want to support me, it’ll include the editor, additional maps and start locations, the manual in a printable PDF format and the music tracks at a higher bit-rate. Depending on the overall success of the game, addons will follow and will be reserved to those with the deluxe edition and to those who donated in a way or another (Paypal basically, I will probably add Bitcoin support later on).

Monetization of GRA will depend on how successful this model is. A free version will exists, at least for PC/Windows but it may have some limitations (single city, fewer scenarios, no editor, things like that, I honestly don’t know). The portable versions are likely to cost some money, probably between 2 and 5 bucks.