Saturday, June 16, 2012

7DFPS Postmortem


This week's blog post was delayed by a couple of days as I was participating in the 7 Day First Person Shooter challenge. The idea of the challenge was to create a FPS in a week. My entry was Coffee Quest FPS, which is kind of fun but was not as polished as I would like. I will be polishing the game up a bit more and releasing it on Blazing Games. This week I would like to do a mini postmortem. The game is roughly 2K lines of JavaScript (including comments, spacing, and data) with roughly 120 art assets spread across 8 sprite sheets.

What Went Wrong

The biggest issue for me was the time. This was made worse when most of my Sunday ended up shot and by the fact that I kept up my exercise regime. The problem with short deadlines is that they simply go by far quicker than you think they will. At the end of the challenge I had a finished game but not a polished game. My list of things I want to do for the Blazing Games release of the game is 0xF items long so at least a few more days would have been necessary to meet my minimum goals for the game. Notice that I said minimum goals? In fact the original idea I had in my head was a lot more than I knew that I could realistically implement so I focused on just having a single level competed by the deadline.

The second biggest issue, which may have largely caused the first issue, was developing the game and game engine at the same time. For me, the whole idea of developing a game in a week is the whole game. Just creating content for an existing engine makes the challenge more of a level design or modding challenge. The honest truth is that we have reached the point in game development where games are built on top of existing engines. This saves a lot of development time, at least half of the week in my case. If I ever do another challenge like this, I would write my own engine well before the challenge began and build the game with the existing engine. This would allow a vast amount more time to be put towards the actual game. Still, there is nothing like the feeling you get when you have created a fairly complex game from scratch in a week and if I had used an existing engine (mine or especially a third party engine) I simply would not have been as satisfied even if the resulting game was ten times better. In other words, I am glad I chose to write my own engine during the challenge but it was still the wrong decision.


What Went Right

While my new JavaScript ray casting engine has a ways to go before it is "finished", it is a very flexible engine. What I was able to implement is only a subset of what the engine is capable of. Earlier ray casters that I developed had fixed texture sizes. Part of this was designed to speed up the rendering and insure that integers were used for calculations. Now floating point is almost as fast as integer math and JavaScript uses floating point for its numbers anyway so allowing for variable texture sizes was easy. There was a bit more work getting the rendering to work, but I found myself using 256x256 textures for the walls but a variety of sprite sizes (64x64, 128x128 and 256x256 though power of 2 isn't even a requirement anymore). This actually made implementing the game easier. It will make future games that use enhanced versions of this engine easier to write.

The second thing that worked well was building on known IP. Using a known universe makes a lot of the design decisions very straight-forward. While there are often restrictions when using existing IP, in this case it is my own universe so I could do whatever I wanted with it. When your time is limited, working out background information and trying to figure out what works with the universe you are creating is a dangerous time sink. Granted, if I would have used an existing game engine instead of creating my own there would have been plenty of extra time to create a new universe. I suppose that is another reason why my decision to create my own engine during the challenge was a wrong decision. More to the point, at least in this case, it was a while since I played around in the Coffee Quest universe and really enjoyed myself.


The future

As I convert my older Java and Flash games to HTML5, this engine will be utilized in porting all the games that use their own ray casters or similar technology. What I am ultimately planning on doing with this engine is reworking it to use WebGL for the rendering, but falling back to ray casting for browsers that do not support WebGL. This way I will get great performance yet sill have my games work on the vast majority of browsers. Before I can do that, I have to actually learn WebGL so it might be a while. Coffee Quest FPS will have at least a couple of updates so eventually you will see what I originally was planning for this game.

No comments: