The main change in our lives is the hallmark out-of-college experience—we got full-time jobs. That’s what it means to be an adult, right? To bring home the bacon? Well, regardless of what being an adult truly means, getting a job and being financially grounded is important, especially in the independent gaming industry. Fortunately for us, work is fun. We work at a fabulous company called Rally as Fullstack Software Engineers. The work there is engaging and pushes us to learn new coding tools and techniques. Besides work, we play with the Rally soccer team too, and even managed to win the championship last season! The only downside to working is the 1 hour 30 minute commute, but we take advantage of that time by working on Realm Racer.

Alpha Build

     We are really excited about this one. Within the next month or two, we should have an alpha build ready and available for testing. This is a great milestone for us. Compared to our previous game, Realm Racer has required a lot more effort and thinking. We had to treat this game like we treat our work: one task at a time, incrementally building out the product. Hack'n'plan has tremendously increased our productivity by creating a task-driven mindset, enabling us to close out smaller goals without being overcome by the looming task of completing a game.

     Accomplishing the actual Android build was a little tricky with jME, since the stable SDK still uses the Ant build system. Our code exceeds the 65K limits specified by Google. An easy fix for this is to add some build dependencies in the “gradle” file of the app in in Android Studio to enable what’s known as a multidex build. What I ended up doing is copying our code from the jME3 folder to a new Android Studio project, and editing the gradle file. Luckily for us, it built first time without any hassles.

Issues

     We will leave the thorough testing of the game to our alpha testers, but we've come upon one major hiccup ourselves. My and Suchaaver's phones are on Android 6.1, but my dad's phone is on 7.0. When testing on the 7.0 phone, the shaders of the tubes and the car break. If you thought the current game might induce epileptic seizures, then playing it on a Android 7.0 will surely do so. When we do release the alpha build for testers, we’ll be gathering more info about this problem to address it accordingly.

The Good Stuff

     As always, we start out with a teaser gif of what the game looks like:

Obstacle Notifications

     The major functional update for the game is the obstacle notifications feature seen in the gif. The notifications show up when an obstacle is close enough to the player. We knew this was a very much needed feature due to how fast the player moves, especially when going around blind corners. If a rocket comes around one of those corners, then BAM—there is no way the player can react fast enough to dodge it. Thus, the dire need for notifications.

     It was a bit of a technical challenge for us as well. I had an idea of how I was going to approach the notifications, but I didn’t know how well my approach would work. What ended up working is the following:

1. When an obstacle is a certain distance from the player, start emitting a message from the ObstacleCreationControl to the HudControl that contains the obstacle's rotation from the center, distance from the center, and distance from the player.

2. When HudControl receives ObstacleCreationControl messages, attach a notification per unique obstacle message, and use the data to set its transform properly.

3. When the player rotates, emit messages from the PlayerControl to the HudControl with rotation information.

4. When HudControl receives PlayerControl messages, rotate the center node by which all other obstacle notifications are attached to in the opposite direction of the message's angle, keeping the notifications inline with the obstacles.

     This method works because at any point in time, any obstacle's location with regards to the player is a mere 2D projection of the obstacle on the player’s view once the tube is collapsed.

Functional Game GUI’s

     We have functional GUI’s now too. There are four GUI’s to consider: the main menu, the in-game hud, the pause menu, and the end-game menu. They are respectively shown below:

     Designing these is arguably the hardest and most frustrating part of using the jMonkeyEngine. GUI design using jME, if not using the Nifty GUI editor, leaves a lot to be desired. The libraries for the GUI’s are almost as powerful as any other GUI libraries, but the tooling to iterate quickly on GUI design is poor. The game has to be rerun in the editor every time changes need to be tested. It’s almost like front-end development without a server that automatically refreshes when assets have changed. Instead, a compile and rerun of the server is necessary followed by a hard refresh. That’s not how things are done anymore. Of course, our complaining only forces the question from the open source community: “Why don’t you build it then?” My response? It’s already been done in other engines, and I’m in the business of writing games, not tools. So while I’m not against writing tools, I just don’t want to put up with it right now. That ends that discussion.

New Shaders

     Shaders continue to be a point of experimentation for us. This comment on reddit echoed a thought we’ve had for quite some time—our shaders are seizure inducing. The effort is a mix of just using shaders to get the desired effect, or going back and UV unwrapping different textures on the model for different tubes. The former is seizure inducing, the latter is tiresome work. I feel as if the answer will lie somewhere in between, but Suchaaver will have an update ready when that really happens.

Emotional Impact

     I don't broach this topic often, simply because I find it difficult to put into words well. But there is something to be said about this topic now. After putting it on our phone, and showing it to my mom, dad, and little brother, something clicked. All of sudden, we could see them enjoying the game. None of them are mobile gamers (or gamers, except for my little brother), but to see them so casually hooked on our game meant we did something right. Out of the blue, my dad starts talking about monetizing schemes for the game. My dad doesn't know anything about the mobile gaming market (he knows much more about general market and business intricacies), so his strategies were a bit bizarre, but it's the fact that he opened up the discussion that matters the most. And our little brother offered to whip up some sample soundtracks to start testing some music. They say the games that make the money really capitalize on the 5% of their audience that does the spending, but I'd be happy just watching the other 95% enjoy our game. Just like my family did.

Thanks for reading buddy boys. Also, we may or may not (depending if time allows) participate in the Github November Game Jam to let us explore new ideas before getting back to the game. Regardless, expect an alpha release within the next two months!

     I want to dedicate a whole entry to the logo's creative process because of this post, which highlights the creative process behind Tiny Phoenix's logo. Despite what some comments say, I think the logo is splendid, and I'm glad the team reached something they liked. Designing a logo is not easy, and I learned that first hand while making our logo. Not all of you will agree with the decisions we made, and some of you may not like the final result. But doing this taught me a lot of things about what goes into a logo, and I think some if it may be useful for you to know. But just to be clear, this isn't a post about logo design. It's about the thought process.

Elrel

     What is "elrel"? It's a five letter word that has absolutely no meaning, as far as I can find. It's just what came to mind some 14 years ago when I made a funny sound with my mouth and Joraaver wanted to make the same sound, but couldn't. He just said "elrel." With that origin story in mind, I started making logos.

The Logos

     Let me start by saying that if the word means nothing, then starting is difficult. So just let go of your inhibitions and draw randomly. If you feel like, pray for a happy accident, in a Bob Ross sort of way.

     I started with some funny box icon thing. Let’s just say that was warm-up. I played with the idea of stick figures fighting or running through the logo. I imagined the animation. It was clicking. I liked that last one of the four.

Funny box things, and then people running.

     Then I toyed with the idea of letting the letters hang vertical. “Elrel” is a short enough word for that. Of those, I saw potential in the man standing in the rain, with lightning flashing. Animate that, and something pretty might still come.

