Long time reader, first time journal poster here. This is regarding a game convention called XPO, where I showcased publicly for the first time an indie game I've been working on for the past three years. And more specifically, it's about the lessons I learned from it.

The game in question can be described as a fighting game with RPG elements and it is being developed in Unity. It's something that has been on my mind for a while, but I didn't start any real development on it until early 2013. XPO, which took place in September of this year in Tulsa, OK, was the first, and so far only, convention I've showcased the game at. Up to this point, I didn't think it was good enough to be publicly exhibited. And without further adieu, here are the most important lessons I learned from the whole experience:

Lesson 1. Test the game in a build as often as possible (under different resolutions and aspect ratios). Because I had never done this until the week of the convention, there were a great number of things that did not work correctly in a build and there simply wasn't enough time to fix all of them, so I ended up demoing the game in the Unity editor, which was not optimal.

It is much easier to position various UIs (user interfaces), dialogs, and other game objects where they need to be as you are developing them, when all the various conditions and parameters are still fresh in your mind, as opposed to coming back later and adjusting them. For example, now that I've learned this lesson, I am re-working big portions of the game to make sure it runs in a build. One of the biggest issues I've encountered is with the positions and sizes of my UIs. Many of them I simply hard coded to get them to work when I needed them, but as you can guess, they did not work so well in a build.

In order to address that issue, I am currently re-doing all of my UIs to make use of the Canvas system in Unity, as it has built-in features for adjusting the positions and sizes of UI elements as the screen resolution changes. As you can probably guess, this is a time consuming enterprise, which would have been a lot less painful had I planned for it from the beginning.

Plus, making sure the game works well in a build forces you to think about important details, such as what resolution and graphics quality your game should be playable under, where should data files be located, etc., early in development.

Lesson 2. Have other people test the game as often as possible. It is a well known, and oft ignored, maxim in the professional software development world that a developer cannot, and should not, test his or her own code. They are simply too close to it and subconsciously, or rather consciously at times, "test" it in such a way that it does not break. Unit testing can do some of the work for you, but really nothing is a substitute for another human being playing your game and actively trying to find ways to break it.

The reality though is that indie developers, such as myself, don't really have the resources to hire testers to playtest a game on any kind of a regular basis. We are often limited to friends and relatives, or just doing it ourselves, which is pretty much what I did, other than one playthrough done by my spouse.

If your game has been tested on a regular basis and you already know everything works well, that will give you confidence in your creation, which will show through to whoever you are talking about it with. And as a very nice added bonus, it will also save you from having to frantically fix bugs in your hotel room the night before the convention. Trust me, I've been there, I know, it's a stressful experience that I don't care to repeat.

It is, shall we say, unpleasant to find out the night before you are supposed to be showcasing your game, that it doesn't work in a build so you have no choice but to have people play it in the Unity editor, not to mention finding out that a major feature you introduced specifically for the convention, such as being able to restart the game, has caused hard to find bugs and you have no choice but to scrap it. It sucks! Test your game early and often to prevent all that.

Lesson 3. Have the game playable on a TV. Somehow I had convinced myself that as soon as I had set up my laptop and started up the game, people would line up wanting to play and asking me all sorts of questions about it. Talk about wishful thinking. Well that was not exactly the case. People were walking by, but did not seem terribly interested in approaching my booth. I am sure the location (off to one side and facing away from the entrance) did not help things a whole lot, but I am convinced the bigger reason was that my set-up was simply not appealing enough. I had no posters or marketing materials of any sort, just a laptop screen facing towards the convention floor.

In contrast, the main indie games booth hub, other than being directly in front of the entrance and thus being difficult to miss, was populated by big screen TVs at elevations high-enough to be seen from pretty much anywhere on the expo floor. It was only logical then that people would congregate around them and hardly even notice my less catchy set-up.

Lesson 4. Have the game playable with a controller. Being a console gamer, perhaps I am a bit biased, but watching people play my game, hunched over the laptop and struggling with the keyboard, it dawned on me it would be so much easier if they could just pick up a controller and play. Plus, with a controller there is less opportunity for errors, i.e. only the buttons that do something in the game are available to the player. Even if they wanted to, they could not press a button, or a button combination (such as Escape or Ctrl + Alt + Delete), that could cause your game to exit or transition into some other undesirable state.

Lesson 5. (Almost) always develop as if you are preparing to showcase the game at a convention. When you are in the midst of development and really want to pump out a cool new feature, it can be very tempting to "leave things for later". Or when you are faced with a looming deadline. Of course, the reality is that it is impossible to never leave anything for later, but you should try to minimize that and think really hard before you do (leave something for later, that is).

