Thoughts on Coffee Quest 5/6

Working on Coffee Quest FPS has really got me thinking about giving my cursed Coffee Quest 5 project another go. I suppose cursed is really not quite the right word, but I have started on CQ5 a number of times in the past only to have the project go to the wayside as other things came along to eat my time. Needless to say, paying work always takes precedence over my game development hobby. As much as I would like to be able to turn my hobby into something that will pay the bills, I lack the proper marketing skills and tend to work on a large number of smaller projects instead of one really large project. I am trying to remedy the later problem but my twelve months of doomsday project just was something I had to do so my plans were derailed (and the games took a lot longer to code than I anticipated). Still, Coffee Quest 6 is a game that could work on something like the iPad and Nexus 7 and it is large enough of a game that I could justify charging money for.

For those who are unfamiliar with my Coffee Quest series, it started out as a Java game written for browsers. I drew up a roadmap of games that would lead to the ultimate role-playing game. This was broken into 9 games with the last 5 games being broken into a large number of episodes. The first game was simply getting a 3D maze working in Java (which at the time was a new language to me). Next came monsters, then multiple-levels and proper inventory. Coffee Quest 4 was the first true RPG featuring magic and more of a story.

Coffee Quest 5 was going to be a multi-part story that added NPCs and Stores to the game. Coffee Quest 6 was going to be a huge continent spanning epic with the player in control of a party of characters. CQ7 through 9 was more  of a 3 part story arch with no planned elements other than the vague idea of taking advantage of all the cool technologies that would appear when I finally got around to creating the game. Needless to say, the browser technology kind of stagnated until recently and Java has been replaced with JavaScript. This is something I could never have imagined happening.

I still have a few months of work to do before I can even consider taking another stab at a large-scale game. Coffee Quest is still in my heart so it is a project I would like to do but I suspect as soon as I get into the project something else will come along. Hopefully a high-paying project that will occupy far too much of my time. Still, it might be worth another shot and perhaps this time the games will see the light of day. As someone who isn't that big of a FPS fan, it would be rather surprising if a FPS is the catalyst that finally resulted in CQ6.

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.