Letters hanging vertical.

     Then I dropped the idea of stick figures and put some emphasis on the E. Think of the big old storybooks, where the first letter of the book or the chapter is some gigantic, fancily drawn form. Or look at Valve’s typography. I still wasn’t feeling any attachment to these logos though. Maybe I am not good enough or didn’t try hard enough, but I was not getting the vibe. It was time for something else.

Like a storybook?

     Where can you find meaning if the word has no meaning? For some it’s a stretch, but look at your (or your company’s) values or philosophy. What are you trying to achieve? These are ideas we hadn’t thought much about, but we tried to put some words down. At this moment, I thought of Vlambeer, the successful creators of Nuclear Throne, Ridiculous Fishing, and more. I hoped to find some insight to the logo of a seemingly random name, but alas, it actually means something. You can read about that here. However, they say that their logo was made "in twenty seconds." To me, that mean "don't sweat it." The logo doesn’t need to be better than sliced bread, just something you can be happy with.

     This leads us to the green sprinting foot logo. I think I was thinking of something lame like “live fast and free.” I can’t help it; I’m a Sonic fan. But really, it just looks like the less popular cousin of Adidas. No go.

     Now comes the fist. It has something to do with breaking barriers or new frontiers. I liked it, but it didn’t read all that well. The bird with the marmalade jar was an attempt to lighten up from the whole philosophy idea. It didn’t need to be that deep. It was a nice bird, but a far cry from a nice logo.

Fist and bird.

     Ahh, the lava lamps. They are captivating little contraptions which kept me pacified for many hours; perhaps in the way that our games should captivate our audience. We really thought we had something going in the last red logo. We were very close to just stopping and plastering that thing everywhere. Honestly though, we were 90% happy. I know that I said not to sweat it too much, but this logo is going on our games, our site, our lives. No pressure, but we weren’t there yet.

Lots of lava lamps (or cryogenic stasis tubes).

     Which leaves us with the dying cats. Now I know this is a tad unfair, but “elrel” isn’t perfectly meaningless. It was given meaning by my 7th grade teacher, who said it sounded like a dying cat when I made the discordant noise in class one day. I hadn’t really thought about it until this point because it was a tenuous connection. But I ran with it. Thus, we ended with the last cat. I like the first cat with bulging eyes more, but it’s too much an imitation for me to use comfortably. When I don’t know how to draw something, I make a blatant copy first (I can’t draw cats). But I digress. That’s our logo!

Lots of dying cats.

Here’s a summary of what I learned:

Types of Logos

     I believe there are three types of logos, with some icing if you'd like. You could make an icon-based logo, a typography-based logo, or a logo involving both. The icing? Animation. Not necessary and not always right, but good to keep in mind. The point here isn't to limit the type of logos you can make. It's to provide options. Sometimes you see a good logo and think that your logo has to have some funny character alongside a name, but that's not true. I had to keep reminding myself to change styles. Granted, because I’m not the best vector artist, some things were outside my time and ability scope, but I still tried to stretch my wings.

Source of Inspiration

     There are three things to look at when brainstorming: other logos, philosophy, and origin. I looked at Naughty Dog, Vlambeer, Bethesda, and a whole bunch of other studios. I even looked at non-game studios. I read about company values and learned how some studios were formed. There’s a gold nugget somewhere. Just keep looking.

     In a final act of complete contradiction, I will say this: it’s perfectly acceptable for your logo to mean absolutely nothing. It could be a flying elephant, while your studio is “Grounded Worms.” All it has to be is recognizable as your brand, and make you happy.

Thanks for reading, and feel free to discuss here or on reddit !

We haven't done any loading screen, which is why you see a funny flash of the tube before the actual game appears.

     To be a little more technical, JME currently has 3 GUI systems in place, either with native support or actively supported by developers. These are: nifty GUI, tonegodgui, and Lemur. All three are fine options, but Lemur really shows a tremendous amount of flexibility for very complex GUIs (even 3D). Granted, our GUIs will be simple, but Lemur also boasts CSS like styling, with which I am quite familiar. For this game, we are using Lemur.

     Since I’m no UI/UX artist, I went looking for examples or information to help me get started. Here are some of what I found helpful:

• http://gamesinspiration.com/ Provides a tremendous number of mobile game screenshots for references
• http://gameuis.com/ Similar concept, but not just mobile games. Still a new site, thus the library isn’t large.
• What Players Want A rather in-depth look at how UI is a part of the player experience.

     Like I said, I’ll keep this short. Keep devving!

Near miss with that second rocket.

     Suchaaver modeled a nice prototype rocket for use in our game, and it is now our game’s first moving obstacle. The design of the rocket pays homage to old school spaceships (think Pizza Planet from Toy Story). It’s fun, a bit nostalgic, and most importantly, fits the feel of our game by having a low-poly style to match the player vehicle.

Good ol' Pizza Planet providing some inspiration for that rocket.

What took so long?

     It took a lot longer than I anticipated to put the obstacle movement system in place. From the outset of this game, I knew I wanted to create a universal obstacle system that allowed for complex obstacle behaviors. In jMonkeyEngine, behaviors for spatials are manipulated via "controls." In order to enable this complexity without having to give each obstacle unique code, I planned to build the "controls" so they could be swapped or stacked with ease. That way, I can create future behaviors like my hand-drawn diagram below illustrates:

Possible obstacle movement patterns (and thinking of new obstacles). Under "Circular Moving," that obstacle is a saw, not an eye.

      "Static", "Forward Moving", and "Circular Moving" are unique patterns, but "Helical Moving" is a stacking of "Circular Moving" and "Forward Moving", and "Sinusoid Moving" is a combination of "Forward Moving" and I guess a "Static Sinusoid Moving" obstacle I didn't draw. As of right now, we have the first two covered in a way that I’m pleased with, since it allows for the evolution of the other obstacles in a Lego-like manner.

     We will have another update coming next week. Suchaaver didn’t push his code changes to our repository before we left for vacation, so we can’t quite show them yet. Yeah, that’s right. Our resident artist is writing code. Surprising? Well, it shouldn’t be, since he just graduated from UC Berkeley with a degree in Electrical Engineering and Computer Science. But that explanation can wait till next week!

In this post I'll talk about the look development of the whole thing. So let's get started.

From Humble Beginnings

Last time you saw the game, it looked like this:

That art was more “placeholder” art. I wanted to make the player feel like he or she is moving very quickly through a tunnel with lights evenly spaced within. Thus, I needed the lines of the tube to darken and lighten evenly. I could have painted a diffuse/color map with light and dark areas, but I decided to lightmap it. Why? Well, 1) with actual lights generating the lightmap the result is more realistic, and 2) I wanted to learn the process.

So I went into Blender, set up a lighting scheme, rendered the textures, and plopped them into the game. The result was this:

To me, this looked pretty good. But I was bothered by the fact that the lights weren't as bright as I wanted them to be. Something about lightmapping that I hadn't realized was that with basic lightmapping, things don't get brighter. They only get darker. That is because the traditional lightmap is multiplied over the diffuse, such that white on the lightmap acts as a pass-through (value of 1.0) and anything darker reduces the brightness on the diffuse map (read this polycount article for more). You can manipulate this, however, by defining how the multiply layer effect occurs in your game. If you set 0.5 to be your pass value, then anything above get brighter, and anything below get darker. You have to be aware though, because unless you scale it appropriately, the things that get darker don't get as dark as they would originally.