In my case, I had left so many things for the proverbial later that when the time came to showcase the game at an actual convention, there simply wasn't enough time to address them all, so I had to cut features and otherwise make compromises just to have the game be playable at the expo.

This also goes hand in hand with some of the other lessons, particularly #7 below, but long story short, (almost) nothing during the development life cycle of a game happens in a vacuum. All aspects of a game, especially the code, go hand in hand together and many are dependent on each other. So if you leave one thing for later and that one thing depends on, or affects, five other things, the amount of time and effort it would take to finish or fix that one thing several months later would be significantly higher because the other five have most likely changed, or they would have to, as a result of the thing you change.

Lesson 6. Add a main menu screen. I noticed the guy on the table next to me, who was showing off an open world MMO with western themes, had a pretty nice main menu that was constantly looping while the game was on stand by, and it made his game look polished.

By contrast, my game thrust the player directly in the first level. Now granted, you are not expected to have a finished product at a game expo, but whatever you do have should look as good as possible, and a main menu is just the sort of thing that can make your game look more like a professionally done product as opposed to a hobbyist project.

Lesson 7. Emphasize (code) quality over quantity. As a software developer by education and trade, I've always tangled with the million dollar question, "How to build better software?" One conclusion I've reached is that creating good software is very much like building a brick fence. You lay down a layer of bricks and then another one on top of the first one, then yet another on top of the second one, and so on and so forth. Now, if just one of the bricks in the very first layer is a tiny bit askew, that's not a big problem, plus at this point you only have one layer so really, your fence is just as stable as if that one brick fit perfectly with all the rest.

However, if you now put down a second layer on top of that first, imperfect one, your fence will be a tiny bit unstable. Still probably not a big deal, right?! You are on track to meet your deadline, so things are good, ....maybe. However, think about this now. If you wanted to fix that first layer at this point, you would have to undo the second one, fix that one brick, and then redo the second layer. Of course, things are not as clear cut in neither real life brick fence building or software development, but you get the point.

To continue with my analogy above, if you leave the first layer imperfect as it was and not only that, but you also introduce a faulty brick in the second layer too (because again, you had to meet a deadline or some such) and then you erect a third layer, your fence is now starting to get a bit wobbly and the cost of fixing all that would be even greater, as you would have to undo and redo two layers.

I am pretty sure you see now where I am going with this, but let's continue with our example a bit longer. Now let's say in layer #3 not one, but two bricks are off and don't quite fit very well with the rest of the bricks, partially because one of the bricks is now on top of the imperfect brick from layer #2. You still march on, however, and you construct layer #4 on top of #3. At this point, the whole thing is starting to get noticeably unstable, but the cost of fixing it grows higher and higher and you now start realizing it would take so long to fix all the issues that you would be severely over budget and behind on your deadline. So you do the thing that so many other developers do, and that seems the easiest at this point, and you keep on building on top of an increasingly unstable foundation, you keep on patching and duck taping the fence, just to keep it standing and your boss happy.

The time comes, however, when the fence is so unstable that it becomes impossible to patch it up anymore and when that tipping point is reached, the whole thing simply collapses under its own weight. The only way to fix it at this phase in development is to scrap the whole thing and start over. That's the very situation we want to avoid by following software development best practices, measuring twice before cutting once, and so forth. As a side note in regards to best practices, I would highly recommend the SOLID principles of software design.

So after this very long example, back to my lesson. After spending a few months preparing my game for XPO, I realized my code base had gotten big enough to the point where I could not really afford to add any more poorly designed or implemented code, or I would risk my "brick fence" going over the wobbly point of no return. From this point on, I decided, it's imperative that all new code is well designed and implemented in accordance with best practices. I suppose the whole point of this lesson then would be that "this point on" should really be the beginning of your development cycle.

Lesson 8. Go and find people to play your game if you have to. For whatever reason, poor location, the small laptop screen the game was showcased on, etc., people were not coming up to my "booth". So after some time, I decided that it was up to me to convince them to try out the game. And so I did. I watched the people pass by and when I spotted what I thought was a good candidate, a young guy walking by himself, I went up to him and said, "Excuse me, do you mind playing my game? It's an indie game I am working on and I need some feedback. You can get free candy if you play". And the guy said "OK". Boy was I happy. The first stranger to play "Genosaga"!

Bonus lesson:

9. Bring candy. Why not? Can't hurt. People like free food. See Lesson #8 above.