Quick update

Yesterday was a lot of work.  I worked really hard to obtain a higher frame rate for the game, because I know that my postprocessing effects will be costly.  Sometime certain obvious things take a few days to sink in. It’s funny how I was looking everywhere to try to improve my fill-rate and bandwidth performance when I knew the problem was a polyon issue.  Drawing the entire scene twice (once for lightmap/shadow pass and again for actual rendering) was really stupid.  I was doing this because certain elements in the shadow maps such as the walking men were dynamic, thus the scene needed to be redrawn into the shadowmap every time.  However, the mass majority of the polygons in the scene where static.  The solution of this was to pre-render this static geometry into one shadow map, and render the dynamic geometry into a separate one, and then adapt all of my shaders to take an optional second shadow texture.  This wasn’t easy since much of my architecture wasn’t designed for multiple shadowmaps per light.  But I got it working.

The above boosted my framerates back into a very acceptable range so I’m happy.  It’s a little annoying, that for some reason on OSX Yosemite, I can no longer turn off Vsync in a windowed mode.  So I’ve been having to go fullscreen during debugging to see my max framerates which are hovering now well-over 100.

As far as swift goes, I’m now on the fully released Xcode 6.1 and I’m having far less problems with the source kit crashing which is great.  The IDE is generally still a lot slower than its predecessor which I hope improves with time. as I’m writing more and more code in Swift, certain features are starting to really prove useful to me as I get used to the language.  Among these are the tuples, willSet/didSet, and operator overloading.  On the ObjC side, I’ve had to rely on this bulky MathVector class to do my vector maths.  With swift I’ve been able to add all of the math operators I need directly to my low-level C structs via an extension.  This has already saved me alot of work and made the math code that I’ve written for the game alot cleaner.

Here’s an example of the vector math extension code in swift


Game Development in Swift

First Impressions

So let me start off by saying, Swift is FAR from finished.  I know Apple is calling it “released”, but that’s a load of garbage.  My two main annoyances with swift from the previous post reign true, alongside a new victor:  the infamous can-go-to-hell sourcekit crash.  This problem occurs so frequently on the latest Xcode to GM candidate, that I came very very near abandoning Swift as the language for this game entirely yesterday.  If it wasn’t for a post that I found on the Apple developer forums related to deleting the “ModuleCache” dir within XCode’s DerivedData, I would have probably had to abandon swift which is really sad considering how much effort apple has put into it already.  Let me just say that a craftsman is only as good as his tools, and when it comes to XCode 6 alongside Swift, at this point I’d be very very cautious using it for anything that you absolutely must count on to be finished in a reasonable timeline.  This goes without saying that apple seriously needs to re-evaluate what they consider to be a GM release.

Either way… Because my project is an experiment and has no real pressure of any release deadline (apart from the fictional one I’ve set for myself), I will continue using Swift as the language.  After using it to put together the stuff that I’m going to show today, I must say that I definitely like coding in Swift compared to Objective-C for class design.  It’s a much less uglier language for the most part.  Some things still tick me off such as continuos need for explicit casting.  But overall, I can see its appeal as a language choice over Objective-C.  I say over ObjC because if you are stuck using Objective-C, you’re already stuck with an OSX/iOS-only application.  So you might as well make things easier on yourself and use Swift instead where possible (once it matures).

Lastly, I’m not setting out to use every single feature swift has to offer.  I likely won’t touch a lot of them.  The whole point here is to get the game done and to use the language as exercise to see what it offers to me to put together A 3D game in the OOP-style that I’m used to using.  My background is in C++, so I’ll likely find certain features more useful such as nested type capabilities.

The Game Architecture

So writing about programming is always more complicated than writing about 3D modeling or artwork.  At the beginning of this project, I stated that I would care more about the game than the programming itself.  That has already proven difficult for me, since my years of experience programming always leads me to architect a good solution for the task at hand.  One of the things I can’t stand in a game (or program in general) is over-architecture.  So what I present below hopefully won’t change that much moving forward.  Which leads me to say that I really want to focus on the game now.  Now that I’m in the main stretch of developing this thing, I need to put all efforts on the game development itself.  This means I might be ramping down temporarily the number of posts on this blog until the game begins nearing completion.  I hope to be at that phase within the next two weeks.

Graphics Engine