But where would you even write the code to deal with this?

The Answer: Shaders

Ahh yes. What a buzzword. The be-all and end-all of any cool effect ever achieved in a videogame. I always knew when I started learning about graphics and game development that I wanted to learn how to write shaders. I thought my graphics course in college would teach me that. Alas, it taught me many important things which I use right now when I think about this game, but it did not teach me shaders. However, after spending a solid day understanding how shaders work (in general and in jMonkeyEngine), I figured it out. They work the same pretty much everywhere, and honestly, they aren't that complicated. It is true that they can get very complicated, but to learn them isn't so hard. In fact, if you want to learn about them, I recommend this article.

But yeah, shaders are where I could define how multiplication would occur. However, it became apparent when playing the game that we wanted it to be much brighter overall. We wanted it to have bright vehicles, bright obstacles, bright lines, and be very vibrant. Thus, I worked to achieve brightness without walking too far way from my initial idea. Which resulted in this:

Pretty colors, right? Let me walk you through the shaders that made this possible:

Vertex Shader

uniform mat4 g_WorldViewProjectionMatrix;  
attribute vec3 inPosition;  
attribute vec2 inTexCoord;  
uniform float g_Time;  
uniform sampler2D m_LightMap;  
uniform sampler2D m_DiffuseMap;  
varying vec2 uvCoord;


void main(){  
    //Transformation of the object space coordinate to projection space
    //coordinates.
    //- gl_Position is the standard GLSL variable holding projection space
    //position. It must be filled in the vertex shader
    //- To convert position we multiply the worldViewProjectionMatrix by
    //by the position vector.
    //The multiplication must be done in this order.

    uvCoord = inTexCoord;


    gl_Position = g_WorldViewProjectionMatrix * vec4(inPosition, 1.0);

}

It's a pretty standard vertex shader. By definition, a vertex shader manipulatesw where the vertices of a model end up on screen space. It just takes in the vertex position and converts it to the appropriate screen coordinates. The game time, light map, and diffuse map are passed in to be shared across both the vertex and the fragment shader. The “uniform” declaration means the information is given to the shader from elsewhere, and is shared across both parts. The “varying” declaration means that the variable will be passed from the vertex shader to the fragment shader. The vertex shader also has a bunch of information that comes into it that is related to the current vertex, all prepended with “in”. These are declared as “attributes.” Therefore, you can see the use of inTexCoord (the UV texture coordinate of the current vertex) and inPosition (the 3D position in model space). You can usually look up what information comes into the vertex shader.

Fragment Shader

A fragment shader decides the color of each fragment (pixel, less accurately). My fragment shader is much more interesting. Let's take a look:

uniform float g_Time;  
uniform sampler2D m_LightMap;  
uniform sampler2D m_DiffuseMap;  
varying vec2 uvCoord;  
void main(){  
    vec4 df_color = texture2D(m_DiffuseMap, uvCoord);
    vec4 lp_color = texture2D(m_LightMap, uvCoord);
    vec4 cur_color = lp_color * df_color * 2.0;

    vec4  kRGBToYPrime = vec4(0.299, 0.587, 0.114, 0.0);
    vec4  kRGBToI = vec4(0.596, -0.275, -0.321, 0.0);
    vec4  kRGBToQ = vec4(0.212, -0.523, 0.311, 0.0);
    vec4  kYIQToR   = vec4 (1.0, 0.956, 0.621, 0.0);
    vec4  kYIQToG   = vec4 (1.0, -0.272, -0.647, 0.0);
    vec4  kYIQToB   = vec4 (1.0, -1.107, 1.704, 0.0);

    // Convert to YIQ
    float   YPrime  = dot (cur_color, kRGBToYPrime);
    float   I      = dot (cur_color, kRGBToI);
    float   Q      = dot (cur_color, kRGBToQ);

    // Calculate the hue and chroma
    float   hue     = atan (Q, I);
    float   chroma  = sqrt (I * I + Q * Q);

    // Make the user's adjustments
    hue += g_Time;

    // Convert back to YIQ
    Q = chroma * sin (hue);
    I = chroma * cos (hue);

    // Convert back to RGB
    vec4    yIQ   = vec4 (YPrime, I, Q, 0.0);
    cur_color.r = dot (yIQ, kYIQToR);
    cur_color.g = dot (yIQ, kYIQToG);
    cur_color.b = dot (yIQ, kYIQToB);

    // Save the result
    gl_FragColor    = cur_color;
}

The first two lines are standard—read in the diffuse texture color and the lightmap texture color for this vertex. The third line is where, for a normal lightmap, I would multiply the two colors together. However, I multiply the result by 2. What does this do? If the lightmap were at 50% gray, then the shader treats it as white and keeps the diffuse color. Any higher and the diffuse color is brightened. However, as I said previously, things don't get as dark. Only the blacks stay black (0 multiplied by anything is 0).

The convoluted code below is what changes the hue of the colors over time. Honestly, I don't understand all the specifics of the algorithm, but it essentially converts the RGB space into an alternate space where one can then simply do a rotation calculation to shift the hue to something else. I do a rotation based on the time. At an even higher level of abstraction, you can see that it's difficult to change the hue of the color in RGB. If you had an HSV representation, you could just change the hue value and be done with it. I recommend reading this (it is where I got this code from). I'll be doing more reading about it too.

Extra Step

Now, my next decision was probably completely unnecessary and may not make it into actual gameplay, but I couldn't resist it with my newfound powers. First, I'll show you a new vertex shader (only the last line is different):

uniform mat4 g_WorldViewProjectionMatrix;  
//The attribute inPosition is the Object space position of the vertex
attribute vec3 inPosition;  
attribute vec2 inTexCoord;  
uniform float g_Time;  
uniform sampler2D m_LightMap;  
uniform sampler2D m_DiffuseMap;  
varying vec2 uvCoord;


void main(){  
    //Transformation of the object space coordinate to projection space
    //coordinates.
    //- gl_Position is the standard GLSL variable holding projection space
    //position. It must be filled in the vertex shader
    //- To convert position we multiply the worldViewProjectionMatrix by
    //by the position vector.
    //The multiplication must be done in this order.

    uvCoord = inTexCoord;

    gl_Position = g_WorldViewProjectionMatrix * vec4(sin(g_Time+inPosition.x)*0.5 + inPosition, 1.0);
}

It simply scales the sine of the addition of the game time and the vertex's x position and adds the result to the current position. Here's what it actually does:

I'm sorry, I just couldn't help myself. Maybe it's cool, and playtesters will love the idea. Or, everyone will say that it just distracts from the actual goal of the game. Either way, I'm just glad I now know enough to do this kind of thing.

In Conclusion

