You don’t use Unity 3D, it uses you

After seeing how so many people are picking up game engines like Unity 3D and Unreal Engine for their smaller scale game projects, I decide to do a little more research on what would be required to use one for an upcoming game idea of mine.

I chose Unity 3D to start with and downloaded the free version, and was able to run the editor tool and start playing with it pretty quickly. The interface was closer to something like 3DSMax or Blender in that content creation seemed to be top priority, with behavior and the programming parts secondary. On top of this, I was surprised that Objective-C wasn’t supported natively, though there was some sort of way to bridge this language and use it together with Unity.

Wondering how I could develop a platform specific (iOS in my case) game with the engine, I found there is a separate set of APIs which mirror those on the platform, and you actually generate a XCode project with the relevant files, and use that when you submit to the App Store.

This entire process was completely the reverse of what I am used to, making a project in XCode and just importing libraries as needed.

After some consideration, I decided to put Unity 3D on hold since it would require such a major shift in development style. Clearly, if I want to make a high quality 3D game an engine like this is necessarily, and there is also the extra advantage that I can easily port it to other platforms. However, the game I have in mind can probably be done pretty well in basic 2D, so I tentatively decided to prototype it first in the simplest possible way.

One of the reasons I made this decision is because my time budget is pretty tight. Had I been back in college when I had much more free time, it might have made more sense to just spend a few solid weeks learning Unity 3D. But for my current situation, I am not sure if that is worth my time. Also, I generally like to focus on writing gameplay and AI, with less of an emphasis on visuals, so I try to plan things so I can spend the most of my time on these elements.

While it’s true that many games these days decide to use a 3D engine just to look cool or extra realistic even when the gameplay doesn’t require it (ex: Smash Brothers), in my case I am not sure if the extra time to use 3D is worth it.

Game development: To Engine Or Not To Engine

Since I started scanning the posts tagged with “Game Development” on WordPress, I’ve noticed a great deal of talk about game engines, in particular Unity and UE4. Although I knew such engines existed for some time now, I was a bit surprised how frequent they are used, and how even games created by a single developer were using these.

So I’ve been thinking a bit more about game engines and decided to do a post on them. To start with, what are the reasons and pros/cons to using one?

Though I mentioned two 3D Engines above, there is really a continuum of choices for game developers, with increasing reliance on other’s code and less on their own. I’ll list some options out, very roughly:

  • Assembly-language code  [all code]
  • Low-level programming language (C, C++, etc.)
  • Higher level programming language (Basic, etc.)
  • Some programming language along with an engine (Unity, EU4, etc.)
  • Game-development tool with simple scripting or visual-based logic blocks (RPG Maker, Game Maker, etc.)  [no or very little code]

Generally speaking, the farther down on this list you go, the less time you have to spend on coding as many things are already done for you, or can be done with a few clicks or a simple script. In exchange, you have more limitations on the types of games you can create, including graphics, gameplay, and other elements. If ten people create a game with RPG Maker, there are likely to be many similarities between these games, whereas if these games were made “from scratch” in a low-level language, they would probably have much greater diversity.

There was a time when I looked at those using RPG Maker and the like with disdain, thinking “those people aren’t really developing games!”. But after some thought, I now realize that their choice to use such a tool frees up their time to focus more on game elements, like story, gameplay, and balance. While it’s true that someone making games is less likely to “make it big” by selling their game to a large audience, I’m still very far from that goal myself and surely, the joy of the act of game making itself, plus the pleasure of having others play your game are too important aspects to game creation. [As a side point, as a career building skill I still highly recommend learning some commonly used programming language, such as C++ or Objective-C]

For me, I learned to program around the same time I was introduced to computer games, and programming itself is a very enjoyable activity. Just writing code, tweaking it, and seeing the results can be fun, though it depends somewhat on what the program is doing and how tedious the code writing is. Because of this, sometimes I can end up spending a great deal of time on tweaking certain parts of code, and not necessarily focusing that much on the “game-making” aspect. In any case, I consider myself much more familiar with programming than game-making per se, and have much more to learn with the latter.

Having said that, regardless of your experience level you can choose any of the above options, given you have enough time. So which do you pick and why?

First off, for 3D I think you pretty much are forced to use an engine, whether it’s Unity or something else. Back in the day when 3D rendering was a much less mature technology, it might be possible to calculate your own 3D-to-2D mapping and maybe even apply simple textures (think of the classic film Tron to get an idea of what I mean). But now with advanced lighting, textures, animation, and so many other things to worry about it’s nearly impossible to do all this yourself. I knew a guy once whose hobby used to be creating graphics engines for fun, but ironically he never really did much with them, since the engine itself was the end product. Unless you have a pretty large team you’re not going to get by with creating your own engine and consuming it.

