codewalker

Disclaimer: If you don’t know, I have a full time job and I make the games in my free time hoping that one day the free time becomes full.

The core game is complete and it has been released on Desktop, Android handhelds and consoles. However the multiplayer feature is on hold until I have enough funds to support a reliable server, that can only come from sales and ad revenue. However, any update will be performance improvements and bug fixes until then.

Multi Dominoes taught me more things about game development, publishing and even marketing that I thought it would. I am glad I have chosen this project and I would like to share to the few people that follow my work over the past weeks that wither gamers, devs or enthusiasts what I have learned so far.

1. Choose your game project carefully

Multi Dominoes ended up being an excellent choice for my first project, but it was not the very first that I had planned to make. Not even close. And now that the development went through I think it would have ruined me in the long run.

A project should reflect the skill set you and your team (if you have one) have, the budget you have available and the knowledge of what you are actually making. Do not start with a blank canvas and just a bunch of ideas in the head. Make the ideas more concrete and down to earth before start coding

2. Prototyping is good but leave them alone

A prototype is usually a bunch of cheap assets and loosely structured code that is made to prove a concept or game idea that you want to implement. It does not matter if the prototype is a success or a failure, you keep it as a learned lesson and experience that may be useful in the future.

However, you should not build the game from a successful prototype even if that is the “core” component of your game. Remember, a prototype is meant to break, to push to the limits of what you, your team and the tools can do; not to server as a foundation for the game. If the foundation is broken, the game will be broken.

Instead have a clean game project where the code is a collection of lessons learned where the purpose is to be stable, reliable, and balanced overall.

3. Do not “marry” a game engine or practice

Sometime is better to move on from one engine to another to realize your projects that sticking to a “proven” one that has done good for so long. Other times, the engine is fine but your programming practices need to change or else your goals will never be reached.

I have been an Unity advocate for years and with each project I was learning more ways to make the games my clients wanted more efficient, have more features, become easier to port to other platforms, etc. When the time came to start making my game, I started wondering if, as a programmer, Unity was the tool that suited me best.

JMonkeyEngine proved me I was right in switching since I learned in one project much more that I learned in any of the Unity projects I was involved with. This does not mean JME will remain forever, if a project is more suited in another software, a switch will happen. But not for now.

4. Refactor, refactor, refactor

This is for programmers. Sometimes it’s better to rewrite code that works so it can be more flexible and extendable in the game.