I don't know how much of this will make it to the final iteration of the game, but regardless I think this spring break was very well spent. Let me know if you have any questions regarding the shaders or any aspect of this post (feel free to correct me if I said something wrong). Maybe I'll let you guys tell me whether or not you think the result is interesting enough to keep!

     I'm quite happy with the progress we've made. It's been considerately motivating, applying different software engineering principles and seeing what a difference they make in game. I'll discuss what those changes are and reflect on why they've made me a better coder.

Aesthetics

     The gif below sums up most of what the game looks like now:

     The game has gone from just a bunch of debugging objects to actual art. We tweeted some concept art we had in mind for one possible slice of the game and have, to some degree, implemented that art. The tubes and the car currently reflect that. However,you'll note that the lines on the tube are very large. I had to perform some scaling due to nonstandard sizing of the models. Don't worry, I complained to our artist, and he says he has now standardized the sizes of all the models.

     The gif doesn't demonstrate the sound of the crash. It's just a royalty free sound, but we will change it later to align with the games feel.

     Obstacle collision technically records damage to health as well, but there is no GUI for that yet. In fact, there is no GUI at all. Suchaaver is hashing it out, and we'll hopefully have some sense of a GUI in the coming months. If he knows what he's doing, it'll follow his post late last year regarding GUI design. We may even do an analysis of different GUI schemes we drew up and how they rank. I think that would be pretty cool.

     Finally, the gif doesn't reveal that it currently works on Android. Have to make sure the target platform supports it, right?

Code

     What really excites me are the programming patterns I've implemented. Part of why I make games is to learn how to build them; making changes so that the code is cleaner, faster, and more scalable is an essential part of that process.

Messaging Queue

     It was becoming harder and harder to manage the interaction between my objects; simple things such as telling my TrackCreationControl to generate a new track piece were no longer easy. However, two pieces of reading kicked in, saving me from horrible code. The first is Game Programming Pattern's page on Event Queues. The article articulates very well when messaging protocols are needed, and my situation definitely called for it*. GameDev Tuts “How to Implement and use a Message Queue in Your Game" gave me a practical and minimal way to implement the queue.

     I introduced a CommunicatingObject interface which any object that needed to throw messages around implemented. Then, in the style of the tutorial, I created a MessageBroker and a Message class. Now, say, the player finishes a turn on the track. The following actions take place:

1. The TrackPieceDeletionControl fires off a message to the TrackCreationControl telling it to generate a new piece.

2. The TrackPieceDeletionControl deletes the turn piece. 1 & 2 are performed in the code below:

   private void delayedDeletion(){
       Message m = new Message(
           "track creation",
           this,
           "deleted",
           -1);
       MessageBroker.getInstance().sendMessage(m);
       obs_destroy = null;
       bas.getPhysicsSpace().remove(track_piece.piece);
       track_piece.piece.removeFromParent();
       bas.getPhysicsSpace().remove(this);
   }
   

3. TrackCreationControl receives the message and generates a new piece:

   public void onMessage(Message m) {
       if(m.getFrom() instanceof TrackPieceDeletionControl){
           removeDeletionControl((TrackPieceDeletionControl)m.getFrom());
           createPiece();      
       }      
   }
   

     I may think about adding a relay message back to the TrackPieceDeletionControl to let it know when TrackCreationControl has created the new piece, but that's a redundancy I'll implement if sufficient testing deems it necessary.

Singleton

     This is a simpler idea, explained once again by the fabulous Game Programming Patterns Singleton article. Right now, the singleton design pattern is being used for my MessageBroker class. It dictates that there only be one MessageBroker, and prevents me from accidentally instantiating another MessageBroker to put a message on a queue. It has a fairly simple use, but it does the job of making me have to think less. That's a plus.

Flyweight

     I didn't have to implement this design pattern because but it is already provided by the jMonkeyEngine API. I just wanted to take a step back and appreciate it. As described by, wait for it, Game Programming Patterns Flyweight article, the flyweight design involves making objects more lightweight by moving extrinsic data in a single place for more efficient access and usage. In our game's case, each of the barrels is cloned. With no animation, this means they all share the same mesh, optimizing the use of the barrels. Huzzah! These little things under the hood make a difference, especially when developing for mobile.

* I'm not foreign to messaging systems. I have worked with RabbitMQ in a larger software setting. But being told to work with something versus deciding for yourself when to implement something are very distinct roles. It can be rewarding to see your decision play out in your favor.

     The updates are done. For now.

     The roadmap in the near future involves getting this to a prototype that people can download and test. To get that going, we want to have

• A GUI of some sort in place
• A scoring system
• An end to the level

     When the last bullet point comes to life, then the game becomes a much more modular system, and scaling it will be fun. But we'll cross that bridge when we get to it.

     Watch our twitter, and stay tuned!

WARNING: There may be a spoiler or two in this article. I'm not saying anything explicit about the game's narrative, but a picture of a map may reveal information you don't want to know (or something like that). Tread carefully.

The Encounter

     Far Cry 4, for those unaware, is an open-world first-person game set in the dangerous yet beautiful nation of Kyrat.

     When my friend and I play, we go "question mark hunting." All the hidden caves, items, or places on the island that one has not stumbled upon show up as question marks on the map, like so:

     Thus, we went on our merry way playing Dora the Explorer. One of us was Dora and the other was Boots. It was all tremendous fun, until we reached our next location. It looked like a hole in the ground covered with boards.

The First Try

     The triangular space allowed me to squeeze through, so I did. I thought I might be able to attach the grappling hook as I fit through, but instead I failed magnificently. I slipped through the hole and fell to my death. In fact, here's a clip of what happened:

     Clearly, dying is not the right way to reach the bottom. My friend crouched down with the intent of attaching the grappling hook first and then jumping down the hole. However, this is how it turned out, from my perspective:

     The cable wrapped around odd places and he became a contortionist. However, he couldn't get down. Thus, we were left without options. Surely, it couldn't be this hard.

MacGyver It

     My friend had a flash of inspiration. One of us could pilot a gyrocopter over the hole while the other hung below it via grappling hook. Once the chopper was in position, the man below could potentially lower himself into the hole and all the way to the bottom of the cavern. Here is our trusty method of locomotion:

     Though I didn't record it the first time, my friend and I sat down to do a re-run and record it this time. Mind you, it was my first time doing game recording, so you'll have to forgive our occasional banter about that and other random subjects (I now know that "bow" is the front while "stern" and "aft" can both refer to the back of the ship). I also had a bit of a cold. Go to the 2 minute mark if you want to skip some discussion.

     It was a little complicated, but in the end, it worked. Notice what happened at the end. I shot and broke the boards, and my friend could grapple down easily. In fact we could have done that when we first saw the boards. We were supposed to do that! What took us 25 minutes should have taken us 2. But you know what? I didn't regret a second of it. I'll remember this event for many years, probably because I was having fun. At some level, that's what every game aims to be: fun.