My knowledge of tools like Game Maker is limited, but I’m pretty sure most of those are 2D only, so wouldn’t apply to making 3D games. If you want to focus more on level development and don’t mind little to no control over the gameplay, you can always use something like Minecraft or Blocksworld.

For 2D games, I think you have a little more wiggle room since it’s much more feasible to write your own code to do things like display a grid of tiles and scroll them. This is what I choose to do for my first iOS game, as well as the one I am currently working on. I considered playing around with something like Unity which has support for 2D games as well, but due to concerns about the learning curve I ended up not using it. From the little research I’ve done, it seems that one of the reasons to use something like Unity is for it’s level editor, which is something you really don’t want to make yourself. Also, you would have to worry less about performance of animations and scrolling since the engine would take care of those for you. Given the opportunity, I’d still like to play with Unity sometime, however.

In the end, I think we all want to be able to say “I wrote a great game”, as opposed to “I wrote a great program”. And as long as we can customize the end result to our liking, the player shouldn’t really care what technology or set of tools was used.

Visual styles for games

When creating a game, a key element is how you display information to the user visually, and this will have a major influence on implementation times, skills needed, and how easy it is to divide up tasks among multiple developers. In this post I’d like to talk about some of the different categories available, along with each’s pros and cons.


Writing a game that operates in a flat space in two-dimensions is a very common style, and even now I feel it is the most common one, at least for games done by small teams.

With 2D, you have a few different ways to create your assets:

  • Pre-rendered from 3D
  • Hand-drawn (generally requires artistic skill)
  • Drawn in-game (vector, geometrical, etc.)
  • Photographs
  • Mathematically generated

2D games can be further broken down into a few genres depending on the gameplay and constraints of movement. Here are just a few:

  • Static single screen, cannot ‘go’ anywhere (ex: Tetris)
  • Horizontal scroller (ex: Mario)
  • Vertical scroller (conceptually same as the horizontal scroller, though gives a different feel)
  • User is only shown a small piece of a larger map, and can scroll around at will


  • Spend relatively less time on graphics, compared to 3D
  • Can potentially do all coding in-house without using a third-party engine (though you have that option as well)


  • Types of games that can be done is limited
  • More and more games are moving to 3D, so it’s easy to look dated with 2D


Writing a game in 3D means that a three-dimensional space is represented, usually with light sources, textures, and a camera of some sort. This is becoming the norm for more and more games, and more and more 3D engines are becoming available for no or low cost.


  • Nearly unlimited options for game types
  • Can polish graphics to the extent they are photo realistic
  • If done well, can be very intuitive to users


  • Almost always requires a 3rd-party engine (Unity, etc.), or spending significant time on developing an in-house one
  • 3D-related development and related issues typically take a great deal of time
  • Requires special skills to make textures, models, and animations
  • If done bad, can look even worse than 2D
  • Making intuitive controls can be challenging, depending level of freedom given to the user


Isometric is a unique perspective where objects farther away from the camera don’t get smaller. Q*bert was one of the first games with this perspective, and XCom 3 is one of my favorites. You can see a few screenshots of isometric games here.

Isometric can implemented either simple projections so that it is similar to 2D, or can be used by configuring a 3D Engine to appear isometric.


  • Has a certain ‘nostalgic’ feel to it for those who have been gamers for some time
  • Can look more realistic than 2D, while taking much less effort than 3D


  • Freedom of camera movement and world construction is limited.

Text only

This is a style for the most part extinct, but was headed by classic games like Zork        in the day.


  • Spent no time on graphics
  • Prototype very quickly


  • Severely limits the type of game which can be made
  • Small, niche audience

Sound only

This genre is pretty rare, even more so than text only, but I’ve seen one or two apps on the iOS app store recently that use a combination of high quality sound effects and stereo sound to create a immersive experience.


  • Spend no time on graphics
  • Can be seen as “creative”


  • Very limited
  • Requires special skills to properly record sound effects
  • Small audience

Combination styles

The sky is the limit for which styles you mix and match. For example, classic Sierra games used a good mix of 2D graphics with a text-based interface. The Super Smash Brothers series uses 3D but in a mostly 2D way, emulating true 2D fighters like Street Fighter. Some games also use a combination of 2D and 3D, either simultaneously (like showing a 2D map at the same time as traveling through a 3D landscape), or switching between styles in different areas.

Though it’s probably rare, you can even switch styles in the middle of development – starting with a 2D prototype to prove the concept then switching to 3D for final implementation, or falling back to 2D when you realize 3D is not worth the effort for the given gameplay.