As I’ve mentioned in the past, the game will take the form of a series of swift classes that are going to be built on top of my existing Objective-C codebase.  This is the same codebase that powers my Verto Studio 3D modeling tool that I’ve used to put assemble the 3D assets.  Because Swift is designed to interoperate with ObjC pretty easily, this shouldn’t be a problem.  A closely-related C++11 mirror of the lowest layer of this system is available open-sourced at https://github.com/mlfarrell/VGLPP.

I loosely refer to all of this code as a “graphics engine”.  It contains routines for working with OpenGL 3.2 to draw 3D graphics primitives (VGL layer), and load/render 3D scenes and models (VOM / Object-Model) layer.  In the Objective-C code, these layers blur a bit but you get the idea.  The important classes that I interact with in the game (in the swift code) are as follows.  Because this system is quite large, this list is not exhaustive.

Objective-C Classes (Graphics Engine)

VGL Layer

  • VertoGLUserShaderEffect (subclassable to provide shader effects)
  • VertoGLStateMachine (GL 1.1-like state and state delegation)
  • VertoGLSystem (delegation and control for the behavior of the entire VGL system)
  • VecTypes (C structs for low-level OpenGL-needed things like float3, float4, float16, etc).
  • MatTypes (C structs for low-level OpenGL-needed math things like mat3, mat4, etc).

VOM Layer

  • SceneManager (3D Scene)
  • Entity (3D Model type)
  • EntityMaterial (Material properties)
  • Texture2D (Texture map)
  • RenderPassManager (Multipass rendering manager)

The Game Classes

After one day, here’s the basic architecture I have for the game.  The idea here follows the same concept I’ve used for many years now:  a game loop class with three methods that manage input (processEvents), processing(processLogic/update) and output (rendering).  At any given time, the game loop will be in one of many game states.  These states dictate how the game loop behaves.  Currently the planned game states are Splash (loading up), Menu (the title menu), Driveby (the actual gameplay), and Game over.  The game states are managed and executed from the game loop using a new GameStateRunner protocol type.  The game state holds on to a single object conforming to the GameStateRunner protocol and forwards the processEvents, processLogic and render methods to it accordingly.  This allows me to nicely separate and organize my code into special GameStateRunner conforming classes.  The interesting thing here is that swift actually allows me to embed some logic into the game state enum itself which I’ve already found useful to allow it to load and construct the GameStateRunner objects for me.  Confused yet?  Awesome!