The Realization

     Besides just being fun, I immediately realized this was a perfect example of emergent gameplay (which I promptly described to my friend). I wanted to do some more research regarding emergent gameplay, and so here we are.

     Emergent gameplay is a scenario in which the simple rules or mechanics provided to a player can be utilized such that their combination creates new and/or unintended strategies. Utilizing the grappling hook of the chopper to bypass the destruction of the boards was an unintended method of descending into the hole. That said, my definition might also be a point of contention for some. It's debatable whether or not emergent gameplay has anything to do with the game designer's input.

For example, if the game designer provided a mechanic whose depth and complexity was massive but fully intended by the designer, is a player's discovery of this complex utility emergent? Some argue that true emergent gameplay arises when no part of the system can explain the complexity of the emergent property (like the rise and fall of market prices)¹, which has nothing to do with the designer's intentions. In fact, Jochen Fromm theorized four types of emergence², which I briefly review here:

• Nominal or intentional emergence, which derives from systems with no feedback or only feedback on the same level. The example used is man-made machinery in which the function is a designed emergent property of the components, but lacks flexibility because of it.

• Weak emergence introduces top-down feedback between levels of the system. Flock behavior of birds is an example of such emergence; birds react to the birds in their vicinity yet all of them move as a group.

• Multiple emergence describes the complexity when multiple feedback loops interact at different levels of the system, such as in the stock market, or Conway's Game of Life.

• Strong emergence is a little tough to immediately agree with, but it describes systems where the highest level of emergence is completely separate from its most atomic particles. The examples used are life as an emergent property of genetic systems and culture as an emergent property of language and writing. I feel the connection is a bit tenuous, but you can form your own opinion with more reading.

     Regardless of how it is defined, emergent gameplay is fascinating because it's difficult to get right. It isn't something you can reverse-engineer or truly plan for. It's also difficult to accurately predict. If one were designing with the dream of emergent gameplay in mind, one would have to ensure that the game rewards the result and not the method. I'm sure many of you have played a game where you've gotten past some part of a level, but not in the intended way, and so something funny happens, like the enemies in the next sector fail to load (Sonic Heroes, anyone?). That's an example of rewarding method instead of result, and that denies emergence (or freedom, if you view emergence differently). The design can be much more involved than that, but I would suggest reading the second article in the source list below for more.

Summary

     Though this post was more an opportunity for me to tell a story and explore a topic I developed an interest in, I hope it was of some value to you. Emergent gameplay, while difficult, is not something I would write off as immediately out of reach. Next time you are designing some game mechanics, think about how you might relax the rules to provide some feedback or interplay. I've included some sources for further reading because I only scratched the surface here. The comments of the first article are truly engaging; I would take my time there. The second link is a research article examining emergent gameplay and how game systems can be visualized with UML (Unified Modeling Language). Both are excellent reads.

Sources

1. Gamasutra - Examing Emergent Gameplay

2. Research Article - Visualizing Game Dynamics and Emergent Gameplay

      That being said, we recently learned of Nielsen's heuristics for interface design and the method of heuristic analysis in general. I'd like to share with you all how a heuristic analysis is done and why it might be a good thing to do for your game. I also did a heuristic analysis of two games to see what I could learn, and how I could apply those principles in the future.

Heuristic Analysis

      Before I go any further I must say that if you would like to hear an explanation on this topic from the man himself, here is the link: How to Conduct a Heuristic Evaluation. A majority of the quotes I use will be from this site, unless I indicate otherwise.

      To be succint, "Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the 'heuristics')."

      Essentially, the evaluators comb through the interface and use the heuristics to bring out any failures in the design. The heuristics make it so the evaluators are not biased in their responses. Different evaluators may feel differently on the subject of design "failures" if left to their own devices, but the heuristics make it so their personal beliefs have minimal contact with the interface and the report. The research indicates that the use of around 4 or 5 evaluators yields the maximum return for the minimum cost (paying evaluators).

      Each violation noted should come with a severity rating (from 0-4, 4 being the most catastrophic).

      Which heuristics do we use? Well, that's a tough one. Some research has focused on creating usability guidelines with regards to gaming, but games are so varied in their design that it may behoove you to make your own heuristics. As for the games I look at in this post, I'm using Nielson's 10 heuristics which I mentioned above. They may not be directly applicable, but I still think it's worth trying.

Heuristics and Your Game

      Heuristic evaluation is known as a "discount" method in some HCI circles because it can be done on the cheap. You don't need to hire people to help perform a large scale user test or an experiment. You can take your UI, HUD, or whatever screens you would like to evaluate and do the evaluation yourself. That, or someone who didn't design the UI can evaluate it. Either way, you get to iterate on your UI, so that when the user test rolls around, the users can spend more time ripping apart your gameplay and less time ripping apart your UI (the dream).

      I'd like to point out that I am discussing the evaluation of user interfaces and NOT gameplay mechanics/interaction as they relate to games. Gameplay is a whole other beast which has its own research. Check out the sources below to see some research articles regarding the subject, plus some heuristics geared towards gameplay evaluation.

The Studies

      So, which game did I decide to look at? Our own, of course! When I was thinking of which game to examine, I thought tearing apart our own game would actually prove pretty useful for further work. It isn't very complex, but even a simple game can have problems. So, without further ado:

The Sharpest Blade

      Here you see the start screen. Immediately, I see a violation of the "Aesthetic and Minimalist Design" heuristic. The design is fairly minimalistic, but what about the aesthetic? Honestly, the font makes me cringe. Is that "The Sharpest Blade," or "The Gharpest Blade?"

      I would say this problem deserves a severity rating of 2 (minor usability problem, low priority). Some might say it deserves a 1 or 0 because it is purely cosmetic. I argue that the font is used in every screen, including the title of the game, and thus may hinder experience everywhere.

      This is the pause screen. Again, I can see a heuristic violation, namely, "User Control and Freedom." Usually a player would like to unpause after pausing the game. That functionality should be immediately available to the player, but even I, a developer, had to figure it out by scanning the text.

      Instead, what is instantly recognizable are the two buttons, "Quit" and "Home." At first, I thought "Quit" would go to the start screen. But then what does "Home" do? Clearly, this is a violation of the "Consistency and Standards" heuristic. After clicking around, I figured out "Home" brings the user to the start/home screen, while "Quit" quits the game. It sounds like common sense, but I hesitated when I first thought about it. There should be no hesitation. That should be fixed.

      While everything I have pointed out so far is not an interface disaster, each flaw deserves a severity of about two (minor problem, low priority). It can be argued that the font issue is purely cosmetic, but I believe that since the font is always visible at some point in the game, it deserves more attention.

      Now, for contrast, here are some notes on a far more polished game:

