Blogs - 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.

Compared to Unity. jMonkeyEngine is not as straightforward when it comes to porting your game to other platforms. There are different issues to consider: The type of input, the size of the screens, the graphic capabilities, etc. This offers new challenges and invites to reconsider the approach to provide a solution that is easy to maintain but at the same time flexible to make the ports as optimal as possible.

My first approach was to simply copy and paste the packages that were generic for each game and then make the changes for each platform. This worked well when I ported Multi Dominoes from desktop to Android, but with iOS in plans and other platforms that support Java. I was getting overwhelmed when new core features were being done like the Mexican Train, porting some changes were not straightforward so it had to stop.

Since the release of jMonkeyEngine 3.1 I decided to start anew and port the desktop code first and update the game to take advantage of the new features. After that the new process was simple in idea.

1. Create a desktop release project of the game and only move the desktop specific code.
2. Create abstract classes and/or interfaces and begin refactoring the base project so that it will not depend on any platform code, but use generic methods.
3. Make changes to the desktop release project to extend abstractions and implement interfaces and ensure the gameplay was the same as before this process.

The game works now on desktop as before and the Android is almost ready as well for a future release. Who knows where the game might end up next ;)

I have been developing games as a freelancer and employee for many years using both indie and commercial engines. Now that I am starting to make games on my own I chose an engine that I am not as familiar to as the others: JMonkey Engine. While I have many projects I want to make. I didn’t want to spend time fighting trying to get something I want to work without knowing what I can and cannot do and the best way to progress. This mean that I had to do a project that would make me familiar with JME but at the same time I didn’t want to do just a sample project and continue from there. I needed a simple game project that would allow me to make a game that I can distribute and at the same time give me experience in developing with the SDK. Dominoes was the first game that came to mind.

Using a board game as my first game project was just what the doctor ordered. The problem that me and other developers that start by themselves when making a game we want without the proper experience falls into “scope”. Sometimes the project is either too ambitious or demand more things than what the engine can do or our experience can handle. After all, in many cases our games start as blank canvas where we have all the freedom we want. Dominoes on the other hand breaks away that convention.

A classic Dominoes game has a specific set of rules, a determine way to play and how it begins and ends. Just like any classic board game. By having these constraints I realized while I was programming I was looking for ways to optimize the game and use the best practices of programming and the strengths of the game engine at the same time. Starting was the difficult part but I was able to plan the different stages of the game that I want to reach. I was able to find some limitations the engine has in order to keep the performance high and how to get around them without sacrificing the integrity of the code. I learned that you don’t need to have an AppState or Control every time when a simple class can do that and saves you performance. It allowed me to apply critical thinking and problem solving with the tools that I have at my disposal ad the project progressed better than I thought.

Unfortunately I am not able to work full time on my projects since I need a job until my own games make me sustainable enough to be full time on it so the updates seem a bit on the slow side. But things will progress nicely as completion draws near

In reality it was a hard moment for me to perform the switch. After all, of the 9 years as a game developer six were unto Unity development mostly and I have a decent career of games released on many platforms thanks to this engine as I worked as a freelancer and employee for some companies. However, as time goes on I started to think about making games on my own and Unity was being my first choice due to the vast experience I gathered over the years. My very first obstacle is that I only have a personal edition (or indie as it was called back then) so I had my limitations. The other was that after all these years I was getting tired of Unity and many of the shortcomings and workarounds in order to get the projects reach the completion step.

Unity is an excellent platform for designing and prototyping your games, if not the best to my opinion. With its ease of use, drag and drop nature for assets and behavioral script based programming you can have a prototype of your game running in record time. This facilitates game design as a project continues its development. And it’s after the prototype stage where things can get ugly for the actual programmers of the game since this means the complexity is about to increase.

To make a long story short, I needed a different tool that offered me more flexibility and freedom as a programmer without being stuck with any paradigm. JMonkey Engine SDK offered me what I needed and more:

• Create my own game architecture for each project and not adapt my game to a predefined one.
• Able to edit code and run my project using one single application instead of two, saving myself a back and forth process.
• Able to write testeable code without external tools but one existing for a programming language.
• Release multiplatform games with an extremely affordable license (FREE!!! :D).
• Have a decent performance as well as easy coding.

JMonkey Engine and Panda3D fitted my needs but there is an inherent issue with performance in Python and with C++ there was a debugging issue and Android porting was not seamless as well. Another point that made me choose JME was the similarities between Java and C# on a basic level. To porting my current code to Java was fast.

JMonkey Engine was clear to let me know that is a programmer oriented SDK for making apps and games. It became more straightforward development on my end. However, I must warn that this engine is not easy and I would still recommend Unity for beginners into game development, but move out of it once you get enough experience and want to branch out. Do not stick to it.