Recently I discovered an awesome podcast that discusses a variety of games, and one of the hosts actually works the business of developing them.
While you’ll need to know at least some Japanese to appreciate this, if you do it’s a great way to study up on Japanese as well as the art of game making.
You can more details about this podcast in my post here (on my blog about Japanese study).
Lately, I’ve been working on a new game project which is very different than all the other ones I’ve done so far. I’m planning on waiting until it gets a little further before I write about it in detail on this blog, but I ran into an interesting technical challenge and I’d like to discuss how I solved it.
To implement the game mechanics I need a graph of nodes, with various connections between each node. I have a need to find the shortest path between two nodes, where the path is calculated by the sum of the length of all connections as part of the path.
I started out with a simple recursive algorithm that started from each node and worked backwards to find all possible paths to get to it, and used a map to store the best connection to move, given a certain intermediate node and a certain destination node. This worked really well, although after around 13-14 iterations on a graph with many connections it started taking over a second to compute and them getting exponentially worse.
One option was for me to search for a more proper algorithm to find the shortest path, and I am sure this has been perfected by programmers over the last few decades. But I had a secondary requirement to also store all non-optional paths as well, so some of those algorithms probably wouldn’t suffice.
Looking at my recursive function, I realized that there really wasn’t much going on in terms of sub-functions it called that do any significant calculation. If there was, I could try to optimize those or cache up some result. But the question remained – what was taking up all the time?
Looking at the function again I saw that I was passing four different arguments into it. If you have ever studied assembly, you probably know that there are several instructions just to push and pull each of these to and from the stack, and since the function is called so frequently I thought that maybe this added up to a big chunk of the total time.
I decided to test my hunch by making all the parameters into global variables. I purposefully didn’t use class variables since I knew there would be extra lookups required, translating to extra work for the CPU.
It was a bit of work to make this transformation, since for non-pointer variables I had to manually save the state before calling the recursive function, and then re-set it. But this was only for two of the variables since the other two were pointers anyway which were supposed to change (one was the map which stored the nodes that had already been traversed so far, and I already had code to adjust that when returning from the recursive function).
The resultant code was a bit harder to follow, but the performance was significantly better. For the test case I was using I was able to get several more iterations before it got significantly slow (>1 second), if I remember correctly to at least 19-20 iterations.
If I keep adding nodes and connections eventually it still gets slow again, but I will probably put limits on these anyway so I may be safe with this solution for the time being.
Although I enjoy designing games from a high level, after many years of coding I still enjoy these types of algorithmic challenges, and the satisfaction of a well-tuned function.
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:
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.
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.
2D
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:
2D games can be further broken down into a few genres depending on the gameplay and constraints of movement. Here are just a few:
Pros
Cons
3D
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.
Pros
Cons
Isometric
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.
Pros
Cons
Text only
This is a style for the most part extinct, but was headed by classic games like Zork in the day.
Pros
Cons
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.
Pros
Cons
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.
A few days ago I wrote an article about using sound effects in iOS games. Just today I was doing some more testing and realized I had made a major mistake, and some things I said in that post were wrong. In this post I’ll let you know what I had did wrong.
I alluded to a single line change that would allow playback of MP3 files. Here is the specific line:
NSString *audioFilePath = [[NSBundle mainBundle] pathForResource:sampleName ofType:@”caf”];
I had simply changed the “caf” to “mp3” and since I was getting sounds I assumed things were working. The weird staticky sounds I got I explained by saying that several of the same sound were colliding and causing such an effect. Though sound collision can be a problem and sometimes it might make sense to have several variations of a sound effect, what appears to have been actually happening is that OpenAL didn’t know how to process MP3 and so it was just generating random noise.
After a tried a few different .MP3 files and they all sounded pretty much the same, I finally realized what was going on.
The solution was to return the code to use “caf” files, and use a line like the below to convert MP3 files to CAF files.
> afconvert -f caff -d LEI16@44100 chop.mp3 chop.caf
After doing this, my sounds finally started playing properly. I did find some strange effects that occur when sounds overlap quickly, but they were more subtle.
One additional step that is good to know is you will need to manually tell the .caf files you added to your project that they need to be included with the bundle that gets copied to the device. You can do this by dragging the file under XCode’s Build Phases => Copy Bundle Resources. I didn’t notice this problem for MP3 files, as it seems smart enough to add the to this list automatically.
The strange thing is I would expect OpenAL to throw an error somewhere instead of just spitting out noise. So either this set of APIs is pretty badly designed, or there is some code in AudioSamplePlayer that isn’t handling things properly. Either way, I got things working so not going to pry any deeper at this point.
Despite the fact that game development can involve many roles (story designer, art designer, gameplay designer, etc.) which can be filed by many people, ultimately the game produced is a creative work influenced from the individuality of each of the people involved. This means things like biases, world views, and what makes a fun or interesting game to each person all factor into the end result.
I believe we all have blind spots when thinking creatively, whether that is game design, a visual art, novel writing, or even musical composition. For example, something which we feel is obvious or logical may not be the same to another person, or even to most people. That’s why in all these creative arts, it’s good to have someone to bounce ideas off of and get feedback: “Does this make sense?”, “How does this sound?”, or “How does this look?”.
Herein lies a problem, because all these things are inherently subjective. We could ask 100 people to review a creative work, and they might all give different opinions and suggestions. This is why it’s best to be very picky about our reviewers, and in the domain of game development this means being picky about who tests our games, and what weight we give their opinion. We also can use basic statistics, like putting more weight to any feedback that was given by a certain percentage of people. If 80% of people say the UI is hard to use, then it would be pretty unwise to ignore that feedback.
As with all things, budget comes into play here since if we are not willing to spend money, our best bet is to be lucky and make friends with someone very experienced in playing and/or designing games, who also possesses the communication skills to clearly communicate what works and what doesn’t. Another option is to just get as many people as we can to help out, gather their feedback, and then worry about how to value it later. If your budget for your indie game is 0$, then you’re options are pretty limited here.
Fortunately, there is one more thing we can do to help – become our own best beta testers. That is the art of stepping out of our everyday thoughts and trying to act like a third party. This can involve playing devil’s advocate (“is this feature really easy to understand?”), or trying to think in detail about what the “average” person would think (“so-and-so game is popular, so many people would quickly grasp this element”).
In the field of music, we can get a good idea of what a third party would hear by recording ourself and listening to that with all our attention, since during the actual performance we are worrying about so many other things it’s hard to really listen to what sound we are putting out and the overall feelings it invokes. For novel writing, you can try to read through a chapter you wrote after waiting a few weeks, since then you’ll be closer to what a new person would experience. At least I found this to be a good practice.
For game development, I think getting into a neutral state where we turn off our biases is very difficult, but actively trying to get into that mode can help us train little by little.
[Image credit: http://www.gratisography.com ]
[Note: there are some problem with the conclusions drawn in this post. See this follow up post for corrections]
For my current mobile game project, I have a need to do both background music, and sound effects.
In a previous project, I used AVAudioPlayer to loop a MP3 file continuously in the background, and you can see an example of code to do that here (just make sure you call setNumberOfLoops to “-1” if you want infinite looping). For the sound effects, originally I planned to use the same API, however there are some problems with this. The biggest of these is there can be a large delay (a second or more) between when you kick off playback and the sound actually plays. This is fine for background music, but for a series of quick sound effects (imagine the sound of bricks falling, like in Tetris) it just doesn’t fly.
One of the other ways to play sound files with a bit more control is OpenAL. The documentation by apple (here) is pretty good, but it has a pretty steep learning curve, especially if you are like me and didn’t want to spend hours on experimenting. One of the reasons for this is if you want to do multiple sounds you have to do extra work to manage the simultaneous sounds, since unfortunately OpenAL doesn’t do this out of the box.
Fortunately, someone put together a class called AudioSamplePlayer (get it here) which covers much of the basics needed for playing simultaneous sounds, plus the added bonus of easily modifying the pitch and volume of them. The class is pretty easy to use, with the only minor annoyance that you need to pre-load sounds. However, this is understandable since it is designed to improve performance by avoiding loading each sample every time it is played. The licensing of the code is also such that you can use it pretty freely (but be sure to read it in full before using it yourself).
With AudioSamplePlayer you can save some development time, but you may need to do extra work depending on your requirements. One minor tweak I made is to allow .mp3 files (instead of just .caf files) which was a simple one line change.
A bigger problem is that if you game has the possibility to play the same sound quickly in repetition, the sounds can overlap and the resultant sound can sound strange (tinny or mechanical). For example, if you were playing the sound of each rocks hitting the ground in a simulation with 1000 rocks, some would likely occur near the same time.
In this case, one option is to limit the number of simultaneous sounds (and the above class allows this with a simple constant), but that can lead to unexpected behavior as well, especially if your sound file is relatively long (this includes and echo or space at the end of the file). You can also write logic to use a few different sounds to avoid exact-file collisions, or modulate the sounds in some way. You could even delay sounds a bit to reduce collisions, but again that would often be undesirable since the visuals would be out of sync with the sound.
In my case, I am considering just allowing the sound collisions since the resultant effect sounds sort of cool and seems to fit the atmosphere of the game.
Your next question is probably where to get the sound effects, since you may not want to record them yourself. There is a bunch of free sound effects sites on there, but I’ve found this site to have many interesting effects which can be used given the condition that you attribute the site.
References
http://www.raywenderlich.com/69369/audio-tutorial-ios-playing-audio-programatically-2014-edition
My first mobile game on the iOS apple store, Play the Field, was a great learning experience in many ways, but to be honest the number of downloads was quite below my expectations, especially considering it was free. I knew the mobile game market was dog-eat-dog, but nevertheless I think I was still a bit too naive.
I still feel the game is a lot of fun, and at least one person who tested the game for me (who had experience with RTS games) said he felt it was enjoyable to play. But it’s pretty clear to me neither the gameplay nor the difficulty was the main factor in the small number of downloads. I’m pretty sure the game’s simple, unrefined visuals, was the real culprit. Although I tried to market those as “retro” or “minimalistic”, the actual number of games with visuals that simple that become popular seems pretty small. The game’s unfamiliar genre (“casual” RTS) may also have been a factor in the lack of popularity.
While I have recently done some experimental advertising for PTF, and may continue to do so in the future, I have decided on spending the biggest chunk of my time on a new mobile game. It’s something along the lines of a puzzle game influenced by classic games.
This time around I have a different set of priorities, the most important being to spend a greater amount of effort and time on polishing the visual and UI aspects of the game. In all my game projects up until now I’ve always went the path of least resistance (meaning I spent the most time of my time on other elements such as gameplay, AI, level design, difficulty, etc.), but this time I will shift that balance.
Since my lack of artistic ability isn’t likely to change anytime soon, I’m making the best of what I have – still trying to keep to simple visuals while adding things here and there to please the eye. In particular I’m trying to add more animations to the game, for the background as well as at the start of each level. In between each player’s turn there is also a special animation I’ve spent some time refining.
Besides this emphasis on visuals, I’m hoping my decision to make a more standard puzzle game will give it better chances at popularity, while acknowledging that genre is extremely competitive.
The final thing I’m planning on putting more effort into is making an enticing preview video, since I feel that’s one of the most important things determining whether a user makes the jump to actually download an app or not. Of course the screen shots are also important, and since animations won’t show up in these I’ll have to pick what to showcase wisely.
I’m aiming at the somewhat arbitrary figure of 2x over my previous game’s downloads, though part of me is hoping I can get at least 10x. Even 100x wouldn’t result in a famous game, but if I can see concrete progress in some form it will motivate me more to keep along this route. Otherwise, I may chose to devote my time elsewhere.
Programming is great fun, but there’s nothing quite like the thrill of real users around the world downloading your mobile game, with a great degree of unpredictability around what will be popular and what won’t.
For this post, I’d like to talk about a minor tweak I did to Play The Field whose aim was to improve the gameplay.
Like most Real Time Strategy games, units in PTF have a maximum attack distance. This means that if an enemy comes within that range, they can attack (and unless ordered otherwise will attack).
Attack distance is especially important in this game because for many of the levels the player is forced to place units in very tight environments – sometimes in the middle of a group of enemy units just waiting to attack. This contrasts from most other RTS games where you have to create units at specific buildings.
By playing through a stage a few times you can figure out roughly where this attack range ends, but each unit has a different attack range so memorizing all of them is tedious, and visually identifying where are safe zones can be hard.
After realizing this, I decided to put a visual indicator of each unit’s maximum attack distance. After some experimentation, I decided on a light grey sphere around the unit showing the “danger zone” of that unit. This was implemented with translucency (an alpha value), and an interesting side effect is that these zones visually combine whenever they intersect. For example, for the region where two zones intersect it will twice as bright, and so on.
This not only creates interesting patterns, but gives you different levels of safety based on brightness of the zone. Dropping a unit in one of the brighter zones means you would be taken out almost immediately.
At first, I felt that this graphical change would be a big too busy and detract from the game’s mechanics, but after testing it I feel that it doesn’t interfere much with the gameplay. This is probably because the game’s visuals are already extremely simplistic, with a completely black background.
See the below screenshot for an example of what this looks like:
In the past I’ve briefly touched on how Play The Field was inspired by classic Real Time Strategy games such as Age of Empires and Starcraft. I was especially into the latter of these for many years (including expansions and follow up games), and for me when I really enjoy something I tend to want to make my own version of it.
Taking something like Starcraft, which typically takes several hundred people (including artists, developers, sound engineers, testers, managers, etc.) several years to make, honestly I would never have a chance to make anything close. Having said that, I enjoy game development (and software development in general) to the extent that whether my game would be popular is secondary, and in my college years I created a pretty detailed RTS game for the PC. In retrospect, it wasn’t that great but if you search around you may be able to find it online.
Now that I am into mobile development, it was only natural to try and make a RTS game for the iPad, but this time around my time is mostly taken up by my great job and my great family. However, I still have an hour or two in the evenings, and some time on weekends, so I decided on creating a very minimal game which captured some of the essence of RTS games. The fact it was made on a shoestring budget (both in a money and time sense) is why the graphics are also so simplistic. And due to the smaller scale and shorter timeline, I decided to group this game in the “RTT” (Real Time Tactics) category rather than RTS.
Just as with my RTS games on the desktop (I actually made a few if you go back far enough), the joy of coding a game is my primary motivator, but if people happen to download and enjoy my game, all the better. The game is completely free with no ads or in-app purchases.
To be honest, with a app store oversaturated already with nearly every type of game and app imaginable, I count every download as a tiny miracle (:
At some later point, I may talk in more detail about how I developed the game quickly with limited time, as it may be of use to some aspiring game developers.
[PTF on iTunes: https://itunes.apple.com/us/app/play-the-field/id985621862?ls=1&mt=8]
Mobile Game Development 