Hearthstone: Heroes of Warcraft

      Since this game saw plenty of design screenings and iterations before launch, I won't have too much to actually critique. I will, however, take note of certain design decisions that I feel are important or interesting. Some of these might be obvious while others not so much. These should make sense even if you have very little knowledge about the game.

      Here is the screen displayed when you click on "Quest Log." A very simple yet important design decision was made here. To close the dialog one must click anywhere except the Quest Log dialog itself; there is no "X" button to close the dialog. This follows a convention that a lot of mobile apps have been using as of late. Given the limited real estate of a mobile device, hitting a small "X" can be a low percentage shot, resulting in unecessary frustration. Since Hearthstone is on both desktop and mobile platforms, it keeps a consistent UI that follows convention, making the interaction easier on the player. This practice is used for a few other dialogs in the game too, such as the Options dialog.

      This one is pretty obvious: it's the "loading" screen of Hearthstone's matchmaking system. It's cleverly artistic, but most importantly, it gives the user an indication that something is actually happening. Players crave feedback, whether it's something trivial, such as firing a bullet, or something more serious, like whether the computer has frozen or the level is still loading. It's Nielson's "Visibility of system status" heuristic. Just something to keep in mind.

      Here is the "My Collection" tab, which allows a player to browse through the decks and cards in his or her posession. I've circled the search bar at the bottom because it adds particular value to the system: flexibility and efficiency of use. This might also be obvious, but when I had a smaller collection I used to flip through the pages until I found what I wanted. It's purpose becomes immediately clear to the more experienced players with larger collections. As Nielson describes this heuristic, "Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions." These are much akin to macros in Photoshop, for example.

      This is the battlefield, that is, the screen of the actual combat in the game. The most interesting thing here is that the battlefield is asymmetric. Your hero faces you, as does the enemy hero (and the enemy hero power). It would have been very easy to just develop one symmetric board and display the correct orientation to the player, as many board games do. This one breaks that convention in a way that makes sense. If there's something to learn from this decision, I would say that it's to not be trapped by the convention of the genre of game you are developing.

      I don't have a picture for the final design decision because it's an audio decision. When you no longer have enough mana to play any card and you have no other moves you can make, a voice says "Job's done!" A lot of people find it annoying, but for the less experienced players, I feel it eases the burden of determining if one has exhausted all options. It allows for more focus on the next turn. I can't find a decent clip of this actual event occurring, but here's the audio nonetheless: Job's Done!

Summary

      Getting your game tested by users is great, but it only works well with a certain level of polish and gameplay. If you aren't there yet or you can't do multiple user test iterations, sometimes you have to test the game yourself. When you do, it helps to have a plan. Approaching your UI/UX design via heuristic analsyis is a cheap yet effective way of testing. If you give it a shot, let me know! I'm interested in hearing how it turns out.

Sources

Heuristic Evaluation of “FarmVille”

http://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

http://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/

What makes Virtual Reality any different?

     At first, when we were all coming up with ideas for our games, a lot of them were rejected outright by our professor. The continuity needed in virtual reality requires a different kind of gameplay. There can be no cutscenes, no eye-blinking, no arm movement, no looking at oneself in mirrors—all these things can break the experience. This limited selection caused around eight of our fourteen teams to create horror games. Luckily, our team went a different route, really focusing on how the Oculus Rift allows a new range of movement with the head.

What did my team do, specifically?

      We named our game Heighten on the premise that the player has the ability to heighten his senses after focusing on an object. Imagine the game has the player start tied to a chair, and there are two guards talking outside. With the Oculus, the player could swivel his head and focus on the guards. Slowly, his hearing perception increases, and what used to be the quite mumble of the guards now seems as if the guards are whispering in your ear. A picture with a link to a full video below demonstrates our attempt to catpure this experience

Video of the game in action

      The intro should be enough to understand what's going on, but to put it into words, some of the guards holding the player captive are actually on the player's side, helping him escape. Nothing distinguishes them except for the scent that can detected by a very powerful sense of smell, one the player can develop if he focuses. Problem is, focus too long on the wrong guard and he starts to get the feeling that someone is staring him down, and tells the player to get back to work. Through the game, we focus on head movement, AI interaction, and trying to keep the player invested in this "undercover" feeling. The guards that do want to help give you tips to help the player solve the puzzle in each level, granting him access to the next stage. ¹

Technical Takeways

1. Always keep your audience in mind.
2. Ask for feedback as soon as you can.
3. Parallax mapping is a must for detail in VR.
4. Use Unreal Engine's Blueprints for prototyping.
5. Understand your hardware limitations!

      The first two go hand in hand. I hade two roomates who could have easily provided instant feedback, since they were my target audience, yet I didn't show them the game until the very end. That was foolish on my part, since I could have changed so many little things much earlier on, like if the heartbeat were too loud, or the focus mechanic took too much time, or whether or not the clues were easy enough to understand. Readers, when you have a chance to receive feedback, take it!

     Parallax mapping is an enhanced form of bump mapping, giving small depth to textures. From http://graphics.cs.brown.edu/games/SteepParallax/

While the effect is minimal, it greatly helps create better immersion with more realistic objects in VR.

     Unreal Engine's Blueprint system is phenomenal for GUI based programming. However, the deeper you get, the more complicated all the wiring becomes, and frankly, my team was frustrated at points where we felt the blueprints were limiting our coding. For prototyping, it is amazing, simply because of how fast one can crank out logic. But when classes and entities become necessary, and algorithms are more compilcated than a for loop or two, I feel coding it in C++ would have been a faster approach.

     Number four is just an Oculus VR thing. At the beginning of the quarter, none of us had a machine with the specs capable of running it, but we managed to MacGyver a solution to get a Windows machine with a good enough graphics card to start development. Do the research beforehand and know the hardware being handled. It never hurts to come prepared, and it always hurts when you don't.

Now, for the qualitative analysis.

It is Time-consuming

      Somehow, I thought things would be different. I thought this would be a structured class with both the theoretical and the practical in mind. I thought it would have projects involving different aspects in VR, and that I would have ample time to do it all. I was wrong.

     The class consumed both my time and my thoughts. It wasn't very structured in the beginning (were we doing two games or one; was multiplayer a requirement or a plus?) and we only had a grasp of what was expected of us halfway through the course. Our team was working well into the night, and I actually skipped all my classes the final week and pulled 4 all-nighters (3 back to back, with about an hour of sleep total) to work on the project. Life was tough.

It is a Recurring Theme

      I don't want to perpetuate the idea that game development is a career that demands sleepless nights and a risky future. Maybe it's just that as new developers in a market saturated by the like, we don't learn from each other's mistakes as well as we should. Only problem is, the wise learn from other's mistakes (via postmortems), but the wise realize that learning is doing. So who is wiser? I can't answer that yet, I'm still reading the postmortems.

     On the flipside, everyone in the class suffered similar fates and voiced similar concerns, so at least we were all in this together (another recurring theme)!

It is Rewarding

     Getting week to week homework isn't much of an achievement. But getting a solid demo for a game in ten weeks is greatly rewarding. Being able to physically work with other game developers isn't something new indie developers get the chance to do, so this was a new and exciting experience. We were able to receive continuous feedback from our professor and iterate on the game to the point where experts from Unreal Engine who had come down to take a look at our games were thoroughly impresseed. In game development, it's the feedback developers look most forward too, and to receive such praise from professionals in the field is more than any student could have hoped for. In fact, just last week, our professor gave a forty-five minute lecture on "AI Interactions in VR", including video clips from each of our projects at Siggraph. How many students get that opportunity? I was happy with the class' conclusion, to say the least.

