One of the first questions you should ask yourself when evaluating a software solution for your game is one that gets overlooked: Are you interested in the final product (that is, a complete video game for a commercial release), or are you interested more in the implementation details of the game than the final end product?

If you are the latter, then you might consider developing a game engine in your favorite language to learn the core systems yourself, such as graphics, physics, artificial intelligence (AI), and file input and output (I/O). This book will not delve into the details of these different components. There are plenty of great books out there that will guide you through this process, such as Programming Game AI By Example by Mat Buckland and Game Engine Architecture by Jason Gregory.

If you are the former, then the rest of this section should help you make a better decision given the myriad software solutions available. On the one hand, the sheer amount of solutions for any aspiring indie developer or team opens many doors that were not available years before. On the other hand, it is very easy to get overwhelmed with all the options available.

The second question you should ask yourself is, based on the project scope and requirements, what are your target platforms? This question will drive not only the project schedule, but also have a huge impact on the programming language choice and in turn will determine the software solution for your game.

Years ago, this question used to be easy because there were only a limited amount of available systems with a high barrier of entry for all of them. Today, when creating a commercial game, there should at least be some consideration for all the available channels for distribution. This includes personal computers and laptops running Mac OSX or Windows, mobile devices that have most of the market share running iOS, Android, or Windows Phone, and even home console development including PS4 or Xbox One. Even with game frameworks and engines with cross-platform compilation, you will still need to factor testing for the various platforms into the schedule.

If you plan on adding a series of closed and open beta sessions to the project roadmap (a good idea to gauge the fun factor from user feedback as well as a first round of user bugs), there will be differences in how this process works across the various platforms and it needs to be accounted for in your plan. Once the details for target platforms have been ironed out, the choice of programming language should be much clearer. Hopefully, the language is one that you prefer, but if not, there needs to be additional time in the project schedule for training with the programming language.

The third question you should ask yourself after you have decided that you really want to develop a shippable commercial game, and decided on the target platforms, is whether you would prefer a game engine or a game framework for your solution? The primary motivation deals specifically with control and how this affects your workflow.

A game engine is typically a closed black-box solution (even though sometimes there are options for access to the source code) where you develop your game logic (in a language dictated by the engine) around the scaffolding of the engine, and in turn, the engine calls into your code during the game lifetime as the engine processes the main game loop.

A game framework, on the other hand, is a collection of libraries with exposed application program interfaces (APIs) into modules representing higher level abstractions of the core system components, such as graphics and file I/O. Developing with a game framework, in contrast to a game engine, gives control to you, as the owner of the main game loop, to call into the libraries as needed throughout your game lifetime. So, the question boils down to what kind of control you want for developing your game. The answer is not a straightforward one, but one that comes with tradeoffs for either solution.

The following table (Table 1) is just a small sampling of the solutions available today for game projects:

The fourth question you should ask yourself is: What is the actual budget for the development of my title? Table 1 is just a sampling of the options available for today's game development teams, and most of the options are very reasonably priced even for the indie developer bootstrapping their first commercial release (that is, free). There are much more exhaustive lists out there, but this should give you a feeling for the various programming languages, target platforms, and library support available.

With all the wonderful ideas and features for any commercial product, the Triple Constraint will rear its ugly head and quickly ground the project, demanding that you stay bound by time, cost, and quality. Any change to one attribute will affect the other two, constantly maintaining a balance for the project.

For example, if you sourced and received estimates for artwork at $5000, but you only budgeted say $100, this will significantly affect the quality (maybe you can just mash together some programmer stick figures) of the art, as well as time (even with stick figures, you will still need to draw them out, taking time away from development). Commercial titles, even with 2D pixel art, still need to be original and polished to really stand out. Stick figures might work as a gimmick to draw attention, but most audiences have more sophisticated expectations today, even with indie titles.

So, in summary, you really only have three courses when planning the budget:

Answering these questions and evaluating the choices available should lead to a more straightforward and educated decision without getting lost in a sea of noise. Originally, I wanted to develop my own game engine from the ground up.

After asking myself the first question, I realized that for me, shipping a commercial game was more important than building a game engine from scratch. There are many mature game frameworks and engines available, and the curiosity of building something from scratch was simply outweighed by more battle-tested solutions supporting multiple target platforms, once I committed to a commercial project.

This leads into the next question about target platforms because I realized, once I started evaluating the different solutions, that the cross-platform ones would significantly reduce my time on the deployment end. The cross-platform solutions are nice because they abstract away platform specifics (and most of them optimize under the covers based on build target), freeing me up to develop my game for one platform without worrying about the scope of work involved in porting to the mobile platforms later.

The third question regarding the preference of a game engine or framework was a little clearer because I wanted control of the game loop. I didn't really want to deal with the training time or cost associated with the various engines, and I didn't want to deal with all the complexities that come with their specific ecosystems (or idiosyncrasies).

Finally, the fourth question regarding budget was straightforward because as an indie developer bootstrapping my way through this process, cost was a significant factor, as I had a specific budget for art, and not much more especially for game engine licensing or tool costs.

These decisions helped frame my choice to go with the LibGDX game framework for my commercial game project. LibGDX is developed with a heavy emphasis on performance, includes cross-platform support out of the box (Windows, OS X, Linux, iOS, Android, and HTML5), provides low-level bookkeeping APIs that free me up so that I focus on developing the gameplay, provides an engaged and responsive community (not one where the forums have tumbleweeds blowing through), has active maintenance (nightly builds instead of one zip from ten years ago), and is available for free without a prohibitive license.

With all the decisions that need to be made when first starting a commercial RPG game, this book aims to help you through the process by minimizing the constraints. First, the time constraint can be reduced with this book by guiding you through the process of creating an RPG from scratch using LibGDX.

By the end of this book, you will have a working base template that you can expand on and add content to in order to make the game uniquely yours with support for multiple target platforms. Also, time will be reduced during the development cycle by developing modular pieces, such as scripting support, which can easily offload the creation of dialogs, items, monsters, levels, and quests so that content can be created in parallel with development without affecting the build process.

Second, recommendations on great free offerings, such as LibGDX, will be made throughout this book keeping the overall project costs low. These recommendations can be used in the toolchain of your development environment to enable you to stay productive and give the biggest bang for your buck on the deployment end.

Third, quality can be maximized due to minimizing the time constraint and thereby allowing more time for collecting feedback on usability, beta testing, and overall quality assurance.

Hopefully, the case has been made for adding LibGDX to your commercial endeavor for your RPG game. We will now review some core features of LibGDX as we continue our adventure developing the RPG game.