Objective-C Classes (Driveby Gangster Game)

  • GameLoop (base class that interacts with SDL C-API and sets up OpenGL, this stuff is just simpler to do in C (which Objective-C is fully backwards compatible with compared to swift)
  • SkeletalAnimationShaderEffect : VertoGLUserShaderEffect

Swift Classes (Driveby Gangster Game)

Subclassing or Protocol conformance denoted with colon notation

  • GangsterGameLoop : GameLoop 
  • DrivebyGameStateRunner : GameStateRunner
  • TitleMenuStateRunner : GameStateRunner
  • SplashStateRunner : GameStateRunner
  • GameOverStateRunner : GameStateRunner
  • GameObject (base class game object for all visual objects in the game)
  • GameObjectSkeletalAnimated : GameObject (any game object that has a skeletal animation)
  • GameObjectPlayer : GameObjectSkeletalAnimated (the game player / protagonist)
  • GameObjectEnemy : GameObjectSkeletalAnimated (enemies in the game)
  • GameObjectBystander : GameObjectSkeletalAnimated (bystanders in the game)
  • GangsterSceneManager : SceneManager (game-oriented scene manager subclass)

Now the good news is, above should be just about it.  All of the shadow stuff, shaders, texturing, rendering of the game scene is all saved in the Verto Studio file and should load and render just like I had it in the editor when I load it into the game via SceneManager’s load methods.  The skeletal animation support (apart from the special shader effect subclass) is also all entirely provided by my graphics engine so I shouldn’t have to tinker too much with that stuff besides optimization.

Now this post has already gotten crazy long and it would be too much to include the source code of all of the above classes in this post. So instead I’m going to provide snippets of some of the base classes so you can understand how the system will work.

The Game Loop subclass in Swift

Using the ability to embed a “load” method directly in the game state enum is probably the most “swift-esque” thing I’ve done sofar.  Moving onto the GameStateRunner protocol and sample implementation.


Lastly, a sample lineage of the early GameObject class implementation.



That was alot.  The end.

Why most indie games are 2D games.

Why Most Indie Games are 2D Games

Okay so do you want to know why most indie games are in 2D?  Read the posts from the last month or so in my blog.  In summary, you’ll notice that 90% of all that work was asset creation.  Keeping in mind, this is supposed to be a small-scale single-level 3D mini game.  Artwork, modeling, texturing, more artwork, more texturing, more modeling.. etc.  Simply stated, asset creation for 3D games is LONG, HARD work.. and in my case, I didn’t even do it all myself (I had a character modeler/animator help me with my single base character model, and I’ve relied quite a few times on turbosquid).  Even still, compared to 2D game development, this process can be extremely time consuming.  If this was a 2D platformer, most devs would have had at least basic assets for a “level 1″ finished probably in the first day, and would have been programming the actual game long before now.  I’ve always tried to ignore this fact but its true.  Look at the number of delays, setbacks, and ultimate release date shifts that have plagued Jonathan Blow’s “The Witness” project and you’ll see that rapid 3D game development is not an easy task even for seasoned developers.

Most independent game developers have certain skillsets that usually fall into the domains of programmer or artist.  Now I know there’s stortywriting, sound effects, music, etc.  But just about everything involved in a game’s development really splits into the two big umbrellas of either programming or creative (artwork, asset creation, etc).  The problem here is that as one advances in their particular domain, and starts to get really good at one aspect of the field, they often have to leave the other side of things to somewhat wither.  To become a really good programmer, I mean a really good programmer, you need to get obsessed with your craft.  That means even if you were a decent artist, you probably won’t keep up your artistry skillset as much.  The same goes for becoming a very good artist, and even a 3D artist.

As the industry has made the shift into large-scale theatric AAA games, more and more specialized craftsmen/craftswomen are needed to spend 8-hour days on something as simple as the texture of a claw of a single enemy in a single dungeon of a game.  The sheer manpower that AAA studios can throw at a game allows for the large attention to detail that 3D games require to feel right.  Even a “simple” game like mario 64 likely required dozens of artists to pan and pan over every keyframe of mario’s animations to make sure it was perfect.  Now don’t get me wrong, this was also true of the SNES/Genesis 2D era.  However, attention-to-detail, or lack thereof in these kind of games comes with less of a penalty, and certainly less of a time commitment.

It’s a hard pill to swallow since my dream of making games that started at a young age, has always predominantly been a dream of 3D game development.  But you know what?  I still love 3D game development.  It’s supposed to be hard.  The hard… is what makes it great.  Tom Hanks is right.  

So where does that leave the indie developer with respect to 3D game development?  Well when you have a team of only 2-3 people (or in my case, 1 people), you CAN succeed at independent 3D game development.  The absolutely crucial difference here is to understand and accept your limitations as an independent.  For starters, no matter who you are, limit your freaking scope.  Understand that you simply can’t make an AAA-length 3D game in any reasonable amount of time.  If you’re 1 person, and a hobbyist with almost zero budget (like me), set a goal for a game that requires at most 1-2 3D environments with very few (if any) unique character models.  If you are weak with art but you have the funds, consider using services like turbosquid to procure assets.  If you are weak with 3D programming, consider (after buying a few books) using a 3D engine such as unity or unreal instead of building your own.  

Above all, plan out the scope of your game to a t.  Then, give yourself a pre-determined amount of time to finish the game project… and..   quadruple it.

Driveby Gangster Update – a Dive Into Swift

Over one month in to my planned “2 week” 3D game project, 90% of my assets are done!  I still need a 3D tommy gun and an old-timey driveby gangster car.  But I’m going to start actually programming (imagine that) the very simple AI that will drive the walking of most of the bystanders in the game.  I’ve got my work cut out for me since most of the game logic code I’ve written to this point is all throwaway “get-it-to-work” POC code.  I now need to organize and get a basic heirarchical game-architecture together.  More fun, as I mentioned in my first post, I’ll be doing most of the game classes and logic in swift.  Swift, despite being officially released, still has its problems.  Namely for me, the speed of the IDE (for things like auto-completion) while typing in swift is the biggest gripe I have with the language so far.  That problem is followed by a close-second of annoying cryptic compiler errors that have nothing to do with the underlying problem of “I’m expecting an Int32, but you gave me an Int”.  Either way, I’m keeping my promise to write the game in swift as an experiment to see if the language is truly something I’ll want to leverage for game development in the future.


Despite the activity on this blog, I’ve actually been quite hard at work on this game.  The last few days have been filled with quite a bit of shadow mapping optimization which has proven to be much more complicated than I originally thought.  Shadows are probably a good chunk of the reason why most people go with pre-built game engines instead of developing their own, but I finally got shadows working reasonably well!

I’ve also spent quite a few days trying to get the frame rate up for the actual game by optimizing the rendering engine.  I’ve made some small strides here but honestly the main cost in terms of performance seems to be the grand total accumulation of just “alot of OpenGL api usage” to draw roughly 250 separate objects in the scene.  When I turn off the root call (entity render) for the entire scene, the framerate goes sky-high, but when I comment out smaller parts or optimize entire sections of code such as my prepare to draw methods (setting up uniform state), I get very small gains.  This leads me to throw up my hands and say “screw it” at least for awhile.  I get roughly 60 fps when close to buildings (thanks to occlusion queries) and about 30 when viewing the whole street on my Geforce 650 m card.  That’s going to have to be good enough for what should remain a small game project.  I really don’t want to get sucked into too much more low-level OpenGL optimization for this project.  Surprisingly, my older laptop from 2009 gets 20 fps (still pretty decent) and the iPad Air gets a very decent rendering performance too.  Perplexing… but I’m all-around  pleased so I’m moving on from performance optimization for now…

After all this craziness, my next step is to finally start texturing the character model and making sure he still animates properly when textured.  My character artist wasn’t able to texture the model so now this falls onto me.  This hopefully shouldn’t be too bad.  I’m planning on doing the UV texturing within verto to avoid more problems with 3D file format conversion.  It should work out fine, as long as I make sure I absolutely do not modify the vertices of the model when I do the texturing, as this will break the references inside of the animation skeleton structures.  Fun stuff.  More to come soon…

The ways of shadows

Ahh shadows.  I’ve been putting this off because lets face it, 3D shadow mapping is not frickin easy.  There are countless advanced algorithms for 3D shadow mapping to make shadows look as pretty as possible on our discrete-centric graphics hardware.  Some of them are crazy complicated and quite difficult to implement.  I’ve been messing around with 3D graphics programming for over 10 years now and let me say that shadows have always been just out of reach for me.  This week, I decided to put an end to that.

As a plan, I’ve decided to keep things as simple as possible.  I’m making a game here, not a game engine, so I wanted to get shadows working reasonably well, and get back to the game programming aspect of this project.

The basic outline of the simplest shadow mapping technique:

  • Render the scene from the perspective of the infinitely far direction light (shadow pass) into a shadow-depth texture.
  • Render the scene normally using the depth-information from the shadow-depth texture to determine whether or not a particular pixel is visible to the light or not (in shadow or not).

The Shadow Pass

Above, it sounds simple.  In practice, there are many caveats.  For starters, its absolutely critical to get the most of out of the “shadow-depth” texture in terms of resolution as possible.  Thus, when rendering the shadow pass, we want to contain the entire scene into the light’s view with the constraint that we show as much (are as zoomed in) as possible.  If we zoom in too little, we hurt the resolution of the shadow map.  If we zoom too much, we risk clipping the scene resulting in some shadows being lost.  Furthermore, we want to render this step with as simple of a shader as possible, to avoid unnecessary wasted computation on the GPU.

Going back to the optimal viewport containment (zooming) issue, this boils down to computing the optimal Ortho-box that the scene will be contained in.  We’ll use this box as the parameters to the ortho projection matrix given during the light/shadow rendering pass.  Optimally bounding the scene with this box presents a problem due to the fact that the box is in light-view-space coordinates, and all of our scene bounding boxes are in world-space.  Trying to work through this last night, I resorted to pencil and paper.

The algorithm essentially involves grabbing the light’s “viewing” transformation which consists of a simple lookAt transform and applying it to the 8 corner vertices of the world-space bounding box of the entire scene.  Once I have these coordinates in light-view-space, hopefully a computation of a new axis-aligned bounding box of these 8 points will be the ortho-box I’m looking for.  It turns out, that this worked quite well.

The actual code of this algorithm ended up looking more like this..


Below is a sample result of a shadow pass done using my cheap and simple bounding algorithm ran on our street scene (vantage of the light).  Note that this is stored into a depth-component texture attached to the depth-attachment of an offscreen FBO.


The Shadow-Application (main) Pass

During the main rendering pass, I needed to modify my shaders to include the application of the shadows from the light-map.  Alongside the light-map texture, I needed the a variant of the same “MVP” model-view-projection used to transform a world-space position into projected light-view-space coordinates.  This matrix is commonly referred to as a “bias shadow matrix” because its optimized to express the result in a normalized texture-coordinate form that GLSL texture routines are expecting.  In short, it simply applies the lighting-transform, divides the coordinates by 2 and then shifts them by 0.5.

Armed with the shadow matrix and the shadow map texture, I generate the needed shadow coordinate information in vertex shader.  I also compute a shadow bias to combat a well-known phenomenon known as “shadow acne” essentially caused by z-fighting from the shadowmap texture.   

Lastly, in the fragment shader, I sample the shadow texture to determine whether or not the shadow coordinate of the given fragment is visible or not to the light.  I can vary the visibility factor to be as dark or light as I want to achieve the desired effect.  Note that I’m using a shadow sampler here.  This special hardware sampler takes multiple samples of the shadow map for me and interpolates the results automatically to produce a smoother shadow edge.

The results of all of this craziness is something quite nice.  Shadows casted in my scene that can lie across curved surfaces.  This was quite a bit of work but I think it’ll be quite worth it since now my graphics engine is shadow-capable.  Down the road I’d like to add point-light shadow capability via rendering into shadow cubemaps and general shadow capability for Verto Studio, but for now, directional light shadows satisfies the needs of my game project.

Scene texturing 99% done!

I got the street scene mostly done!  I actually had gotten this far on monday but I’ve had to spend alot of time getting Verto Studio for iOS back up to speed and polishing the new features that I’ve recently added.

I’ve started to worry a little bit that this game will quickly become too boring for only having one scene but I’ve promised myself that this will be a SMALL scope game (which has already ran quite longer than I thought it would).  I’m hoping my idea of slowly transitioning the graphics from “realism” to “black&white noire comic-bookism” as the player loses touch with reality will help keep things interesting.

Yarr.  Screenshots be below.

My cubemap renderer feature came real handy for the light-bulb reflection effect.

More of texturing day

Yesterday I worked quite a bit with my character animator Tyler Hurdle to get the animations properly exported from his modeling software into my graphics engine.  After much wrestling, I got the simple walk cycle loaded in and it looks awesome.  

Things happened today.  Those things included me finishing up the texturing for the Hotel.  I must say, it’s really starting to look good. I can’t imagine how it’s going to look once I add in the final shadowing and post-processing effects.  I didn’t take as many intermediate screenshots as I should have this time. So I only really have the final results of where I am at the end of today.  Nothing too-far out of the ordinary happened during the last steps of the texturing of the hotel besides me modifying the basic window shader effects to include partial transparency. I did this so that I could “cheat” with the interior shops of the hotel, modeling the interior as a simple gaussian-blurred backdrop which is partially of obscured by the semitransparent window.

I also decided to get rid of the ugly default “sand” texture that I’ve been using for my background terrain.  I spiffied this up a bit with multitexturing effects using a detail texture which came out pretty awesome.

After all this, the frame rate performance within the editor and the game started to both get really bad.  So I had to stop modeling and dive into some optimization once again.  Using instruments within xcode, I uncovered some horrors related to the terrible performance of objective-c’s NSString methods (namely stringWithFormat) which forced me to eliminate their usage and some of the more critical sections of the rendering engine’s code.  That alone, gained me another ten frames per second back and started getting me to question the viability of Objective-C for hardcore game engine development.  I sure hope Swift’s string methods are faster than Objective-C’s.

Continuing with optimization, I put off the long-needed step of sorting scene entities first by transparency, and then by material.  This helped me avoid unnecessary state changes which propagate to the shader and harm performance.  I also hard-coded a backface culling test which showed that I really need a per-model “cull backfaces” option within the editor.  All of this optimization added up quite a bit to bring my performance back up to a reasonable level.

All of this work today uncovered quite a few new bugs in the editor itself, so tomorrow will likely be spent fixing those…