Conclusion

     Should you take a game development course? I think you should, but only if it offers an interesting experience or one that isn't easy to obtain. For me, being able to use the Oculus Rift sealed the deal. If it were a regular game development class, I may not have taken it.

      Once you've committed to the class, prepare to sacrifice a large number of hours. That being said, it still is a class; enjoy your time spent, see what others create, and enjoy the experience.

1: Forgive the game for any lackluster art or bad voice acting. A budget of $0 and a timeframe of 10 weeks doesn't leave much room for these choices, since the game mechanics were much more important than the stylistic concerns, even though we were dealing with a VR experience.

     We've done some concept work, and are pretty satisfied with the direction of the game. It's planned to be mobile game—an endless runner, to be exact. However, what excites me most is that it will all be procedurally generated. The whole game. I'm talking the track, the obstacles, the power-ups—everything (even the environment, if we are really good)! It might be slightly hard, trying to balance the game and give the user a fair chance at making some headway, but the challenge will be fun and, more importantly, a learning experience.

Concept Art and Inspirations

     We drew inspiration from some things that consumed a large part of our childhood: HotWheels!

Concept art from player view.

     To be more specific, Hot Wheels World Race, Hot Wheels AcceleRacers, and Hot Wheels Velocity X. The first two are movies (well, we own the game for the first one as well, but the the movie was the real inspiration), and the last, a game. The main inspiration from the movies is the exhilarating speed at which the drivers move through bizarre environments, all the while surviving dangerous obstacles.

(Top) Scene from Hot Wheels World Race as the StreetBreed team helps the racers navigate an alternate route on the ice. (Bottom) The Cosmic Realm in HotWheels AcceleRacers.

     The game lends the idea of power-ups, but not quite for the same purpose. In the video game, you have to fight other cars. In ours, you are only trying to drive for as long as possible.

Car with top mounted weapon, approaching another power-up, in HotWheels Velocity X. Picture courtesy of www.gamesdbase.com

     In the end, this game has a lot to do with simply reliving our childhood passions, but through our new passion in game development. What you receive, you must give back, right?

Procedural Generation

     Now, I want to give a small explanation for how I built the procedurally generated track. The main gist of the procedural generation is heavily borrowed from this GameDevTut. I'll show you some of the integral parts that makes ours just a tad bit different.

     First, a simple picture of one of the main pieces in the prototype of the track:

Red is the X axis, green is the Y axis, and blue is the Z axis.

      You'll notice that I have at the start a node oriented as per the tutorial. The other node is at the green arrow, and it follows the same protocol (you just can't see it because in jME, one can select all the nodes, but only the first one's axes shows up).

     Now, after implementing the tutorial's algorithm for connecting pieces, and a little of my own hand waving, we get this cool piece of work:

     It took a little extra work in jMonkeyEngine to visualize the correct movement, both position and orientation, of the nodes with respect to the scenegraph. In fact, there is more to this track than meets the eye. If you think about how the current procedural generation works, my track can easily collide with itself within a couple of iterations of the loop, simply because of how my track can turn left or right every time. Three turns and BAM—I've hit my track already! How do I avoid this?

     Well, there are two trains of thought for this. Like many endless runners, I don't need to store the rest of the track behind the user. Therefore, I can destroy the rest of the track behind the user, and that way, any conflicts with it will be avoided.

     The only issue with this is its dependence on how far ahead of the player the track is being generated. If it's extremely close, then it'll probably work. However, this means the player might be able to see the track being generated. While, in some games, that mechanic works really nicely (there is a game I saw from /r/gamdev's Feedback Friday, but I can't recall its name; please link it if you can), we don't think it suits our game too well. While I should still be deleting the track behind the user for memory purposes (it's being culled, but I don't want the camera to even have to think about whether or not to render it), I need another way for the track to not collide with itself.

     This is easily accomplished with some raycasting techniques. The pseudo code goes something like this:

boolean[] canPlace = new boolean[]{true, true, true};
collidables = track
loop:
    node = Node to attach next piece too.
    left_cast = raycast to the left
    right_cast = raycast to the right
    forward_cast = raycast forward
    left_collisions = new CollisionResults();
    right_collisions = new CollisionResults();
    forward_collisions = new CollisionResults();
    node.collideWith(left_cast,left_collidables);
    node.collideWith(right_cast,right_collidables);
    node.collideWith(forward_cast,forward_collidables);

    if(left_collidables isn't empty) canPlace[0] = false;
    if(right_collidables isn't empty) canPlace[1] = false;
    if(forward_collidables isn't empty) canPlace[2] = false;

    Random number from 0-2. If it's false, repeat. Else, use that as chosen direction, grab appropriate piece.
end

     This is slightly naive, since I don't check the distance to my previous track in the collidable, just that it's there, either in front, to the left, or to the right of the current track piece. This means the track will never turn back in the direction of previously laid down track. Instead, I could have checked what the distance to each first collision was, and then made the decision as to what track piece to lay down. That's just only a couple calculations away from what I've done currently, so whether I put that in or not won't affect the code heavily, but it may affect the design of the game.

     See the second half of the image in our concept art? It shows the user on the outside of the track, able to view the environment he is driving through. Currently, the code implementation deletes the track the user has been through and never has the track turn back on itself. But these both mean that the user will never be able to see how far he has come. If you were driving on the inside of the tube, and all of a sudden, jumped to the outside, wouldn't you want to take a second to view the world around you? Take a second to see just where it is you are driving through, and how far you have driven to get there? I know I would, and I hope to build that feeling into the game. There's another reason for this too (more childhood inspiration!), but I'll save that for another post.

     You may notice in the gif that an axis object is rotating and translating around the track. That's how I'm moving the player around the track! Think of the player as merely orbiting around this point—that's all it is. That, and some camera adjustments, gives us our latest twitter update:

     That's one hefty update! Hope you enjoyed that!

That's all, as far as announcements go. Now for the real topic of conversation--

Perspective

In a small studio, most people wear multiple hats during the development process. For teams of less than 10 people, game design is often a decision made by multiple members, not all of whom hold the title "game designer." Similarly, a small studio may not hire a specific person to deal with all PR material--it may be a joint venture by some programmers and artists. This is perfectly acceptable given a lack of resources and time. But visual and sound artists as well as programmers have decisions to make too. So why aren't things like game architecture or implementation decisions discussed with people not in the discipline? I believe we can attribute this to a lack of perspective.

In a game jam I recently participated in, I had my first real experience with a game engine (Unity, to be specific). I had written 2 games before in game jams, but they were HTML5 games written with JS libraries. Those aren't exactly engines, if you will. That having been my first real experience, I came across decisions that I thought wouldn't even be relevant in developing the game. For example, a score multiplier was received when the player takes the thinner path. How would I know? My initial idea involved checking the collision between the ball and the current platform it is touching to examine the width of the platform. This would occur for every platform, for the rest of the game time. That's a lot of collision checking to do, and probably not a smart idea. So I asked my brother how he might do this, and of course, the answer came to him naturally--create a block at the start and the end of every thin path with the same width as the path, and let them be triggers. If the start block detects a collision, then a score multiplier is given based on the width of that block. When the end block is triggered, the score multiplier is reduced to 1. It was a no mess-solution. Clean and simple.

Why hadn't I thought of that? Because I lacked perspective, and perspective enables a way of thinking. I'm a computer science major, so I'm not new to the rodeo, but where games are concerned, I'm the artist--I never learned the methodologies and thought processes that are involved in designing a game from the code side. We both discuss game design, sure. However, when my brother runs into a coding issue that isn't an error or a bug, but rather a design issue of the architecture--now I can help too. Maybe not immensely or immediately, but experience enables. No part of the pipeline ought to be thought about in isolation.

So what am I trying to say? Should artists learn to code, and progammers learn to create works of art? No, not quite. But I do believe that artists ought to take the effort to see the world of game development through the eyes of the programmer, and vice versa. The programmers can take steps to learn the troubles and decisions of the artists, without having to learn so much about the technical detail. Similarly, artists can learn some of the peculiarities of the engine and tools without learning how to proram. Having people more informed about the decisions other disciplines face in the pipeline leads to more collaborative thought and a distributed burden. Better decisions are made when the programmer isn't the only one thinking about architecture, just as game design is improved when there isn't only one person designing. Game design is a collaborative process; other disciplines ought to be as well.

Now, it is true that I might not have a leg to stand on because, being a programmer, it was very easy for me to understand the other perspective. However, how easy it was doesn't change the value of the lesson learned. I understand how intimidating it can be to program without any knowledge beforehand, especially when trying to make a game. I had to deal with the opposite--learning about the process of 2D and 3D art, when all I knew was programming. What's important is to learn how to think, in ways which your worflow does not involve.

So go forth and learn. Learn about what you don't know. You don't need to learn so much that you could get a job. Just learn enough to gain perspective, so you can be helpful even when you aren't the expert.

     In no particular order, the winners are:

1. Charles J. Geringer, winning The Game Jam Survival Guide
2. Jonathon Lewis, winning Game Data Analysis, Tools and Methods
3. Jenny Allan, winning Mobile Game Design Essentials

      The winners will receive and email from PacktPub when the book has been put in their PacktPub account (if you do not have an account, PacktPub will help take care of that for you).

     Thanks for entering the giveaway everyone, and congratulations to the winners!

     This is where I got the jMonkeyEngine 3.0 CookBook from. PacktPub has a huge game development library, so if there are any books you want to pickup, now is the time!

     PacktPub has also told me that they are willing to sponsor up to 3 free ebooks ! Therefore, I'll be holding a giveway for the ebooks (consider it a late Christmas gift from us)! Send us an email at indiebynight at elrel.com with

• subject: "Giveaway"
• body: your name (please don't be greedy and pull any silly tricks).

     I'll draw three names out of a hat (meaning a random draw, with no repeats) and announce the three lucky winners, as well as email them. The winners can then email me back telling me which book they want. I will then email them the free code to use on PacktPub to get the ebook. There has been a small change. I've been told I need to pick the three books to give out, so these are the books:

• Game Data Analysis, Tools and Methods
• Mobile Game Design Essentials
• The Game Jam Survival Guide

     These books aren't specific to any game development environment, so they should be of help to all who enter. I will announce the winners after the deadline passes, and the winners will receive an email with the new ebook in their accounts on PackPub soon after.

     Remember, the giveaway ends January 4th at 11:59 pm PST (2:59 am EST) ! The giveaway has ended.

     Hope you all had a Merry Christmas and the team here wishes everyone Happy New Year! I hope 2015 makes your indie dev dreams come true!

     Disclaimer: I have not finished reading the book yet, but as I dig deeper, I will update this post to fully reflect my impressions about the book.

First, the "at a glance", or tl;dr, version.

Pros:

• A ton of recipes.

• All the code for all the recipes to use in the jMonkeyEngine.

• Full application in real games, across a wide spectrum of games (RTS, RPG, FPS, platformer, etc).

Cons:

• Few pictures. Could use a few more to help explain concepts and ideas more concretely.

• Requires a solid grasp of several math-related concepts (trigonometry, vectors, etc.).

Now, in more depth.

The jMonkeyEngine 3.0 Cookbook is 298 pages, and is divided into nine chapters and two appendices. Chapters are focused on different aspects of game development, such as world generation, artificial intelligence, networking, and physics. I thought the list comprehensive, and couldn't think of anything that was missing. Some areas are in depth for a mid-level developer like me—I have yet to explore the specifics of sub-animations or procedural generation.

To be fair, the book is labeled “progressing” in Packt Publishing's scale for books, so it's more for the intermediate jMonkeyEngine audience. The jMonkeyEngine 3.0 Beginner's Guide is for the complete beginners, and should be looked at first to learn jMonkeyEngine before going forward. This book and jMonkeyEngine's own Math for Dummies Guide will mitigate some of the math related cons. I had a little difficulty following a few of the vector operations, even though I have done all the math courses for an engineering degree in the United States. This is also where diagrams and pictures might have helped. But as the author, Richard Eden, says in Chapter 2, “No matter which way you choose to do it though, practicing and thus getting a better understanding of these trigonometric problems is always a good idea”. That is a solid work ethic to apply to your code, especially for aspiring game developers.

Okay, no, the math isn't that hard. You aren't going into the imaginary plane anytime soon.

Despite the small bumps in the road with the math, I found the book very useful, practical, and instructive. So many recipes are at the reader's disposal, and they are specific and relevant. I was watching my friend play Legend of Zelda: Ocarina of Time, and I watched as he learned the new mechanic that allowed him to lean around corners to shoot while still covered. Guess what? That's specifically a recipe in this book, with angle of lean and the works! This example just goes to show how applicable almost every recipe is.

So if you are looking to improve your skills with jMonkeyEngine, buy this book. If you are looking to understand common techniques used in today's games, from FPS mechanics to RTS unit management to RPG open world design, buy this book. Simply put, buy this book!

Disclosure: I have no financial interest in this book, and no financial relationship with the author or the publisher.

P.S. If you are wondering about those other IndieCade "Games in Review" posts, they are in the works! You'll have to forgive my major for not being so forgiving to its students in terms of spare time.

The result is a game called "The Assimilator"; it is a puzzle game that deals with mixing colors. You can play it here: The Assimilator

For those readers who are colorblind, I understand that the game may not be very playable. I have a colorblind friend who I'll have playtest the game, and hopefully I have time to adjust the game to make it enjoyable by all.

That's about it. As you were! Or not, if you are playing my game :)