Bit Battles Development

Ride's Over, Kids

2009-02-27T03:56:00.003-05:00

It's been a while since my last post and a wild ride in general over the past few months. I thought I'd offer some final thoughts and tie some loose ends before moving on to greener pastures. As fair warning, there's a lot to read and most of the following is a mix of my opinions and rants about the past year in game development land so if you're not interested in that kind of thing (all two of you that might happen to read this) then move along.

MyDreamGames 'Game in a Year' Contest
Where to begin? Perhaps a bit of backstory.

The 'Game in a Year' contest was the catalyst that got me moving forward with the development of Bit Battles. The allure of a $10,000 grand prize was too great of an opportunity to pass up and my game idea seemed solid enough, perhaps even a winner. The prize money would've more than payed for development of Bit Battles and possibly whatever project I wanted to start next. It all sounded like a really fun experience and a great way to get a foothold into the more serious side of indie game development. This was the contest that was supposed to pave the way for the future of Fanatical Games.

What actually happened is the entire contest became a debacle; a reminder of what can go wrong when a small company bites off more than it can chew and then involves an entire community in their shenanigans.

Bottom line, the thing was a mismanaged nightmare almost from the start. The Dream Games crew made promises it couldn't keep (like offering to support the teams behind the games with marketing, asset creation, etc.), failed several times throughout the year at administering the competition (various rule changes/clarifications, not releasing/creating point tallies for the final two quarters, etc.) and then bungled the actual process of selecting a winner (which seems like a pretty vital part of any contest to me!) by dragging out the judging process for nearly five months PAST the 'dead line', putting every team in limbo for nearly half a year.

I don't have any special insight into exactly why things went so wrong. I think people had the best of intentions (I know I did) and, for a while, the competition was actually fun. I suspect the contest was really a ploy to market Dream Games' products and I suppose it worked. Many of the contestants discovered DG via the contest and actually purchased and used their tech, buggy as it was.

In the end Bit Battles didn't win, the grand goal of gaining a financial foothold in the game development realm never happened. However, after recently chatting with the winner it seems the 'grand prize' wasn't quite so grand after all (surprise, surprise). Apparently losing is just as good as winning according to Dream Games.

InstantAction Contest
This was another contest I entered early last year. The prize this time was a chance to have the game published on GarageGames' new InstantAction platform. It was an opportunity to work with the 'big boys' of indie game development and would've really put Bit Battles out there and on the forefront of some really interesting tech. Bit Battles didn't win or even place in the top 3.

The games that did win were either: 1). games that had been completed before the contest had started (in some cases, years before the contest had started) and had gained a respectable following of players or 2). prototypes of concepts that have still not gotten off the ground (nearly a year later) and are not, and may never be, on IA.

More importantly, and this really gets to the heart of my problem with the contest and InstantAction in general, is the games that did win (or even place as a finalist) all had teams of people behind them. The one-man studios, the true 'indies', never really stood a chance because their entrees were up against games made by full-fledged companies who call themselves 'indie game developers' when in reality, they're more like professional studios who lack a dedicated publisher.

Developers like Introversion (makers of Darwinia, etc.) have more in common, in my opinion, with the 'pros' than with the bedroom coders slaving away on some personal project and yet, somehow, they're still considered just as 'indie.'

And that's my petpeeve about InstantAction. It's really just a showcase for the small studios who are no less professional than, say, Bungie or Blizzard but who lack the sheer numbers to be considered outright 'professional game developers.' While I don't have an issue with the smaller studios having an outlet for their games, it seems odd to me that GarageGames, a company founded on empowering independent developers, would spawn something that isn't accessible to actual independent developers.

Perhaps this is just another way of asking, "Where is the line between indie and professional?" Is there a certain number of employees a company has to hire, a certain number of games they have to release? What's the criteria that governs whether someone is independent or not?

And another little nitpick about the IA contest: There was absolutely no follow-up with any of the contestants. None. The GarageGames employee responsible for managing the contest promised to give some type of feedback about all of the entrees, even do some writeups about the games but that never materialized. The employee in question also apparently went MIA afterwards as there's been no further posts/blogs made by him.

Oh, and the game that won and received the publishing contract? Yeah, still not on the InstantAction website.

Indie Development Scene
Not really sure what to say about the state of the indie development scene. With GarageGames under new management it almost feels like the passing of an era. The founders are gone, many of the old employees have moved on and there's a definite sense that GG is becoming more about empowering studios rather than developers.

I'm interested in seeing things take their course but I'm not overly optimistic about the future. To me the entire indie development scene feels like a grand experiment that harkens back to some golden age of gaming where anybody with a computer and enough time could write a game, toss it onto a floppy disk and do something with it. Unfortunately it wasn't sustainable (in the financial sense) then and I don't believe it's sustainable now.

Bit Battles
What can I say about my game? It was a fun project, probably the culmination of a lot of my favorite things about various games all rolled into one. I think it's fun to play and apparently so do others who've played it. There's things I would've designed differently, features I wanted to implement, additions I wanted to make but overall I'm happy with how it turned out. I think.

With all of that said, if given the chance to do it again, would I? Yes, provided I knew it was destined to be freeware. I wouldn't have spent quite so much time or effort (or money!) on it and probably would've left it half-finished and closer to the original concept. I would've had fun working on it from start to finish or simply not worked on it at all.

So, that's the end. Fanatical Games will be closing up shop soon-ish. In the meantime, Bit Battles will be available for a couple of months in it's open beta form before it dies a digital death and becomes another page in the annals of Internet history. Get it while you can, I guess.

April 30 (The End?)

2008-05-01T03:04:00.003-04:00

The end is nigh! Who knew the final week, then final day, then final hours would be here so soon? With barely an hour to spare, I managed to get latest version of Bit Battles out the door to both the MyDreamRPG contest judges and the general public! That's right, Bit Battles has hit open beta.

First, the important stuff. If you want to take part in open beta, maybe help me squash a few bugs or just check out the latest TRON-inspired indie game, then download Bit Battles by clicking: here. Be warned, this is still very much a beta. You most likely will run into unexpected problems. Report them to me either via email: feedback [at] fanaticalgames.com or the proper way: joining the Fanatical Games forums and making a thread in the Bit Battles area.

Getting from where I was last week to the finish line was supposed to be an easy task. I mean, hey, the game itself has been pretty much ready for public testing since March. Or so I thought. With three or four hours to go I was working on setting up a proper installer (that's right, no simple .zip file here) when I noticed a few small bugs with the game. Minor things like certain text fields not updating on map change. Simple problems with easy fixes. But fixing them required essentially recompiling the entire installation package followed by lots of testing to make sure everything still worked correctly. Each time I thought I had a good release candidate, I'd find another little bug or quirk that I just had to fix. And so on and so forth until I realized I had about 30 minutes to get the thing out to the judges. Sigh.

Anyway, the game is out there now. It's available for play, for judging and for criticism. So, where do I go from here? Only time will tell. Based on the feedback I get (assuming I get feedback, which if the closed beta was any indication, I won't) I'll probably be working for another month or so on bug fixes. After that, testing, marketing and shopping the game around to various publishers. It sounds good in theory but will it work out like that? If the past year has taught me anything it's not to plan too far ahead because things have a way of working out... just in a completely different way than you expected.

Progress Backlog - April 26 (Balancing Act)

2008-05-01T02:55:00.004-04:00

[The following post is a backlog of progress which occurred from April 20 through April 26.]

Another week gone. I managed to wrangle the game manual into submission; one less task on the todo list. After taking care of that I turned my attention to the Bit Battles website. It's been an ongoing project for a while now and after half a dozen attempts I'm starting to make some good headway.

One of the problems thus far has been figuring out exactly what I want the website to be and do. Should it be a hub for all thing Bit Battles (similar to the old TribesPlayers site for the old school T1 players out there) or something much simpler (maybe a page with some screenshots, a big "BUY ME NOW!" button and a link back to Fanatical Games)? That's a question I still haven't fully answered. I'd certainly like to have a be-all, end-all website for Bit Battles complete with a nifty ladder or tournament system, place to host user-created maps, etc. but that seems a bit presumptuous. If the game sales poorly then it's all wasted effort and time, time which could've been spent making the game itself better.

Perhaps the best choice is something in between those two extremes. Finding the right balance, though, is easier said than done.

Progress Backlog - April 19 (TBD)

2008-05-01T02:40:00.002-04:00

[The following post is a backlog of progress which occurred from April 13 through April 19.]

My focus this week is getting the documentation for Bit Battles updated. The MyDreamRPG contest awards points for proper game documentation (although the lack thereof isn't an automatic disqualification).

What can I say? It's fairly boring stuff. Hours of writing, formatting and revising all aimed at teaching players how to quickly jump in and get playing. The game manual (and I use that term loosely as it's more like a quick help guide than a full-blown, "every option under the sun is explained" manual) is essentially an HTML doc. I explained a while back why I decided to go with a simple HTML page instead of a .doc or even one of those fancy-schmancy .hlp files (compatibility, ease of use and ease of creation, in case you're wondering).

My goal is to keep the documentation simple and to the point by covering only what the player MUST know to actually play. After reading the help file a player should be able to join a game and at least be competent enough to know what the objective of each map is, what powerups are and how to collect/use them and how to mix it up with an enemy without getting insta-gibbed. Anything beyond that is considered outside of the scope of the document. In my opinion, no help file is a better teacher than good ole' experience.

For next week, I'm aiming to finish off the manual and perhaps put in some more time on the Bit Battles website.

April 12 (Dead Tired... Does That Make Me a Zombie?)

2008-04-12T18:58:00.003-04:00

Another slow week down the tubes. Things are definitely winding down. The game is ready for open beta, the website is getting there and I'm ready to see it all come together and finally be finished.

The deadline for the MyDreamRPG contest is just two weeks away. I wish I could say I'm feeling particularly confident but I can't. With a lackluster response to the closed beta I'm hoping the game is ready for the masses (and I'm also hoping there will actually be "masses") but I really can't say for sure. Testing a multiplayer game requires, well, people other than ones self which I've only rarely had the privilege of having. Nevertheless, I'm pushing on with an aim to hit the finish line, good, bad or ugly.

Should Bit Battles win the competition, it'll go a long way toward financing the next game. If for some unfortunate reason it doesn't, I plan on getting the game out there and letting it be. If it sales, great. If not, I'll take my proverbial ball and go home. I wish I had the motivation and budget to really market Bit Battles but I just don't. And truthfully, at the moment I'm liking being strictly a gamer rather than a game developer.

Anyway, enough with the gloom and doom. Here's the plan for next week:

Continue website development; still need to tweak a few things for certain browsers and finish the screenshots section
Tie-up any loose ends with the contest (like getting the last revision of the design doc out to Dave!)
Bug fixes?

Until next time, folks!

Progress Backlog - March 31 (Still Truckin')

2008-04-02T14:28:00.002-04:00

[The following post is a backlog of progress which occurred from March 26 through March 31.]

Not much to report on this week. With the exception of a few bug fixes and tweaks, Bit Battles is all but done. I'm currently focusing on all of the other things (website, manual, etc. etc.) that need to be completed before the game is released.

I'm also still dealing with the issue of all of my beta testers mysteriously disappearing. It's really a troubling situation, especially so close to the contest deadline. What's worse, not many even offered feedback on the game before going MIA. Why take the time to sign up to test a game if you're not, you know, actually going to test it? Ultimately I believe I'll be wiping the slate clean and getting a whole new round of testers. Disappointed? Absolutely but I can't afford to wait for the current batch of folks to get it together.

Looking ahead, I need to step up the advertising effort again and soon. This month was by far the best for the Fanatical Games website with more unique hits than any previous month. It's a good sign, I suppose, and couldn't come at a better time but more exposure is needed. I have some ideas in mind but for now my focus has to remain on finishing the MyDreamRPG contest first.

March 25 (Motivation)

2008-03-25T13:11:00.002-04:00

Another week down. Here's what's been happening over at Fanatical Games.

I setup the first "official" multiplayer test of the game this weekend and got exactly 0 folks to participate. Disappointing. Keeping the testers motivated is really becoming a problem. Some have signed up to test, got accepted and I've never heard from them again. Others signed up, offered some preliminary feedback and then dropped of the radar.

The lack of participation is really hindering the game in more ways than one. For starters, winning the MyDreamRPG contest depends on community response to the game (including feedback from testers). Not having much of a response other than a few signups is a problem. Secondly, the game just isn't being sufficiently tested and I can't (and won't) start the push to final release until I feel confident Bit Battles is bug-free. And perhaps most importantly, seeing the testers go MIA really makes it hard to keep myself motivated now that the "fun" part of development is over.

At the moment I don't have any ideas on how to address this problem. Jay Barnson of Rampant Games is using a staggered testing approach where small groups of testers are given access to the alpha at certain intervals. Rotating different groups of testers in is advantageous because it means you get fresh feedback about the game and it keeps everyone excited as they wait for their next turn to play. It works well when you have enough people to fill multiple testing groups but unfortunately for me, I just don't.

If you have any ideas, feel free to comment.

March 17 (Testing Continues)

2008-03-17T02:26:00.002-04:00

Another week down, another week closer to getting this game out. The beta is still in full swing and I've gotten some great feedback from most of the testers. I've implemented a majority of their suggestions already and I'm happy to report Bit Battles is a better game as a result.

The major hiccup this week was one of the testers found a serious issue with the collision system which allowed players to "warp" through walls. Although only the training levels seemed to suffer from the bug, the possibility existed of it affecting the multiplayer portion as well so fixing it became my top priority. The vehicle collision system in TGE has long been one of it's weak spots and it's been something I've tweaked, hacked and silently cursed over the course of development. While the idea behind it is nice (hey, a nifty data-drive rigid body simulation seems like a great idea!) the concepts that power it have some tricky gotchas that don't mesh with a fast-pace game like Bit Battles. With that said, I felt like I had solved or at least dealt with the typical failings of the vehicle collision system (i.e. the vehicles often "sticking" to geometry, falling through terrain or causing the application to hang in an endless loop) but being able to "warp" through geometry was just weird!

After some late nights I discovered the problem: the hovertank collision hull was just too simple. Because the vehicle collision system relies on discrete physics "steps", it's possible for it to not only fail to register a collision but also to register a collision late. While there's some safeguards to prevent both from happening, I was lucky enough have a test case that still broke things. Except the test case was actually a game in the midst of beta testing with a deadline looming just around the bend! Thankfully, I managed to wrangle things into working. I beefed up the collision hull, tweaked a few datablock properties and we're back in business.

In other news, with the MyDreamRPG contest deadline quickly approaching, I'm pulling overtime trying to get everything ready to go. That means continuing the beta, responding to feedback, building a proper website for Bit Battles (or, actually finishing it) as well as all the last minute stuff involved in getting a build ready for public release.

I think I can, I think I can...

March 8 (Testing 1... 2... 3)

2008-03-08T12:13:00.002-05:00

With a modest group of testers signed up, beta testing began in earnest last week. Having some outside help is paying off as the testers have already found enough bugs to keep me busy through the weekend. I've had the pleasure of pushing out a second build of the game which speaks volumes about how thorough the folks playing the game are. Much appreciated!

The beta test will last throughout the month and I've divided into four phases, lasting roughly a week each. Each phase is designed to focus the testers attention on a specific part of the game I'd like to get feedback about. Here's the breakdown as of right now:

Week One: Phase 1:

Offline/singleplayer training campaign testing (bot intelligence, overall 'fun' factor, effectiveness at teaching how to play, etc.)
Control scheme feedback (turning rate of hovertank too slow, too fast?)

Week Two: Phase 2:

Testing Capture & Hold gametype and each of the five C&H maps (looking for feedback on map balance, powerup placement, etc.)

Week Three: Phase 3:

Testing Find & Retrieve gametype and each of the five F&R maps (looking for much of the same feedback from week two)

Week Four: Phase 4:

Miscellaneous feedback on GUI, HUD, etc. Anything is fair game here. Some of the feedback from previous phases may spill over here.

At the end of each phase I plan on asking the testers to wrap up the week with a summary of their thoughts on the game. Their reviews will be submitted via the MyDreamRPG feedback link for the purposes of the contest and, of course, I'll look over each one and hopefully get some useful feedback as a result.

Back to bug fixing I go. Until next time!

February 29 (Sign up!)

2008-02-29T13:05:00.002-05:00

Development on the game has all but stopped, giving me a chance to get around to doing all those other things I need to do to actually get this game out (like working on a dedicated Bit Battles website, writing a manual, oh and actually conducting a full-blown, semi-public beta). Speaking of which, it's still possible to sign up for beta. Just show your interest by posting here.

Since there's now ultra-exciting development news, here's a summary of everything else I've been doing:

Bit Battles website is coming along well. Nothing too fancy, I just want it to be fast and functional. W3C compliant all the way!
Still dealing with some last minute contest cleanups (getting the last design doc revision ready, integrating the tester feedback form, etc.).
Working on some advertising stuff to bring in more players (to both test and hopefully buy the game!).
Taking a much needed breather to play some WoW. A lot of WoW, actually. Too much. What time is it!?

As I mentioned in the last post, I wanted to offer my thoughts and insight into the recent IA contest as one of those unlucky few that didn't make it to the final five. I'm going to hold off on that a bit longer as the winners haven't been announced yet and I'd like to see the contest completely finished first. Maybe next week.

Anyway, sign up for the beta and help support Bit Battles. Until next time!

Some important links:

February 24 (Beta)

2008-02-24T01:30:00.002-05:00

We're here. Beta has started or, rather, will be starting very soon. To take part in the closed beta, sign up here. Signing up means gaining access to the beta forum where bugs can be posted (oh no!), balance issues can be discussed, questions asked and answered and testing times will be scheduled.

The closed beta will take place throughout the month of March. It'll be a mix of random, impromptu testing sessions held by players and "official" scheduled testing sessions which will be posted in the beta forums. The scheduled tests will be times where I'll be on hand personally (on the Fanatical Games server) to answer questions, fix bugs and generally have fun playing the game with other players.

As for the InstantAction contest, Bit Battles isn't a finalist. Obviously a disappointing turn of events but hey, you win some and you lose some. The game is better for being entered so that's the silver lining I suppose. Not quite ready to discuss my feelings on the contest itself as the details are still hazy (as are the GG guys apparently; GDC seems to have gotten the better of them) and I'm still waiting to hear what the IA guys thought of Bit Battles. I'll probably offer some personal insight next week when I sum up the month of February in my monthly GG .plan.

Anyway, sign up for the beta and have some fun testing an indie game!

February 17 (Prep Work)

2008-02-17T00:53:00.002-05:00

As of about an hour ago we're now T minus 1 day and counting until the InstantAction Developer's Contest deadline is here. I've spent the last week really buckling down and getting things ready to go. As a result, there's been quite a few important developments over the last few days. Here's the rundown of what's been happening:

With the IA deadline looming just around the corner, I realized I still had a ton of work to do to actually get a release build ready. Sure, the game works on my system but actually packaging things into a nice, lean-and-clean release entails a bit more than simply zipping and uploading. It's a bit of an interesting situation because essentially I'm taking a game that's very much in development and packaging it as if it were finished. On the plus side, it's a good way of doing trial runs so I have a better idea of what it takes to get a public beta ready to download.

First on the agenda: writing a quick help/manual for the game with an emphasis on "quick." Ideally, the manual had to cover movement, combat, powerups and objectives in about a page (images included). No simple task. A couple of issues cropped up right at the start like what format to chose? A simple .txt or .doc file is certainly the most compatible but not necessarily the most interesting and PDF is nice but requires a downloadable reader. In the end, I chose to do a simple (W3C valid!) HTML help page. It's compatible, allows for some rich formatting, doesn't require another download and it gave me an opportunity to brush up on my HTML and CSS which should prove useful for the upcoming Bit Battles website. I'm not sure if I'll end up packaging it with the final release build but it's a nice starting point for a proper manual.

With the quick help done, it was time to do some housekeeping. I finally got around to cleaning up the data directory and got rid of a few megs worth of obsolete textures, interiors, shapes, script and GUI files. It's amazing how much "stuff" had accumulated in a year. My head on desk moment of the day: finding a subdirectory that contained all of the old hazard zone data (about two megs worth) which had been obsolete for months. D'oh!

Afterwards, it was on to usability issues and bug fixes. First up, dedicated servers. I'm not sure how much use it will be getting this release. Nevertheless, getting a dedicated version of the Bit Battles server up and running took all of five minutes. I wrote a quick batch script to spawn a dedicated server and respawn it should they crash although here's hoping there's no need to make use of that feature! As for bugs, I'm still in the process of testing but so far so good. What I've found thus far has been minor clientside issues (GUIs not saving preferences, etc.).

Thanks to the frantic scramble to get Bit Battles contest-ready, I've had to come to grips with the fact that time is really running out. The MyDreamRPG contest ends in April but because player feedback plays such an important role in the judging, March is really "go time." The goal right now is to have a public beta out by March 1 because I need an entire month to conduct open testing, receive player feedback and implement suggestions. What this all boils down to is there's no more time for new content; what's done still needs to be polished and the rest of the time will be spent advertising and handling all of the little things that go into getting a public beta going.

With this in mind, I've decided to cut Access Denied. With the map still very much in the planning stage and me still stuck in a mapping rut, there was never any hope for it. The downside is only having five maps (well, ten if you count having two versions of the same map for each gametype) for release. On the plus side, Access Denied was probably the single most time consuming task left on my todo list. With it gone, that's more time to test, polish and advertise. It's a good trade-off.

In other news, the marketing campaign is underway. The Fanatical Games website got a nice update (all new screenshots of Bit Battles), there's now a GGE page devoted to the game and Phil Jones of Tank Universal fame (great indie game, go buy it!) was kind of enough to link the game from his front page (and I've linked his website, see the Fanatical Games "Links" section). There's more in the works and even more that needs to be done but it's a nice start.

Well, that's all for me. By the next update the IA contest will be over and it'll be time for beta signups! Scaaaarrry.

February 8 (All in the Timing)

2008-02-08T12:23:00.001-05:00

The InstantAction contest deadline has been pushed back to February 18 which means another couple weeks to work on things. It could mean Access Denied will be included after all, provided I get back into the mapping mood. Regardless, the extra time is a welcome relief as it'll mean a much stabler build of the game to showoff while also giving me some time to work on release materials (i.e. a proper manual, website updates, etc.).

With that said, the past week has been a productive one. In my last update I mentioned wanting to work on some special effects, namely: motion trails for the hovertanks and a fixed function fullscreen glow effect. This is still a work-in-progress but the motion trails are in. Getting them working was a bit of a crash course in OpenGL but I think it was worth it. Originally my intent was to replace the particle contrail emitters with the motion trails but I opted to go for a combination of both. The particle emitters have been tweaked so they die off fairly quickly which makes them look like engine glow. Nifty effect that's difficult to catch in screenshots but here's my best effort:

The fullscreen glow effect is proving to be less than cooperative. The idea behind it is simple: render the screen to a small texture, set the appropriate blending mode, then draw that texture (stretched) over the screen. The upscaling results in a blur effect that makes everything look as if it's glowing. Unfortunately, my OpenGL knowledge is somewhere between nonexistent and mediocre which makes actually implementing it troublesome. But, as they say, third time's a charm so I'll be giving it another try later on this week.

Despite my OpenGL woes, I'm happy to report that the shockwave effect issue that's been plaguing me for the past few weeks has been resolved. I ended up creating a custom Shockwave class that was heavily based off of the Splash class. The main difference between the two is that, unlike Splash, my Shockwave class is fully networked so it can instantiated on the server and then propogated to all clients within scope. The animation for the shockwave is only updated clientside so only the bare minimum amount of data is sent across the network.

With all of the coding fun going on, I managed to find some time to tweak a few GUI graphics. The maps now have an appropriate preview pic that's shown in the Select Map dialog, the StratChat HUD was updated to better support multiple resolutions and the powerup icon was reworked (again...). Speaking of which, the powerup icon is now on it's third revision and I'm sill not happy with it. 2D icons are just not my thing, apparently.

In other news, the website update is coming, as is the GGE page and a slew of other things that'll hopefully get the marketing effort rolling. Watch out for those!

January 31 (Deadlines. Deadlines? Deadlines!)

2008-01-31T12:43:00.000-05:00

With January gone and two contest deadlines looming just around the corner (the InstantAction deadline is a mere week away and the MyDreamRPG contest ends in approximately two months), time is rapidly running out in spite of the fact that my todo list continues growing. With that said, here's what's been happening at Fanatical Games.

First up, I've decided to put the Access Denied map on the backburner for now. The goal was to have it ready for the InstantAction contest but that would mean releasing a playable-but-not-really-finished map and I refuse to do that. SegFault may be pulled as well depending on how comfortable I am with it but that'll be a last minute decision. Despite all of this, the plan is still to have Access Denied ready to go for the MyDreamRPG contest in April. Hopefully I'll be out of my mapping rut before then and can finish it off properly.

The benefit of holding off on the Access Denied map is that it's freed some time up to work on prettifying the game. I've wanted to work on some special effects for a while now but haven't really had the time. Ideally I'd like to get some type of fixed function fullscreen "glow" effect up and running as well as replace the hovertank exhaust particles with motion trails (similar to Homeworld, Tribes: Vengeance, etc. etc.). All of this is in the early implementation phase so calling it quits if things prove to be too much of a hassle shouldn't cause any problems.

Of course, these special effects have to take a backseat to bugfixing. Speaking of which, the Shockwave powerup effect bug I mentioned in my last update is still causing issues. I tried hacking away at the Splash class to make it behave properly across the network but that was a no-go. I'm planning on biting the bullet and just creating a custom Shockwave class from the ground up. I should be able to save some time by leveraging all of the rendering code from the Splash class which means the only real work involved is in the setup. Saving time is great because this has to be implemented before the upcoming weekend test. D'oh!

Outside of the development side of things, I'm starting to look at ways of getting Bit Battles "out there." Advertising/marketing the game will become increasingly important the closer I get to March as so much of the MyDreamRPG contest (and even the financial success of the game itself) depends on building a community, getting players playing and offering feedback. Up to this point I've done no advertising at all but I plan on changing that in the coming months.

Coinciding with the increased marketing effort, the Games page at FanaticalGames.com will eventually become more of a 'hub' containing links to the game websites rather than a preview page. Read as: Bit Battles will soon be getting it's own website. In addition, I'll be updating all of the Bit Battles screenshots soon (this week most likely). Tack another couple things on the ole' todo list.

See you in February!

January 23 (Tick, Tock)

2008-01-23T16:59:00.000-05:00

Here's what's been happening since the last update:

worked on Access Denied map
ran into some issues with the effects with the Shockwave powerup (fix still pending)
started work on getting everything ready for the upcoming internal test

Access Denied is really up in the air right now. My first attempt at it ended with a really bland level that also resembled Fragmentation. For my next try, I thought I'd go for a digital cityscape look, complete with massive skyscraper, towers, etc. and a network of digital roads. What I ended up with was a flat terrain with some really tall boxes on top of it. While I like the idea of this sprawling stylized city, I'm starting to doubt I have the time or resources to complete it. I plan on giving things another go this week but as of now it looks like Access Denied won't be included in the internal test.

While testing the powerups, I ran into an issue with the effects for the Shockwave powerup. When the player uses the Shockwave powerup, a blastwave is supposed to emit from their hovertank and forcefully push enemies away. This all worked great in offline/localhost testing but broke spectacularly when connecting to dedicated servers. The blastwave effect is really just a modified splash effect that comes stock with TGE. Unfortunately, splashes (like explosions, decals, particles, etc.) are clientside effects and trying to instantiate a clientside effect on the server is a big no-no. Right now I'm mulling over a variety of solutions to determine which would be the easiest/fastest to implement. Whatever the solution, this problem has to be fixed before Friday.

The larger issue here is that bugs like these are a real problem. They don't appear in my tests because I'm simultaneously hosting the server and connecting as a client. The only way to find them is to have other, real players connect and try and break the game. Unfortunately, getting a dedicated team of QA testers just isn't possible so I have to rely on friends who can spare a few minutes to give things a go. It's really a bit of a catch-22: keep tests internal and have a few random players give things a try or go public, get more players testing the game but risk turning people off by buggy code.

As for the upcoming internal test, I've decided I'd really like to stretch it out for two weeks rather than the one week I had previously planned. This means fixing the aforementioned problems, cleaning some things up, packaging the game and taking care of any last minute issues. I'm hopeful I can have everything done by then but we'll see.

Anyway, back to the grind. Until next time!

January 13 (A Little Bit Closer Now...)

2008-01-13T12:43:00.001-05:00

Well, it's been an interesting week. With roughly two weeks remaining before my deadline, I've been in crunch mode trying to get things ready for the final closed testing session. My goal by the end of the month is to have all six maps in a playable state and all known bugs fixed. Essentially I want to get as close to beta as possible before the deadline. In real world terms, that means finishing two maps, some minor GUI work and doing a lot of testing.

With that said, I set out this week to get the next map, SegFault, to a playable state. This meant creating an entire map from scratch: terrain, level geometry, etc. Given how short on time I am, I had no idea going in how I wanted it to look or play. The only thing I did know was that I wanted to try something different gameplay-wise so that winning required some unique strategies. I try and follow this guideline every time I make a level but it's getting tougher both because of the lack of time and because there's only so many things to do differently without the risk of breaking gameplay or making something that's not fun.

I divvied up the week in such a way that I had roughly two days for each part of the mapping process: two days for heightmap/terrain design, two days for level geometry, and two days to put it all together. The last day I decided I would use for testing.

By Tuesday I had the terrain done but only after scrapping it several times and doing multiple rounds of revisions. What's interesting is SegFault resembles The Breach in that the terrain is very open with small, rolling hills. It's very organic and natural, unlike most of the other maps which almost resemble pieces of a circuit board. I originally shied away from that approach but it just seemed to fit with the overall theme of the map so I went with it.

Wednesday and Thursday I worked on the team bases. Again, coming up with ideas for these is really starting to be a problem. I think I've got one more design in me before I'll need to go in a completely different direction. One of the problems is I decided at the very start of Bit Battles that there shouldn't be massive interiors. The game was, and is, about players fighting it out outside. Large bases with four walls and a ceiling just don't lend themselves well to this type of game. Unfortunately, there's only so many unique bunker layouts you can make without getting a little repetitive.

Friday I put the pieces together. I played around a bit with the locations of the team bases. There are two bases for each team (for a total of four bases on the map), one in each corner. However, unlike the other maps, the teams spawn on opposite corners of the level. This means that the Green team spawns next to and within viewing distance of the Red team (and vice versa). I'm hoping this will result in some pretty large battles near the spawnpoints.

Objectives, etc. went in easily enough. Only three Capture Pylons in this map, one in the center, one at the north end and one at the south end. Another new thing I tried was putting all of the powerups near the center of the map. I'm hoping this puts some extra value on the north and south Pylons because capturing them will mean gaining access to all of the powerups which in turn will make defending the central Pylon much easier.

SegFault came together well enough and in record time (a mere one week). I will say it doesn't have as much polish as the other maps but that's scheduled for after February 8th. It wasn't the most fun map to work on simply because of the breakneck pace but it should be fun to play.

In other news, with SegFault at a playable state, I spent most of Saturday testing. In the process I discovered a serious issue with vehicle collisions that I had never noticed before. Ramming into walls a very low speeds catapulted the player's hovertank into the air. This was particularly unusual because hitting walls at high speeds resulted in the expected behavior (a hard recoil/bounce back effect). After a few hours of wasted effort I gave up on trying to fix the issue in code. Instead, I opted for replacing the hovertank's collision hull with a simpler design. This had the added benefit of improving the performance of collision detection because the new hull is around 10 polys whereas the old version had ~250 polys.

Next week I'll be repeating the process in an effort to get Access Denied up and running. Any time left over will, as always, be spent on testing and bug fixing. Until next time!

January 4 (Wax On, Wax Off... But Mostly On)

2008-01-04T10:18:00.000-05:00

Another fun-filled week of work on Bit Battles comes to an end. I'm fully in "get this game to beta by February" mode which means tieing up any loose ends and getting things to as close to release state as possible. It also means crunch time for me. Before my February 8th deadline, I have to finish the final two multiplayer maps and revisit some aspects of the GUI and HUD. Doesn't seem like much but each of those items are multi-step tasks and in the past getting even a single map finished has taken about a month (Gateway being the quickest at roughly 3 weeks start-to-finish). To make things a little more interesting, my goal is to devote roughly the first week of February to testing which means the deadline for beta is really January 31! I certainly have my work cut out for me but I'm going to give it my best shot and see where I end up come February.

As for this past week, it was a busy one filled with all sorts of polishing, tweaking, fixing and revamping. The GUI in particular was the target . As anyone who's been following the blog knows, the GUI has been something of a thorn in my side from the very beginning. I've never been able to nail down the look, it's always had some usability issues and it's just plain boring to work on. Thankfully, I'm happy to report I succeeded in revamping the interface. I'm happy with the graphics side of it and everything is laid out in a similar, logical way which takes care of the usability problems. Barring any unseen issues and occasional tweaks, I'm ready to call the GUI done which is a milestone in itself.

Speaking of interface usability, I added some quality of life features: server favorites and a HUD that allows players to stop, pause and fastforward recordings. The server favorites system was a necessary addition and simple to add on top of that. It's all hooked into the server browser as well which means players can sort servers by favorite status, name, map name, battle type, number of players, ping and locked status. Nifty. The recording playback HUD was just something I whipped up in an hour or so. I suspect it'll be useful for those that like to watch past battles (like me!).

I'll be devoting some of tomorrow to finishing up the interface revamp. There's still the end mission GUI (which acts a summary screen, showing what team won, who had the highest score, etc.) to finish as well as tweaking some other HUDs. I'm hopeful I can have all of it done by tomorrow; if not, what's left will have to be pushed back until after February 8th because finishing the last two maps will be the priority come Monday.

Speaking of maps, the first round of testing for the training campaign went well. I fixed a few bugs and tweaked some AI behaviors to make them react appropriately to cloaked and out of sight players (i.e. don't shoot at what you can't see). All in all, I'm happy with the way the campaign turned out. Players learn about the game and how to play and aren't bored to tears in the process. Mission accomplished, I say.

Next week (weekend included!) I plan on finishing up the interface (finally!) and starting (for real this time) on SegFault. The remainder of the month will be focusing on getting SegFault and then Access Denied to a playable state. Until next time!

December 29 (Betanoia - Possessing a Fear of Reaching Beta)

2007-12-29T22:32:00.000-05:00

Well, it's official, I'm starting to see the light at the end of the tunnel. It's a tiny glimmer at the moment but I'm definitely getting there. "There" being the dreaded "beta" stage where all of my blood (not so much), sweat (only in June, July and August) and tears (none of those, either) will be put to the test. Sure, the cornerstone of an iterative design approach is constant testing but for the past few months all testing has been done by me (with the exception of the occasional playthrough by my wife). No "outsiders" have had a chance to play the game in months which should explain why I'm particularly nervous about calling Bit Battles "feature complete" and simultaneously opening it up the public. But that's what I'll be doing in about a month, or so I keep telling myself. In the meantime, there's plenty of work to be done if I hope to have a beta out by February.

On my "must finish by January 31" list:

GUI refinements and possibly some redesign
Two final multiplayer maps (one of which was started last week)
Map revision/refinement
Bug fixes!
Testing, testing and even more testing

The GUI work is something I'd like to avoid (oh, how I hate it) but simply can't. As it stands, the GUI is in dire need of some sprucing up both graphically and usability-wise. The GUI graphics have probably received the most revising but I've yet to find a style or look that really fits the game. Either it's too simple, too blue or both. I'd hire an artist to do things properly if the game budget was more than what I can find between the cushions of my couch. Oh well, back to GIMP I go.

As for the final multiplayer maps, I'm looking forward to working on them. Pushing out two maps in a month is going to be a challenge, though. On top of all the art and sound assets needed, the final two maps are really the least fleshed-out. D'oh!

On top of that, I'm setting aside a week so that I can give each map a once-over and cleanup any problems, enhance a few things graphically, etc. The goal isn't to fundamentally change any of the maps but, rather, to cover up the fact that some of them (like The Breach) were made before I really knew what I was doing or what the world of Bit Battles looked like. It's interesting to see the difference between levels made later (like Gateway, which is full of various special effects and just oozes coolness) and those made early on. The newer maps just have an extra level of detail about them and that's exactly what I'm hoping to add to every map.

And on top of all of that, there's still tons and tons of testing and bugfixing to do. It's going to be a busy month!

But enough of what I plan on doing, let's get to what I actually did.

Quite a lot, actually. All five training levels are complete, the gametype system has been fixed, a few engine optimizations were put in and I polished some art and sound assets.

The training levels were actually easier to create than I anticipated. Each map builds off of the previous one thereby forcing players to not only learn new skills but continually practice the ones they've already learned. As it turns out, developing the training maps with this idea in mind had the benefit of reducing code complexity while increasing reusability because each level can make use of the code written for previous maps. As an example, the third training level teaches players about powerups (what they are, how to get them and how to use them). In order to familiarize the player with powerups, one of each type of powerup is spawned around the level, waypointed and an AI drone is created to guard it. The only "new" code written for this map was dynamic powerup spawning; the code for waypointing level objects came from the first level and the code for spawning AI drones was a quick copy-paste job from the second level.

Getting the training campaign done is a major milestone for the game. It means I can refocus on the multiplayer aspect which is a good thing for a multiplayer-only game! Here's hoping the testing goes just as well (and just as fast!) as the actual implementation.

I spoke last week about several issues with the gametype handling code. Thankfully, most of these turned out to be false alarms. The only gametype dealing with server shutdown cleanup issues was the training gametype. A quick fix was all that was required to get it behaving normally. Given the crunch mode I'm about to find myself in, avoiding a rewrite of the gametype handler is definitely a bullet dodged.

The engine optimizations were added not because they were "needed" (the game actually runs quite well, even on older hardware) but simply because they were simple to add and could do nothing but help performance. Most notably was the Optimization Kit released for TGE 1.4.2 which included batched decal and precipitation renderers. The performance increase wasn't tremendous but any improvement is good. There's still more work to be done in this area (especially with moving the renderers over to retained mode rather than immediate mode) but that's something that'll have to wait.

And lastly, polishing. I mentioned last week I reworked the sky/cloud textures. This week I continued that trend by redoing the smoke textures that emit from damaged players, adding a simple firing animation (with muzzle flash!) to the hovertank and tweaking a few sounds. They're small things, really, but attention to detail is important.

On the agenda for next week: testing training maps, getting properly started on the SegFault map and preparing for the final push to beta. Oooh, "beta"... sounds like fun!

December 21 (Multitasking)

2007-12-21T15:57:00.000-05:00

Wow, what whirlwind the past week has been! Here's a rundown of what's been going on:

The website (specifically the Bit Battles preview) got an update (new screenshots and a CSS "fix" (hack) to make Internet Explorer render the page properly).
The training campaign is still in-progress. The first two missions are "done" (meaning functional but not thoroughly tested); the third is still in the early design stage.
I shifted focus and started taking care of the growing bug list.
On top of that, I played artist and reworked the sky/cloud textures and created some new terrain textures for the next multiplayer map.
Speaking of which, I roughed out the terrain for the next multiplayer level. Multitasking at it's best (or worst...).

The Fanatical Games website got a bit of an update this week. Specifically, new screenshots of Bit Battles were posted and the Games section was reworked to better accommodate Internet Explorer's "interesting" ideas on how to render CSS. Most notably, a vertical scrollbar no longer appears on the page when rendered in IE.

As for Bit Battles, when I left off last week my intent was to finish up the first two training levels and get started on the next two. Instead, I was forced to put those on hold and tackle a growing number of bugs (some of which were fairly major).

First, the Find & Retrieve gametype was a mess. I've rewritten once already but it's since been broken (several times!) by various engine and script changes. The basics of the gametype worked (players could grab a Nanite and capture it and teams could win) but there were a lot of little cases where things could go wrong (i.e. Nanites that were captured by being thrown into a Nanite Reclaimer rather than being brought in by a player weren't given various state info so they couldn't be stolen by enemy players).

To top it off, the code was just ugly and hard to read. As a result, I gave up hope of trying to fix what was there and just went about rewriting (again). Thankfully, that was probably the best decision because in the process I found quite a few more bugs that hadn't been found. As of right now, F&R is working better than ever. It still needs much more testing but the code is much cleaner, easier to read and just works.

Another serious issue that I'm still tackling is the gametype handling code. Gametypes have always been a bit of a hack (and an unnecessary one at that). They rely on a piece of script that's initialized on both the client and server. Clients use the code to get a list of all available gametypes and associated maps; this is then fed into various GUIs. Servers use the code to load/unload gametypes that actually make the game function. Unfortunately, there's been several longstanding problems with gametypes not being shutdown properly or failing to cleanup after themselves. I thought I had all of the problems with them sorted out but apparently not. While playing through the first training mission, I decided to check something in one of the multiplayer maps. After zoning in, I realized the training gametype wasn't shutdown; I was still getting dialog messages despite being in a multiplayer map. D'oh!

Fixing the problem is really going to require a rewrite of the gametype handlers. I'm not looking forward to it but it's obvious the quick fixes aren't what's needed. I'm sure I'll have more on this next week...

In the midst of bugfixing, I decided to finally redo the sky and cloud textures. Anyone that's been following the game for a while knows that the sky textures are about the only thing that haven't went through a revision. In fact, they've been untouched since the first prototype so their time was definitely up.

Going in, I wanted to make something detailed but still keep the digital theme and it had to have the same color schemes as the previous sky textures. After playing around in GIMP for a few minutes, I came up with something that really resembles the skies of Darwinia (which I've always liked). I'm not quite ready to show them off yet but I will say they really add something to the game. Score one for iterative design!

And lastly, I did what I probably shouldn't have and started roughing out the next multiplayer map, SegFault. I'm aiming to one-up myself with this map, both graphically and gameplay-wise. Everything is still in a very early design phase (and probably will be for the next few weeks while I get the tutorial levels sorted) but I'm excited about working on it.

That about sums it up. Next week I'll be reworking the gametype system, getting the third tutorial level running and a ton of other miscellaneous tasks. Merry Christmas!

December 13 (Unintentional Conditionals)

2007-12-13T10:37:00.000-05:00

More progress this week on the offline/singleplayer training levels. When I left off last week, the first two training missions were set to be completed. While both of them aren't completely finished, they're getting close.

To avoid unnecessary code overlap and in the interest of maintainability, I created a specialized gametype just for the training campaign. The tutorial gametype takes care of things like player and AI spawning, dialog prompter, mission state handler and even maintaining the simple state machine that controls AI behavior. Dumping lower-level tasks like these in a gametype means the individual missions can take care of level-specific tasks without duplicating code. It's also worked nicely with the existing gametype framework. When training missions load, the server automatically initiates the tutorial gametype code.

I spent most of Friday and Monday working on the first training level. As I mentioned last week, this level introduces the player to the world and teaches them how to pilot a hovertank. The training map itself (terrain, structures and the like) had already been completed so getting the level up and running meant implementing just the things that actually made the mission work (i.e. setting/destroying waypoints at the appropriate times, detecting when a player had driven to a specific waypoint, etc.). Fairly simple stuff to implement. By Monday night I had a working tutorial level that answered the basic "what, when where and why" questions as well as how to move in the world.

Tuesday and Wednesday were spent getting the second training level going. This level teaches combat basics; how to fire the forcebolter (hovertank weapon) and how to charge the forcebolter for faster/more damaging shots. After explaining how to shoot effectively, the player is told to go and destroy a set of AI drones at designated waypoints. The drones are guarding their waypoint and will chase and fire on the player if he/she gets too close or if fired upon. Once all drones have been destroyed, the mission ends. Again, simple requirements that should've been easy to implement. And it was, except for the slew of "Oops! I didn't think about the possibility of that happening..." moments. As an example, when a player is destroyed in a multiplayer match everything works; the player's hovertank explodes, a chat message is sent out letting everyone know who died and who did the killing and, after a short pause, the player can spawn in again. Offline, however, things broke. At first, being destroyed meant seeing your hovertank explode but still being able to pilot it. Driving a burning pile of rubble was certainly one of the funnier moments in development but hardly the outcome I wanted. Once that was fixed I realized the chat message alerting everyone that the player had died was broken as well. Instead of saying something like, "Bit Battler was derezzed by Drone 1!" it said "Bit Battler was derezzed by !". Why? Because bots don't have client objects like players and the message was getting the killer's name via the client object. No client object, no name. D'oh!

There's a few more issues like these that I won't mention (mainly out of embarrassment) but fixing them takes time which is why the two mission are only "nearly done" instead of "really done." I hope to have everything working as expected by tomorrow which means next week I can start on the remaining tutorial levels. On deck for next week: Training Mission 3 (Powerups) and Training Mission 4 (Objectives: Capture & Hold).

Until next time!

December 8 (You Put Your Left Foot In...)

2007-12-08T18:07:00.000-05:00

When I left off last week, the AI drones were smart enough to (temporarily) move on to other things. "Other things" being the first training mission. The training campaign is broken down into six levels (which all take place in the same map). These six levels each teach a certain aspect of the game (i.e. movement, powerup types and usage, Capture & Hold objectives, etc.).

For the first training mission, the goal is to introduce players to the game by answering the basic "why, where, how" questions about world and then move on to explaining the various HUD elements before finishing off with a quick rundown of how to move. After explaining how to do something, the player is encouraged to actually go do it. The first level encourages the player to get used to piloting a hovertank by setting a series of waypoints the player must drive to. Driving to all of the waypoints completes the mission and let's the player move on to the next thing.

The tricky part about offline levels (especially ones designed as a set of tutorials) in a multiplayer-only game is keeping things interesting for the player. I have to assume that the first thing most players will do is give the singleplayer tutorials a try before jumping online. If that's the case then the offline part may very well determine whether a user continues playing or not. If things are too tedious, boring or just "unfun" offline, why bother giving the multiplayer portion a try (despite it being the "real" game)? It seems the really difficult part is going to be trying to make a set of training missions that teaches players how to play while holding their interest.

With this in mind, I've created a few guidelines for myself to follow as work progresses on the singleplayer tutorials:

Keep in-game dialog to a minimum; dialog should be aimed at explaining something. Avoid rambling at all costs. Too much dialog and the tutorial becomes a novel (a boring one at that!).
Downtime in the levels should be kept to a bare minimum. The player should always be doing something even if it's only reading about what to do next.
Make the training level as atmospheric as possible and try and suck the player into the world.
Give the player clear goals and explain up front the skillset they will learn and why it's important they learn them.

I'm hoping these guidelines will help me correct (or hopefully avoid altogether) some of the many pitfalls involved in making a training campaign. Given that the first and second training missions are on deck for completion next week, it shouldn't be too long before I know whether or not they actually work!

Progress Backlog - November 24 (Offline Woes and Foes II)

2007-12-01T12:56:00.000-05:00

[The following is a backlog of progress which occurred from November 24 through November 30.]

Back again this week, still in the process of getting everything hooked up at the new house. When I left off last week, the first attempt at bringing some artificial intelligence to Bit Battles had ended with less than spectacular results. The bots had no idea how to find their way around the maps, no sense of aiming or leading and generally served only as moving targets (atleast until they hit a wall).

At the start of the week I set about fixing up the AI. First thing: pathfinding. I spent the better part of Monday and Tuesday getting a basic A* pathfinding system in. This, of course, after attempting to get by with a much simpler waypoint-based system (for the curious, this was a no-go because the bots would chase players and either get lost on the way there or on the way back... d'oh!). The pathfinder is pretty barebones. It creates a serious of nodes around the terrain, links them together and shortest-path paths can be created from them with a simple createPath() method.

Once I got this in, I was excited to see it in action. I knew the bots weren't going to be ace hovertank pilots yet but I figured they should be able to atleast move in a semi-intelligent way. Wrong. The pathfinder worked great but the steering code didn't. Bots would overshoot their target nodes and either backtrack in an attempt to correct themselves or spin wildly around. Fixing this meant reworking the entire steering function. It's still a work in progress but it's gotten better. Bots don't spin nearly as often although there's still way too much backtracking going on.

Satisfied, atleast for the timebeing, with the way the bots moved, I decided to work on the AI behaviors. For the training campaign, bots need only two basic tasks: defend position or attack player. Defend means the AI will go to a location (if not already there) and perform a constant radius search for the player. If the player comes within range, the AI switches to Attack and chases the player, firing as often as possible until someone dies or the AI gets too far from their original position in which case they break off and return to defending.

The Attack mode raised another issue: bot aiming. The bots could face and track the player reasonably well but the aiming function didn't take into account player velocity so the bots would often fire at the position the player was rather than where the player would be. This was a simple fix and the result was bots now lead their shots and are surprisingly effective shooters. It certainly makes combat more interesting!

Next week it's more AI programming and the first training mission is on the clock. Until next time!

Progress Backlog - November 19 (Offline Woes and Foes)

2007-12-01T12:02:00.000-05:00

[The following is a backlog of progress which occurred from November 19 through November 23.]

I'm still in the process of moving so things are a bit sluggish on the blogging side. Nevertheless, quite a bit has been done on the game so let's get right to it.

I mentioned in the last post having quite a bit of GUI work to do. GUI design and implementation is certainly my least favorite aspect of game development which explains why some of the non-essential parts of the interface (the options GUI isn't needed, is it?) had been on the backburner for the past few months. Despite my aversion to all things GUI, this week I was determined to bite the proverbial bullet and just get the things done.

I started by creating a mini tasklist to prioritize things a bit. I determined that not only were there a handful of interface bugs to fix but a lot of cleanup needed to be done. GUI profiles used in-game were overwriting those used in the editors and there wasn't much consistency between what fonts and font colors were used where. With that in mind, I set about reworking the "pretty" stuff from the ground up; creating new profiles for a wider range of things as I went a long. This took about a day but the result is a much cleaner, consistent look. Simple things like menu buttons having the same highlighted color, etc. are important in maintaining the professional feel of a game.

By Tuesday, I was ready to tackle the GUI bugs. The credits screen bug was probably the strangest; a single URL at the top of the dialog was rendering a double underline in a random offset. To make matters worse, it only happened at seemingly-random times. After pulling my hair out for a few hours, I simply gave in to a quick fix and added an extra close tag at the end of the URL and for some incomprehensible reason it worked. I'm sure it's some issue with the way tags are parsed but that gets into the ML language parser which is something I don't have the time to do.

On Wednesday, it was time for the dreaded options screen redesign. Up until now I had been using the default TGE options GUI which, as anyone who's ever worked with TGE can attest to, is pretty barebones and has some issues of its own (click the Audio tab and watch as the OpenAL extensions list blocks the audio sliders!). So, I quickly threw out the idea of updating the default options interface and decided to write my own. An hour or so later and I had a window with four tabs (Controls, Graphics, Audio and Network) with all of the associated fields, etc. The design didn't take very long, it was the implementation that turned out to be the real bear.

First, there was the task of figuring out how to actually remap controls and get each binding listed in the Controls pane. Bugs abounded here. Controls could be mapped to two or more keys at once but the binding text listed only one key. Further, controls without any binds couldn't be bound at all! Fixing all of these (and several more that I dare not mention, lest they reappear) took around three hours.

Then the Graphics pane decided to cause some trouble. The gamma correction slider had no effect, the resolution list would update but, when the game was changed from fullscreen to windowed and back to fullscreen, only resolutions less than the desktop resolution were added. To top it off, certain preferences that needed a slider weren't being saved which meant implementing an 'Apply Settings' button to forcefully save everything. Another two hours gone.

Thankfully, by the end of the day I had the options GUI done an working (as far as I can tell, anyway).

On Thursday, my goal was to get the player profile pane tacked on to the multiplayer GUI (which is where players can create/host their own games or search for currently running servers). This was a fairly simple task that didn't need a great deal of implementation. The player's profile contains things like player nickname, website/email address, clan/team name, tag and website and even a quick taunt field so users can spam their favorite saying. The really cool thing is that other players can view profiles of people playing with them. I'm hoping it'll turn out to be a good community builder, hopefully aiding players in finding friends, etc.

By the time Friday came around, I was ready to move on from GUI work so I switched gears entirely and delved into preliminary work on the offline training/tutorial "campaign." The offline portion of Bit Battles is a bit of a double-edged sword. On one hand, it'll be played at most once or twice (or maybe not at all!) by any normal player so devoting massive amounts of time and resources to it seems unncessary. On the other hand, it's a very necessary part of the game because it gives some insight into the storyline on top of explaining how to actually play. This becomes even more important in a multiplayer-only game because new players that zone in to a server and get their butts handed to them are much less likely to ever play again.

With all of this in mind, I decided to devote as little time to content creation as possible for the offline portion (which means reusing models and textures used in the multiplayer maps) but allot as much time as necessary to making sure the tutorials were actually useful. The result was I whipped up the training map in an hour or so and spent the rest of Friday writing the help text. I went through several revisions of the help text trying to find a nice balance between too much and too little. I wanted to answer the basic "where, what, why and how" questions but at the same time give some personality to the tutor.

And then Saturday came and I got my first glimpse of the horrors that is AI programming in Bit Battles. Oh, boy was it awful. My poor bots ran head-first into walls, couldn't aim at and actually hit anything smaller than the Moon and were basically as dumb as rocks. Seeing them in action made me call it a week.

Next week, I tackle AI (again) and hope to come out with better results. Be sure to tune in for the next episode of, Woes and Foes.

Progress Backlog - November 17 (Update Smorgasbord II)

2007-11-21T14:36:00.000-05:00

[The following is a backlog of progress which occurred from November 9 through November 17.]

This week was certainly one of the busiest and most productive thus far. Last week I talked about implementing a week-long todo list and that's proving to be a wise decision. As I said last week, checking things off and, more importantly, reaching the end of a todo list offers a motivational boost that keeps things moving even through the boring stuff (like GUI design!). But enough of that, on to Bit Battles news

I spent much of the week getting Gateway done. That meant getting the terrain heightmap finalized, texturing it, modeling/texturing all of the art assets, whipping together any needed sound effects and finally pulling it all together in code. Quite a lot of work but all of it was fun. Here's how the week progressed:

Monday was spent finishing the terrain (including texturing). Fairly simple process of making sure the terrain is balanced (symmetrical) and roughing out placement of bases, spawnpoints, etc.
Tuesday, Wednesday and Thursday were the designated "model days". The goal was to start and finish all of the models needed for the map. This included bridges (both working and destroyed) connecting sections of the level, random pieces of rubble, destroyed structures representing remnants of the team bases, etc.
Friday and Saturday saw me tieing up the loose ends and getting all of the map effects (like smoke rising from the craters, fireballs falling from the sky, etc.) working. In addition, spawnpoints, objectives and powerups were put in.

On top of all of that, I removed hazard zones from the game. It was tough decision to make; besides being a good bit of work the hazard zones idea had the potential to be fun, the implementation simply wasn't doing it justice. Unfortunately, there's just not enough time to do it right and in the name of getting this game done, out they went.

And in addition to everything else, there were bugs to fix. The issues weren't really gamebreaking, mostly minor things like player score text not updating properly, a misspelled variable name, etc. Two in particular though had been plaguing the game since it's inception and I was determined, above all else, to squash them. Thankfully, I managed to fix the problem in about an hour; hardly the epic struggle between man and code I was expecting.

I'm happy to say the game has really moved several steps closer to being done. Hopefully this is just the beginning of a trend.

As for next week, in between moving, I have a backlog of GUI work that needs to be done. The options dialog needs to be rewritten, there's a bug or two with the way the credits screen is rendered and the player profile section needs to be added in. I'm also aiming to switch gears a bit and get some preliminary work done of the offline training missions.

November 8 (Update Smorgasbord)

2007-11-06T17:33:00.000-05:00

What a week it's been! There's been a ton of progress on Bit Battles, the website has received some updates and new tallies from the DreamGames 'Game in a Year' contest have been posted.

First, the the Fanatical Games website has gotten an update. As mentioned in the last post, the old 'In Development' section has been replaced by a slightly more elegant 'Games' page. Eventually this area will contain previews of upcoming games as well as direct links to individual game websites. In addition to that, a new 'Community' link was added that takes visitors to the official Fanatical Games forums. The forums will be a pretty important community-building tool in the near future. Once Bit Battles is released, I'd really like to see it become a 'hub' for all sorts of game-related things like team/clan recruiting, game times, etc.

As for the contest, Bit Battles is still hanging in there. The game was ranked 9th this quarter (assuming I haven't miscounted) which is better than last quarter. The next half of the contest is really going to be the proving grounds, though. Blog updates will begin taking a backseat to actual progress/deliverables. I'm personally excited about all of the projects involved and I'm certainly looking forward to playing each one. So far, the contest has really prove to be a boon for the indie community. There's several great games involved and, surprisingly, the teams are staying motivated and actually getting stuff done. Amazing what the promise of funding can do!

Now, the juicy stuff: game progress. Tuesday I switched strategies a bit by making a week-long todo list. This is a change from my usual daily tasklists in that it lays out the week ahead and gives me a good indication as to how much time each task will take versus how much time I can devote to development. It's also a good way of measuring true progress as I can tick off items on the list as they're completed and look back at the end of the week and see exactly how much closer the game is to being done.

I had a really extensive list of things to do on Tuesday ranging from getting some particle effects working to rebalancing forcebolt damage/speed. All told, I had about 10 items to finish within 6 hours of development time. The list itself looked something like:

Rebalance forcebolt damage/speed
Get Energy Boost repair effect working
Get Gateway environmental effects working
Add game time HUD
And hovertank damage effects
Begin work on art assets for Gateway

As you can see, a couple things on the list were really categories which contained sub-tasks (i.e. the environmental effects for Gateway actually meant creating several particle effects, textures and sounds and tieing them all together via code). Thankfully, at the end of the day everything was marked off. Another day down, many more to go. :)

As for the rest of week, I have an additional 12 things to do ranging from finishing Gateway to GUI work. I'm pleased with the progress or, more importantly, the pace at which progress is being made on Gateway. It's looking like by next week it should be finished which is quite fast given Fragmentation took over a month! Finishing early should help relax the schedule a bit and provide more development time for the all-important singleplayer training campaign.

Until next time!

October 31 (The Word of the Day is: Re)

2007-10-31T15:48:00.000-04:00

Bit of a short week but some good progress was made on Bit Battles.

Two of the five powerups in Bit Battles were revisited, revamped and generally re-something'ed. Powerups are special items that players can collect which, when used, temporarily give them special abilities. In the original design, two powerups in particular were created to accomodate the 'movement-oriented' nature of the game: the Quick Stop and Super Jump. The Quick Stop powerup was essentially a one-shot emergency brake for a player; using it would instantly stop the player's hovertank from moving thereby giving him/her a chance to avoid running into a hazard zone or simply prematurely end the 'punting' effect caused by being damaged. The Super Jump powerup, unsurprisingly, caused the player to spring into the air, possibly jumping over enemy vehicles, hazard zones or other obstacles. These two powerups offered a nice bonus to a player adventurous enough to collect them but, unfortunately, there were some design issues with them.

Both powerups, like the old 'no health/no death' and 'punting' systems were really remnants of the game Bit Battles was going to be, not what it currently is. Both powerups are focused on movement, either impeding or enhancing it. Unfortunately, Bit Battles isn't focused on hovertank movement anymore; it's become more about vehicular combat than anything else. Given this perspective, what it comes down to is the Quick Stop and Super Jump just weren't that useful anymore, nor were they fun enough to warrant leaving in.

Going further, both powerups were somewhat exploitable and potentially serious balance issues loomed on the horizon. As an example, the Super Jump could be used to allow a player to perch themselves on typically unreachable level geometry and fire down at other players while being essentially invincible. This is obviously bad enough but what if they were carrying a Nanite objective as well? A potential stalemate/'turtling' situation could arise and that's never any fun.

In the end, I replaced the Quick Stop and Super Jump with (hopefully) some really fun alternatives: the Energy Boost and Shockwave. Energy Boost does what it's name suggests, restoring 15% of a player hovertank's health (energy). This is accompanied with a nifty effect whereby streams of energy particles are emitted from the player's vehicle (it's really reminiscent of the bandaging effect in World of Warcraft). The Shockwave emits a large concussive blast centered around the player which pushes away any nearby enemies.

These new powerups have some really interesting gameplay possibilities, both defensive and offensive. It'll be interesting seeing how players put them to use, what exploits they find, etc.

As for Gateway, not a lot was done on it this week with the exception of some early heightmap work. I hope to get back on track with it in the coming week, with a projected 'final' date towards the middle of November. That's really pushing it but with the contest deadline just around the corner it's time to speed things up a bit.

I spent the remaining time this week working on updating the Fanatical Games website. Coming soon-ish: a revamped 'Games' section which will replace the old 'In Development' page. The new page will feature previews of upcoming Fanatical Games software, links to individual games websites, etc. Also included is the new 'Community' link which will take visitors to the Fanatical Games forums.

On the agenda for next week: complete Gateway terrain, start preliminary work on art and sound content and bug fixes.

Progress Backlog - October 27 (Time Lapse II)

2007-10-29T13:40:00.000-04:00

[The following post is a backlog of progress which occurred from October 20 through October 27.]

Work on the Gateway began in earnest this week. The usual process of 'fill in backstory details -> create art and sound content -> rough draft of level -> revision one -> revision two' is still taking place. Currently I'm still at step one, filling in the backstory with minor details that seem plausible (well, as plausible as possible given the nature of the game).

Thus far, Gateway is shaping up to be a pretty exciting level. The map represents a section of the network where packet routing has gone haywire due to unexpected hardware failure. As a result, packet collisions are rapidly destroying much of the sector.

Continuing with this theme of packet collisions/destroyed environments, the terrain will be riddled with craters (aftereffects of packets that have gone off course and crashed). Speaking of which, the packets themselves will be represented by digitized fireballs that constantly fall from the sky. All in all, the effects should make for one of the more attractive levels in the game and certainly one of the most atmospheric. Fighting amidst smoking craters and ruined structures while fire falls from the sky just sounds like fun. Here's hoping I can make it look as cool in-game as it sounds.

I'm predicting Gateway will be a another "testbed" map. I'll be trying out some different placement positions for objectives to see how they affect gameplay. At the moment, I'm imagining Gateway being very centralized, with all objectives in a close proximity to each other, perhaps in the middle of the map. Spawnpoints will be placed sporadically across the map (with each team getting roughly half of the map devoted to their spawnpoints). My hope is that this will mean constant, large-scale battles taking place in the middle of the map as wave after wave of players spawn from various locations around the level and migrate towards the center. That's my hope, anyway.

Next week, I hope to have the backstory done and perhaps some early work on roughing out the level. Wish me luck!

October 19 (Frag Out)

2007-10-19T16:29:00.000-04:00

Whelp, it's done! Fragmentation has left the building. Here's the scoop:

At the beginning of the week I was determined to have Fragmentation finalized in two days. On the clock: powerups and hazard zones. I tackled powerups first, placing two types of powerups in strategic locations around the map (while also keeping in mind map balance). The first playtests went well, the powerups gave each team an advantage but weren't overpowering and the placement seemed to be a good distance between bases and objectives. Mission accomplished.

Next, it was time to throw in the hazard zones. I tend to save these for last because I often use them as an extra obstacle to avoid in order to reach powerups or objectives. Finding the fastest, easiest way around hazard zones is a key gameplay element. The usual combination of Leech, Catapult and Anchor zone were placed and the positioning passed the initial playthroughs. More testing will be needed to really determine map balance, though. It's very possible that certain combinations of powerups are overpowering, or certain geometry on the map is exploitable, etc. I expect to make plenty of adjustments to every map (including Fragmentation) once beta officially begins.

In the meantime, here's a couple screenshots of Fragmentation.

I like the way it turned out. It just 'feels' like a broken world, structures long-since destroyed float in the sky, columns jut out of the wild terrain. Even the bases themselves, not much more than spawnpoints hastily constructed amidst the rubble, enhance the feel of a fragmented sector of space. Here's hoping it's as fun to play as it was to build.

As for next week, it's full steam ahead on the next map, Gateway. The website will also be getting a bit of an update (those old screenshots have to be updated!). Until next time!

October 10 (Stalemate)

2007-10-10T14:46:00.000-04:00

This past week progress has been slower than usual. Fragmentation still isn't done, although it's close; the next map, Gateway, is still in its infancy and there's a backlog of minor bug fixes and tweaks that need doing. In an effort to make myself feel better about the situation, I've attributed the lack of progress to an unusually busy real life schedule.

But, let's talk about what has been done.

Fragmentation is still limping along. I managed to find a few minutes of free time and setup the team bases. I use the term "bases" loosely because, unlike other maps, the teams spawn in a hastily built fort amidst piles of fragmented rubble. I attempted to give the feeling that the two teams literally just dropped into the sector with barely enough time to clear the dropzone, much less setup defenses.

In another spurt of spare time I setup the Capture & Hold objectives. Fragmentation has a total of five Capture Pylons, the most of any map. Each team has access to two pylons near their "base" with the final one strategically placed in the center of the map. I'm predicting (or hoping, really) that such a high number of objectives will spread teams thin and result in many smaller battles taking place across the map at all times. Or it could result in the two teams taking control of the nearest pylons and fighting in one large constant battle over the middle objective. Either way sounds like fun to me!

Powerups and hazard zones are next to go in and then it'll be on to setting up the Find & Retrieve version. If only I could find more time...

And, despite feelings of being way ahead of myself, I've started down the path of fleshing out the new "next map", Gateway. Gateway represents a sector of the network virtually destroyed by packet collisions. Craters dot the terrain, remnants of packets that have gone awry. Objectives are on a series of plateaus connected only by bridges, many of which have been destroyed. The goal to winning will be finding convenient ways of reaching and defending the objectives.

I'm imagining the world itself as almost post-apocalyptic in nature. Utterly devastated, rubble everywhere, etc. We'll see how effectively I can take my vision and turn it into something tangible in the coming weeks.

In the meantime, it's back to Fragmentation for what's hopefully going to the final week. Where I have heard that before?

September 30 (Game. Set. Map.)

2007-10-01T14:32:00.001-04:00

A bit late on the update this week. How time flies when you're in crunch mode! The focus this week was revising Fragmentation for the second time. My aim was to essentially get it to a playable phase. Although the week went reasonably well, I'm not quite where I wanted to be progress-wise.

For the sake of time, here's a quick rundown of the week's events:

Tuesday and Wednesday were spent tweaking the terrain in an attempt to enhance the "fragmented" feel. This was a real pain as I had to keep terrain symmetry/map "balance" in mind when making changes. In effect, this meant changes on one section of the terrain had to be duplicated on the opposite side. Ultimately, I was forced to overlook the map editor's built-in terrain tools and edit the heightmap directly. Duplicating changes at the pixel level is just easier than the guesswork involved in tugging at vertices. The terrain still needs some further tweaking for playability purposes but I'm happy with the look.

Thursday, Friday and Saturday were spent putting in level geometry. All of the models created over the last couple weeks are in (for the most part). It's surprising how much even a few bits and pieces of art content can enhance a map's atmosphere. The broken obelisks fit really nicely amidst the cracked terrain and provide some much needed cover for players to hide behind. There's still a lot of work to be done in this area (especially in positioning level geometry to enhance, rather than hinder, gameplay) but progress has been good.

Unfortunately, I'm now a week past my original deadline and there's still quite a bit of work left to do on Fragmentation. Team bases/spawning points, objectives, powerups and hazard zones still have to be placed and some early playtesting to rid the map of any obvious exploits have to be done before I can deem it "finished." With that in mind, the upcoming week looks like a busy one as my focus returns to getting Fragmentation done. Wish me luck!

September 24 (Pieced Together)

2007-09-24T16:25:00.000-04:00

This week was focused on the completing the first revision of the Fragmentation terrain and finishing the last of the art assets needed for the map.

The first revision process on a map involves doing a semi-extensive "flyby" over the terrain, checking for symmetry, possible layout exploits, etc. while also trying to visualize where all of the art content will be placed. It's during this phase that I start doing preliminary layout work; putting down actual geometry, setting up team bases and that sort of thing. It's a fairly exciting time because the design is still fluid and may change.

The first revision of Fragmentation went well. The level now has a complete, fully textured terrain with some simple level miscellaneous geometry dotting the landscape. It's still a ways from being playable but the map is finally beginning to take shape. With another week (and another phase of revision) I expect to have it playable.

As for the art assets themselves, they're done! As predicted, the "needed art" list was a fair bit smaller with this map than previous ones. I managed to get the remaining models built and textured on Friday, just before calling it a week. In all, there's about ten various structures that'll fill the map so it should be a fun process getting them all in-game.

Next week, it's second revision time on Fragmentation. Level art goes in and hopefully a finished map comes out. Until next time!

Progress Backlog - September 14 (Time Lapse)

2007-09-17T15:40:00.000-04:00

[The following post is a backlog of progress which occurred from September 8 through September 14.]

A much-needed vacation took up the majority of my time but I still managed to get a few Bit Battles-related tasks accomplished. Namely, the design doc was updated in preparation for the next submittal date, a few more art assets were completed and a rough draft version of the Fragmentation terrain was created.

First up, the design document. I managed to find time to revise/update the design doc in between packing and checking reservations. My goal was to read over everything from the viewpoint of a potential publisher who knew nothing about the game. With that in mind, I set about clarifying things and rearranging sections of the document to make them easier to find and understand. Asking myself (potentially) the same questions a publisher might ask while attempting to find the answers in the design doc really proved to be a helpful means of revising it in a meaningful way.

Secondly, art assets. Nothing terribly major here, just a few more broken obelisks, cracked pillars, etc. Fairly simple stuff designed to compliment the map and generally make things look interesting. As work on Fragmentation progresses I'm sure I'll have need for more intricate geometry but that'll come in time.

Lastly, the rough draft of the terrain. Fragmentation is another balanced map (symmetrical terrain) which is proving to be a bit of an interesting challenge. Creating terrain that feels broken or fragmented while maintaining symmetry is pretty difficult but I'm making progress. The rough draft needs quite a bit of work; some of the steep slopes hinder movement a bit too much and the texturing is far from complete. I'm hoping, time permitting, to have these issues ironed out in the first revision scheduled for next week.

Next week it's on to the first revision of the Fragmentation terrain and new art content. Until next time!

September 7 (Fragments of Fragmentation)

2007-09-07T15:09:00.000-04:00

This week work continued on Fragmentation, the new "next map." It's is still in very much in the initial design/"rough out" phase so progress is a bit slow but things are definitely moving ahead.

First up, getting the map backstory completed. The backstory is really just a paragraph or two of text that displays on the load screen but it serves to explain what's going on in the sector, what the teams are fighting over and generally helps the overall atmosphere of the game. As of now, the storyline for Fragmentation revolves around the teams battling for control over a fragmented sector of a network hard drive which contains administrator passwords. Gaining control of the sector would give the team unrestricted access to large portions of the network. More detail is given in the design doc and on the load screen, of course, but that's the gist of it.

Next up, some preliminary artwork. This involved creating large jigsaw-ish obelisks, floating cube fragments, etc. Basically fluff to fill out the map and reinforce the idea that this sector is broken or disjointed. When finished, the map will be filled with random, seemingly out of place shapes that should show off the map concept. So far all of the geometry has been relatively simple to make but I'm expecting some more elaborate designs will be needed as things progress.

Next week promises to be even slower as I'll be out of town for most of it but I'm hoping to finish atleast a rough draft version of the terrain as well as some more (early) art content. Until next time!

August 31 (Of Maps and Men)

2007-08-31T16:45:00.000-04:00

Another good week comes to a close. Thankfully, despite a surprisingly small amount of time to dedicate to Bit Battles, stuff got done!

First up, Power Failure has reached "alpha complete" stage. I'm coining that term for maps which are complete in the sense that level layout is finished and there are working versions for all gametypes but changes may be made based on playtesting and feedback. Maps that have reached this status are playable but not quite ready to ship; the "almost there, but not quite" levels, in a sense. More polish is needed to really finalize all of the maps but that's being left until much later in the year (or even early next year). We'll see how that works. Finally, here's a couple recent screenshots of the Capture & Hold version of Power Failure:

In the meantime, with mapmaking now in full swing, Fragmentation is on the clock. The design doc describes this map as rough, craggy and foreboding. Massive obelisk structures jut wildly out of the landscape, undoubtedly representing broken pieces of files that have scattered across the sector over time. The terrain itself is broken, dotted with massive plateaus and steep dropoffs. Pretty cool sounding stuff, I think.

As I said last week, I'm really looking forward to digging into this map. I have a clear idea of how things should look and feel and that should make the art process faster. Speaking of which, I'm predicting the art requirements for this level will be a bit smaller than Power Failure. The map backstory says the teams have only just arrived in the sector meaning no well-built walled-in bunkers or secured forts here. In fact, the teams will be spawning in makeshift bases that have been hastily constructed amidst the broken file fragments.

I'd also like to try a couple different things with this map. Namely, adding a fourth objective and playing around with spawnpoint location to enhance the feel of the "hastily constructed base." It's all rough draft stuff for the time being but I'm excited to see how it works out.

Until next week!

August 24 (Level Up!)

2007-08-24T15:27:00.000-04:00

Power Failure was the main focus this week and I'm happy to say it's really come a long way.

After doing some playtests, I realized the map layout was a real hindrance to gameplay. Specifically, the two power supply coils I talked about last week were clogging up the middle of the map making it especially hard to capture and hold the middle objective. I didn't want to trash the whole concept but it was obvious some tweaks were in order. The solution was to move the coils to opposite corners of the map. In addition to freeing up the middle of the level, it solved another problem: each corner of the map had a plateau that was essentially "empty" space with no geometry or objectives nearby. By moving the power supply coils (and accompanying objectives) there, it made the corners of the level a focal point.

Next, each team needed a base. Power Failure is a "balanced" map, meaning the terrain and level layout is symmetrical so the two bases were placed at opposite ends of the map. I whipped together a basic bunker, threw in some walls and ta-dah! a base:

Unfortunately, in the midst of all the base-making fun, I managed to slip behind schedule. My goal was to have Power Failure "done" (or, as done as possible until the next testing session) and start on preliminary work for the next map, Fragmentation. Alas, it wasn't meant to be. There's still the powerups and hazard zones to add as well as the Find & Retrieve version of the map to finish. By Monday everything should be complete, atleast that's my tentative "absolutely final, last day" goal.

For the remainder of next week, it's rough draft time for Fragmentation. I'm excited about working on the next map because, unlike with Power Failure, I have a clear idea of how things should look and play. I'm hoping that going in with a concrete design will make the mapmaking process easier and, consequently, faster. Until next time!

August 17 (The Long Road To... Somewhere)

2007-08-17T15:48:00.000-04:00

As I mentioned last week, my goal was to finish up a majority of the art content for Power Failure. This proved to be more than challenging because the level geometry was designed "off the cuff", meaning without any initial concepts or design sketches. What's worse, I really didn't have any kind of vision of what the map architecture should look like, either. All I had to go on was the design doc specs which calls for Power Failure to be a sector of the network where the power supply units are failing. But how do you represent PSUs in a virtual, 3D setting that's meant to be a digital representation of the "computer world?" With that question in mind, I set off to tinker around with 3D World Studio and Constructor.

The first results were pretty unimaginative. Simple boxy geometry that didn't fit the map theme with even worse texturing. Two or three more revisions later and things weren't getting any better. On Wednesday, I decided to scrap everything and started over. That version became a towering coil structure that reminded me, atleast somewhat, of the Tesla Towers in C&C: Red Alert. Perfect for the map theme. Some simple texturing got things moving and I ended up with my Power Supply geometry. There's still some detail work to do and some texture mapping errors but the design fits and I'm pretty happy with it so far.

Failing power supply units

As for the GUI revision, some leaps and bounds were made there as well. The game interface received some tweaks and the play HUD was simplified and made sleeker.

For next week, Power Failure is getting finalized (!), rough work on the next map (Fragmentation) is starting and, as always, bug patrol will be in full-force.

August 10 (Revising the Revision of my Vision)

2007-08-10T16:19:00.000-04:00

Since the last update, there's been more game design changes, the third revision on the interface graphics continued and some good progress on the Power Failure map.

First off, the new design changes. It's amazing how tugging at one thread of a game's design can unravel the whole ball of twine. That pretty well sums up what's happened over the last two weeks and, unfortunately, I can't say I'm surprised (or that I regret it!).

After pulling out the no health/no death system all that remained of the original bumpercar prototype game was the punting system. "Punting" described the effect forcebolts had on vehicles. When hit by a forcebolt, a player would be flung in the direction of the forcebolt (or away from the attacking player). This was essentially the "bumping" mechanic of the original bumpercar game. By punting people with forcebolts, you could move them out of position/away from objectives and powerups. Once again, it was something which made sense originally but was completely out of place in the new design. With forcebolts being able to finally destroy enemies, the last thing you wanted to see in combat was your target being pushed away from you thereby being given an opportunity to escape and recharge.

Once the punting system was removed, the game instantly felt more solid. Combat now meets player expectations. All in all, the shift in design represents about two days worth of work but it was well worth it.

As for the third revision of the interface, it's still not complete yet but I like what I'm seeing so far. This revision is mostly minor tweaks but the sum of the effort is a more polished, cohesive look. With this revision, I hope to improve the look and feel of the interface. Most importantly, I want to have the GUI "fit" the futuristic/digital nature of the game without being distracting. The goal is something neat and clean but not boring.

Lastly, Power Failure. What a bear this thing has become, mainly because the overall philosophy behind level design wasn't well defined. Fleshing out a level without really knowing how it should look is a big no-no. I've since corrected that mistake by updating the design doc with details on how each map should look, feel and play. As a result, Power Failure is back on track. The terrain is all but finished and some preliminary structures and objectives are in place. There's still a sizable amount of work to be done on it but things are moving right along.

Next week, my goal is to complete the GUI revision, finish up some art content for Power Failure and fix whatever bugs crop up in the process. Until next week!

August 3 (We Can Rebuild Him. We Have the Technology.)

2007-08-03T14:25:00.000-04:00

Yet another fun-filled week gone by. There's been some major progress this week so let's jump right in.

I spent a few hours last week watching recordings of recent testing sessions trying to pickup on any bugs or unexpected behavior. During the playback I noticed most players had a very aggressive playstyle, often teaming up with other players on their team against a single enemy player and punting them around the level until everyone involved was out of energy. It was a true revelation and something I had been completely oblivious to in the past. What it meant was that some part of the game wasn't fulfilling player expectations. Players expected to be able to destroy opponents and the "no health/no death" system was prohibiting that. While playing may have been a fun experience, not being able to definitively "win" against an enemy by blowing up their hovertank was going against the grain of what people expected.

Once I realized this, I knew the time had come to rip out the "no deaths" system. I considered it a gameplay staple but it was really a relic left over from the original design that called for Bit Battles to be little more than a multiplayer bumpercar game. In the setting of that original idea, removing any concept of damage, health or lives made sense but the game has come a long way since then. Bit Battles is now a more serious affair, far closer to a full-fledged vehicular combat game than a bumpercar simulator. So, after some pretty significant reworking, the game now has a concept of damage and, not surprisingly, it just feels right. Being able to blow up an enemy player and watch as their hovertank explodes into a burning pile of rubble is just plain fun. It was a much needed change that should have been implemented sooner but wasn't due to my own stubborness. Lesson learned.

After the damage system was implemented, it was time for a couple quality-of-life changes:

First, capturing a Capture Pylon has always captured nearby powerups as well, thereby giving that team exclusive access to them. This acts as an extra incentive for teams to dig in defensively and really protect their pylons; letting them fall back into enemy hands means losing access to certain powerups which might change the outcome of the game. But it wasn't easy to tell which team controlled which powerup as they're often near multiple Capture Pylons. Players would routinely complain about not being able to grab a powerup only to be told that their team doesn't have access to them. This was remedied by giving powerups a capture "aura" that glows green or red, depending on which of the two teams controls it. Powerups, like Capture Pylons, start off as being neutral which means anyone can grab one. In this state, the aura is hidden. Once a pylon is captured, the aura is displayed and it's immediately clear whether or not you can take it or not. Here's a few screenshots to show off the effect:

On the left you can see a neutral Capture Pylon and powerup. On the right, a opportunistic Red player captured the Capture Pylon and his team now has access to the nearby powerups (denoted by the glowing red aura).

Next, The waypoint HUD was revamped. Previously I mentioned being worried about potential cheating scenarios and, as a result, made waypoints point to static areas in the world rather than moving objects. Now, waypoints can target players or other objects without compromising security. Waypoints can now be created dynamically by game events and be sent to individual clients, entire teams or the entire server. As an example, once a player picks up a Nanite object, the game automatically waypoints that player for everyone on his/her team which makes finding and escorting important friendly players much easier. These small changes have really paid off by solving the navigation issues in the game. As a result of the improved functionality, the radar and compass HUD were deemed redundant and removed.

Finally, the process of reworking art assets continued. The new terrain and structure textures were accompanied by code changes which greatly increased texture crispness as well as helped show off the new details. The improvement has been pretty dramatic thus far but it's a bit too early to show off. Hopefully next week I'll have some spiffy new screenshots to show.

For the week ahead, work continues on Power Failure, GUI graphics are getting reworked and, as always, bugs will be squashed.

Until next time, have a good one and God bless!

July 25 (It's All in the Look)

2007-07-25T14:10:00.001-04:00

Last week was focused on continuing to rough out the Power Failure map. It's a long process of going from design to fully functioning level but progress is definitely being made. There's also been a couple important revelations a long the way.

First, Bit Battles has progressed significantly beyond the initial design but the overall look of the game hasn't. Many of the textures still in use were quick mockups made during the prototyping phase designed to test whether the TRON look could be done convincingly and in a unique way. They were never meant to be permanent additions but, unfortunately, they've fallen into that role over the past few months.

So, the long process of refining and, in many cases, simply redoing each texture has begun. Many of the changes are fairly minor (like small circuitry details on the textures for level geometry) but they create some pretty drastic results. As a result, the overall atmosphere of the game seems to have gotten a bit darker, more serious, perhaps even sinister. Surprisingly, this seems to go quite well with the storyline so I'm pleased with the results thus far.

Level geometry is in a similar state. The firewalls from The Breach, for example, were simply fill-ins until something better could be made. They don't do much to instill the idea that this sector is one where defenses are down, nor do they really fit the "firewall" description. So, in addition to the texture work, I'm going back and changing geometry, adding extra details, etc. It's a slow process as well but I'll get there eventually!

Secondly, the overall idea for level design hasn't been well-defined. Nowhere is this more evident than when comparing The Breach and Power Failure. The Breach was made early on and the smooth, flowing terrain is a stark contrast to the harsh, jutting terrain in Power Failure. What's really interesting is that The Breach works better from a gameplay perspective (the smooth terrain is ideal for the hovertanks to skim across) but Power Failure has a "cooler" digital/circuit board look that's not well-suited to the game.

Based on my experience with other games, I'm favoring the functional design of The Breach over the "coolness" of Power Failure. Some of the best (most fun) maps in TRIBES, for example, were the simpler ones. Of course, that's not to say that the two designs are mutually exclusive. My hope is that the second pass of Power Failure will result in a map that both looks awesome and is solid from a gameplay perspective. We'll see how it goes!

As for the upcoming week, I'll be slaving away on the next round of texture refinements and further developing Power Failure. My hope is that by the middle of August the map will be complete and I can move on to the next one: Fragmentation. Until next time!

July 19 (Waypoints and Power Failure)

2007-07-19T10:56:00.000-04:00

This week I continued implementing player feedback. First up, the waypoint system. It was surprisingly simple to get in as much of it had already been done by the object name HUD. Some simple code to iterate through the map to find all waypoint markers, create waypoints at those markers and project them on to the screen were all that was required to get it up and running. There's still a few possible additions to make (i.e. team-specific waypoints) but I'm pleased with how things turned out.

Here's a couple screenshots showing a waypoint from the Green team perspective [Warning: Hi-res images!]:

The next big thing was working on the next map: Power Failure. The concept is a sector in the network where the power supply has gone awry. The design calls for large structures representing conduits, powerlines, etc. hanging everywhere. In the center, atop a large mountain sits the failing Power Supply Unit and, conveniently enough, an objective. Each team's base sits on either side of the mountain connected directly by a large tunnel that cuts through the mountain. Near each base is another objective that will quickly be taken by the two teams. The key to winning, however, will be controlling the PSU objective.

I have some nifty effects planned for the map but it's a bit too early yet to show them off. I'm hoping they turn out as well as I imagine.

For the week ahead, my focus will be on continuing to flesh out the Power Failure map as well as fixing a few bugs that cropped up recently.

July 11 (Getting Fanatical)

2007-07-11T12:51:00.000-04:00

As you can see, the blog template has gotten some major improvements. If you haven't noticed, the layout now corresponds to the Fanatical Games website located: here. Be sure to check it out. There's some nifty Bit Battles info, screenshots, etc. over there. Anyway, on to the development news.

This week was focused on getting some of the feedback from testers implemented. The suggestions were all quality-of-life stuff, namely:

Put some kind of indicator on the Nanite Reclaimers to show when a Nanite has been captured
Put some kind of indicator to show where a player needs to go to complete an objective

What I realized is that all of the suggestions boiled down to: navigating the maps is hard because it's easy to get lost. I even found myself getting lost occasionally (I nearly took a Nanite back to the enemy base!). What's interesting is this is something I was concerned about months ago. It was the reason I implemented a radar/compass system. My hope was that by giving players some indication of what was around them, it would make finding objectives easier. Unfortunately, it wasn't a very good solution. As mentioned, it was stilll very easy to get lost and finding objectives was still fairly difficult.

With that in mind, I set about making map navigation easier and more intuitive. The solution I settled upon was on-screen waypoints. The system mimics the one found in Tribes 2 and the Battlefield series; essentially, it's HUD icons that point to certain locations. There are a couple of differences, though. First, mappers, rather than players, are responsible for defining where the waypoints are. Secondly, the waypoints are static. They cannot move and cannot point to moving objects, only "areas" in the world. These differences are small but important. Giving mappers control over waypoint placement was done to avoid possible cheating scenarios (i.e. players creating waypoints to enemy players, objectives, etc.). Having the waypoints point to fixed locations also reduces the impact on "hide-and-seek" gametypes (like Find & Retrieve where the entire point is to actually find hidden objectives).

There's still some work to be done on it but the progress has been good. Hopefully next week I'll have some screenshots showing it off.

July 4 (Kickin' Butt, Chewin' Gum)

2007-07-04T14:12:00.000-04:00

Phew! What a week it's been for Bit Battles. At the end of the last update, I mentioned beginning work on rewriting the Find & Retrieve gametype. As that was progressing, I decided to raise the stakes a bit and give myself a deadline: by Monday, I wanted to release a test version to the public. The test version needed to have both the Capture & Hold and Find & Retrieve modes as well as a map for each. It seemed like a reasonable enough goal but little did I know the result would be a franticly paced development marathon.

Early Thursday morning I decided to write up a "MUST DO" todo list. I included things that needed to be finished before the online test. The list looked something similar to:

Get F&R gametype done
Get C&H_TheBreach and F&R_TheBreach maps done
Get new Battle Information screen done
Get warmup mode working
Get voting working
Get administrative tools working

As I mentioned, it seemed reasonable enough at the time. What I didn't realize, though, is there were a ton of bugs lurking just beneath the surface that would take valuable time to fix on top of the time spent actually implementing entirely new functionality (like the voting and admin options).

The remainder of Thursday and Friday was spent getting the F&R gametype rewritten, tested and fixed. The design was all there but actually getting it to work proved time consuming. Little implementation details like the physics for throwing Nanites (Nanites being the F&R objectives players must collect) took a while to rough out and get working properly.

Saturday and Sunday were spent doing GUI work. Boring but necessary stuff that I try to avoid whenever possible. The new Battle Information screen (which is responsible for showing player and team scores, voting and admin features, etc.) was a real beast. So much functionality had to be packed into it that a complete redesign was needed.

Accompanying the new Battle Information interface was some major backend work: voting and server administration. Players needed to be able to vote to change the map, enable/disable Warmup Mode, kick and even ban players. Server Admins needed to be able to do all of those things including switching player's teams and logging in. Once again, tiny implementation details proved troublesome (like sending a listing of all available maps to the clients for voting purposes).

Monday was the real crunch day. Two versions of the "The Breach" map still needed to be completed, a few bugs needed to be squashed and the game needed to be tested and packaged, all before the official late night testing time. Thankfully, everything worked out and the game was sent out to the group. Unfortunately, several couldn't make it so the testing period was extended for a week to accommodate everyone.

On Tuesday, I released an updated version of the game that solved a slew of issues discovered from the previous day. Most of the bugs were minor fixes but they all negatively impacted server stability. Fixing them resulted in the game running surprisingly well given the early alpha state.

Fast-foward a bit to last night when the first "real" testing session occurred. Myself and two other players joined the game and played through fifteen (!) rounds of Capture & Hold and Find & Retrieve. I gleaned some really useful feedback and found more bugs but most importantly, discovered that the game is indeed fun; fun enough that a group of hardcore-gamers-turned-adults (my target market!) spent nearly 3 hours playing the same map without realizing it. Seeing the game in action, with other, real players playing it was a great experience. It's made the last few months of effort more than worth it and I'm looking forward to the next testing session.

This week I'll be focusing on getting some of the feedback implemented. Most are simple "quality of life" changes to make map navigation or scoring easier to handle. Bugs are, of course, top priority but none seem very difficult to solve. Until next time!

June 27 (Profiling Performance, Please!)

2007-06-27T23:48:00.000-04:00

The past week was a productive one. The Find & Retrieve gametype was rewritten, a slew of GUI work was completed and I did some early (but important!) performance profiling for the game.

The F&R gametype was a fairly easy piece of work thanks to a straightforward design. The design doc called for the basics of a Find & Retrieve mode: an object to be found/collected by players and a "collector" where players could dump these objects. What I ended up with were Nanites (the object to be collected) and Nanite Reclaimers (the collectors). Going in, I didn't want the F&R mode to degenerate into a "find the Nanites faster than the other team" game. I didn't want the ultimate strategy to simply be put everyone on offense and grab as many Nanites as possible before the other team while avoiding combat if at all possible. Instead, I wanted the gametype to reinforce player-vs-player battles; to create "hotspots" around Nanites where players would fight over it. To accomplish that, the design called for several things:

Many Nanites to be placed on each map but in strategic locations (i.e. one might be near each team's base while another might be in the center of the map; creating two "easy" grabs and one "hotspot")
Giving players the ability to "throw" Nanites to other team members (or possibly have them intercepted by enemies)
Being hit by a forcebolt to cause the player to drop a Nanite (assuming they're carrying one)

I also wanted F&R to be as balanced as the Capture & Hold gametype if possible. That meant making both offense and defense important. To reinforce this concept, the design called for allowing captured Nanites to be grabbed by enemy players. If a team wants to be successful at F&R, some players will need to guard the captured Nanites/Nanite Reclaimers (play defense) while others will need to seek out the remaining Nanites (play offense).

Some rather boring but necessary GUI work was also completed. Namely, the map loading screen and the end map screen. The loading dialog now fits with the rest of the interface and displays some important server and map information. The end game interface shows player and team scores, which map was being played, which team won and the time it took to win. As I said, pretty boring stuff really but it's now (thankfully!) checked off of the todo list.

And lastly, the performance profiling. Performance in the game has never been bad (always above 30 FPS at 1280 x 1024 x 32 resolution on a mid-high end PC) but I have always known it could be better, just not sure how. Thanks to Torque's nifty profiling system, I quickly found out: shadows. With a full (16 player) team of hovertanks on the map, framerate dropped to below 30 which was unacceptable. The profiler showed that nearly 18% of the total game time was being spent inside the dynamic shadow renderer. After a couple quick searches, I happened across a very nifty resource that overhauls the system making use of some newer hardware. Porting it over to my version of TGE was a bit of a pain but once done, the profiler showed the new shadow code was taking less than 1% of the total game time on the same map! Such a massive improvement resulted in an extra 9-10 frames per second which was a pleasant surprise. There's still a few kinks to work out and some cleanup to be done but nothing gamebreaking.

As for the week ahead, Lord willing, I'll be working on getting the first map started and finishing some more GUI stuff. Until next time!

June 20 (Its Continuing Mission...)

2007-06-20T14:56:00.000-04:00

The continuing mission is, of course, to get things done! For the purposes of the Dream Game, Inc. "Dream Game in a Year" competition I spent this past week getting the design document updated and sent in. Certain parts of it were slightly outdated and others needed to be filled in with concrete ideas. Getting the design document up to speed and "finalized" forced me to think about what the next few months of development time will be spent on as well as reminding me of all the little details required to bring everything together.

With the amount of time left in the competition, I took a close look at what was finished and what wasn't and estimated the amount of time needed to get everything done (with polish, of course!). Thankfully, only a couple areas needed to be scaled back. One such area was the map count. My original plan for seven maps has been reduced to six. I estimated that each map would take approximately one month to completely finish -- that includes creating art and sound assets, editing the map itself, doing early tests for balance, etc. Assuming serious map development begins in July, that would put me around January or February before all six were completed. Given that a beta status must be reached no later than March 1, that seems to be cutting it as close as I would want.

Finalizing the design doc also meant dealing with things on the backburner. As an example, the offline training/tutorial missions were something I had been putting off for a while now. Between flipflopping between an AI-intensive, multi-mission "campaign" to a simple dialog-driven help screen, I really had no idea what I wanted to do with them. What I did know, however, is that teaching newcomers how to play Bit Battles in a simple but fun manner was all-important. I also realized that time and resource constraints meant developing a proper singleplayer campaign was out of the question. In the end, I decided on a blend of the two that, hopefully, will be both fun and easy to create. More on this as it progresses.

The remainder of the week will be focused on tackling the Find & Retrieve gametype. It's a fairly big project but all gametypes need to be finished before the tutorial mode can be created. One domino at a time! Engage!

June 13 (Iteration Wins Again)

2007-06-13T01:10:00.001-04:00

It's amazing what a week of revision can do. I spent the past week going over the art assets created thus far and tweaking, fixing and outright redoing them. The really exciting part is doing a comparison between the "first draft" and the "second draft." I suppose pictures speak louder than words, so here's a few:

Remember the early GUI posted last week? It now looks like so:

And that test level? Here's what it looks like now. Pictured are the new Anchor Zone (gray arrows), Catapult Zone (orange arrows), Leech Zone (blue field), the new Capture Pylon and the final(!) hovertank (skinned in the Red team texture).

There's still a long way to go but things are progressing nicely.

Progress Backlog - June 8 (Gooey GUI)

2007-06-13T00:53:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of June 2007.]

This week I focused on getting the GUI up and running. This meant creating custom interface graphics as well as fleshing out the required code. As usual, I'm using an evolutionary approach.

One of the original concepts I created involved a flashy Windows-esque desktop scene but the "folder" icons would link to important dialogs (i.e. clicking the 'Multiplayer' folder would bring up the server browser). This fits with the digital-ish theme of Bit Battles but in the end it was simply overcomplicated.

I finally settled on a much simpler idea with clear buttons on a nice background. It's still a very rough design but it's a good first step:

Progress Backlog - May 31 (Programmer... Art?)

2007-06-13T00:40:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of May 2007.]

Creating prefab objects for the maps and fleshing out the actual maps themselves continues (and will continue for the foreseeable future). I'm taking an iterative approach to the art assets as well. Each iteration seems to feature more geometry detail, better textures, etc. so why not?

Anyway, here's a few early screenshots from Bit Battles. Keep in mind, these are VERY early and feature roughed out programmer art. There's some contract work in the pipeline that will greatly improve the visuals but at such an early state it's not something I'm concerned about.

This is a shot from inside the test map. You can see the Red team hovertank, a Capture Pylon, one of the powerups and a hazard zone (the deadly Leech Zone which drains all energy from those who enter it).

And here we have an overview of the test level. Another Capture Pylon, some powerups, several Leech Zones and the Catapult Zone which punts players in the air.

Progress Backlog - May 25 (Tricksy Mapses)

2007-06-13T00:04:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of May 2007.]

Continuing where last week left off, I roughed out details for 3 of the 7 maps. The overall plan is to have each map tie into the storyline by taking place in a specific (yet stylized) sector inside the computer network. An an example, one map might take place inside a corrupted or infected section of the network while another might take place on a fragmented portion of a hard drive. These ideas are the themes of each map and, as I said before, gives a fairly clear list of what assets are required to pull it off.

With this in mind, I dug in and started producing the early content required for the maps. It was a nice change of pace but also showed how time consuming content creation actually is. The process of modeling and texturing five prefabs took around two days (granted, some of this time was spent learning the modeler). Luckily, it looks as though many of the textures will be reusable which should cut down on the workload a bit.

Hoping to have something to show next time!

Progress Backlog - May 15 (I Want You to Write... a Theme)

2007-06-12T23:42:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of May 2007.]

This week saw me still working on designing the world of Bit Battles. It became apparent to me that in the interest of time (and perhaps my sanity), designing/modeling/texturing a bunch of generic prefabs might not be the best way to go. So, I decided to give each map (of which I'm planning on releasing with seven total) a central "theme" or gimmick that makes it stand out. This gives me a clear picture of what type of textures and objects will be required for each map.

I'm also borrowing an idea from Tribes: Vengeance (the poor beast) and planning my own sort of "universal map" system whereby maps adapt to the current gametype. It probably won't end up as sophisticated as the system in T:V but I like the idea of creating seven "base" maps and being able to play both gametypes on each.

The next step will be to rough out ideas for each of the seven maps but that's a story for next week.

Progress Backlog - May 9 (Color Coordinated)

2007-06-12T16:57:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of May 2007.]

First thing on my list this week (referencing my trusty ToDo.txt): get the world environment designed. This meant looking at tons of reference pics all while thinking about the context in which architecture and the environment would be used in the game and (simple) ways in which to make the world look interesting.

The role architecture plays in the game is important; certain types of structures will hinder gameplay while others can further it along. As an example, designing a large tower that leads down into a vast underground chamber is great for an FPS but in a game as fast-paced as Bit Battles where being free to move around is key, closed in spaces and tight corridors are not the best option. In the end, I opted for structures that either aided movement or provided cover. This meant things like bridges, tunnels, barricades, etc. were fair game but boxed in buildings, etc. were off limits.

During this design process, I also started paying close attention to color and how it could be used to denote context or use. Eventually the idea of both shape AND color denoting an object's context/use spread to everything in the game world. I designed the powerup textures to have uniquely-colored textures, objectives (Capture Pylons, etc.) would be textured with a set of uniquely-colored textures, etc. In the end, this meant that players would be able to look at an object in the world and instantly tell what it was (objective, powerup, friendly or enemy player, etc.) and what should be done with it (capture it, grab it, shoot it, etc.). Simple idea but it's one that should hopefully make learning the game easier for new players.

Speaking of which, ease of use is something I'm growing more and more concerned about. The original idea behind Bit Battles (multiplayer bumpercars) was simple; most people know what bumpercars are, most know the objective when you're driving them (ramming people) so learning how to play would most likely be a fairly easy, if not natural, process. But tack on things like teams, weapons, objectives and so on and you've complicated things beyond the original idea. This isn't a bad thing, mind you, but it does require me to pay attention to the fact that things are indeed growing more complicated with each iterative prototype.

Progress Backlog - May 4 (I Dub Thee...)

2007-06-12T16:27:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of May 2007.]

Amidst the hustle and bustle of prototyping, I neglected to come up with a name for my little project. Brainstorming names for a game in the prototype stage was a little odd but I refused to call it "my game" any longer. It had to be something that was relevant, something that represented what was taking place inside the game world and unique (meaning not some archaic reference to an ancient SNES title). I considered things like ByteWars (taken), BitWars (too serious), Circuit Breakers (nope) but eventually settled on Bit Battles. It just seemed to "fit."

With the name settled, I moved on to setting up a proper directory structure and moving away from the starter.fps template. Starting fresh was important because the starter.fps folder contained a lot of resources (code, art, sound, etc.) that simply wasn't needed for Bit Battles. It was also quickly becoming a cluttered mess of test files. Luckily, this was a simple task as there weren't very many assets to move over and the early code was going to be rewritten later on anyway.

Fresh folder created, I made one of my infamous "ToDo" lists which, unsurprisingly, is a simple .txt document that sits on my desktop. My todo lists tend to be fairly long-range lists mixed with ramblings about needed features, bugs, etc but it's an exciting step because it means I'm past the prototype phase and moving into actual development!

Progress Backlog - April 24 (Bits, Bytes and Hazards)

2007-06-12T16:06:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of April 2007.]

I continued to build upon the early prototype this week with the addition of hazard zones. The design required that the hazard zones be small sections in the world that players would want to avoid. The three types of hazard zones I designed would have a negative effect on a player but would not be so debilitating that players would become frustrated if they entered one. Ideally, I wanted to create another "mini-game" (akin to the management of hovertank energy and forcebolt charge status) whereby players would try to "forcebolt" enemies into the hazards. Doing so might allow a powerup to be collected or objective to be completed. Essentially add on the "game" of staying in position.

Speaking of which, objectives were the next (and last) thing to go in to the prototype. I began by constructing a simple Capture and Hold gametype. "Capture Pylons" were scattered around the map and, by running into them, players would capture them for their team. Doing so would presumably award the team a point and advance the team's goal of winning. In true Starsiege: TRIBES fashion, these Capture Pylons were flip flop switches, meaning teams could capture and recapture them. By doing so, the need for both a good offense (to seek out and conquer the pylons) and a good defense (to guard the ones currently controlled) would be required.

The Find and Retrieve gametype was also roughly fleshed out in the design doc but implementing it would have to wait until a later date...

Progress Backlog - April 17 (Of Prototypes and Forcebolts)

2007-06-12T15:18:00.002-04:00

[The following posts are backlogs of progress which occurred throughout the month of April 2007.]

The design doc was further fleshed out this week. Descriptions of the player-to-player interaction, objectives, powerups, etc. were jotted down. Fairly boring stuff but committing my ideas to paper helped clear up some early inconsistencies and hopefully avoid problems down the road.

The big focus this week is on prototyping core ideas. Working with TGE is a real joy as so much functionality is already in the engine. Within minutes I had a simple hovercraft skimming over the surface of a terrain. It did take some fairly extensive research into the meaning of certain hovervehicle datablock values, though. The one provided on the TDN creates a hovervehicle that is ridiculously hard to control and just "unfun" but after some major tweaking, I managed to get something that controls similar to the original HOVER hovercraft.

With that done, I added another vehicle to test vehicle-to-vehicle ramming and was fairly disappointed by the results. While I seemed to have avoided the oft-talked about problems with TGE rigid body physics (crashes, sticking, etc.) the engine seemed to have sporadic trouble registering which vehicle rammed which. Occasionally I would ram another vehicle only to find myself being punted backwards while the other hovercraft remained in place. Imagine throwing a rubber ball at a boulder for a good indication of what happened.

What I found, though, was that even when the collision registered correctly and things worked as intended, ramming just wasn't much fun. Both hovervehicles would recoil violently from the collision which threw the camera for a loop (probably resulting in some nasty dizziness for those with vertigo) and really just wasn't satisfying at all. So, I opted out of fixing the problem and, instead, adjusted the design to accommodate better player-to-player interactions.

I came up with "forcebolts", energized projectiles that are fired from the "turret" of the hovercraft (or now, hovertank, I suppose). When a forcebolt collides with a hovertank, it punts it away. Collisions between projectiles and vehicles registered correctly, the problem of recoiling was gone and hitting someone with a forcebolt only to see them fly backwards was just downright fun.

The concept of giving players a weapon offered some interesting gameplay options. The hovertank weapon could be "charged" (by holding the fire button down for longer periods of time) thereby causing the forcebolt to travel faster, punt people farther, etc. It also meant hovertanks now needed an energy supply. Dodging became even more important and the dual "mini-game" of managing energy and charge status became crucial. Players that mastered these two tasks would do better than those that hadn't.

The final iterative step for the week was the addition of powerups. The design called for five types of powerups that do nifty things like give invisibility, super speed, shields the player, etc. Designing the powerups meant coming up with creative, fun and balanced ways of rewarding players who took the initiative to grab one. I didn't want any single powerup to become a "god mode" nor did I want them to be so bland that no one bothered using them. In order to accomplish this, each one was made "single-use" meaning once it was used, the player had to go collect another and only one powerup could be carried at once.

While there were still no objectives to be completed, no concept of teams, etc. the final prototype represented fairly well what the game would become and, thankfully, the core ideas were fun...

Progress Backlog - April 10 (Designing the Doc)

2007-06-12T14:08:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of April 2007.]

Creating design documents is something I rarely enjoy doing. I prefer an evolutionary, iterative design approach that relies heavily on early prototypes. It's just my style, I suppose. Yet for this game, I'm taking a different route and documenting as many "core ideas" as possible. The advantage of having an earlier game be the main source of inspiration is that you can actually use it as a prototype; you can quickly see what ideas were implemented and which ones weren't and why while finding ways to innovate yourself away from that game; essentially creating something that's "influenced by but different than" what you've been playing.

The design for this game is fairly straightforward as a result of having HOVER to play around with and my own limitations (time, etc.) are honing it even further. I came up with a list of "must-haves":
-hovercraft that interact with one another (ramming?)
-collectible powerups that provide fun advantages
-multiple teams of real players (multiplayer-only)
-objectives to complete (flags to capture, points to hold, etc.)

Right off the bat, I wanted the design doc to describe the world and answer the "where's, why's and how's" via the storyline. Details about gameplay-specific items (powerups, objectives, etc.) would be roughed out later.

First on the todo list was thinking of a world in which the game would take place. My selection was also narrowed by my own limitations. Setting the game in some post-apocalyptic ultra realistic crumbling city, while probably really interesting, would set me up for failure. The sheer amount of texture work alone would be overwhelming. With this in mind, I thought of locations that would be both intriguing but relatively easy to create. And then I remembered TRON 2.0. The vibrant world in that game just oozed awesome yet the textures and geometry were fairly simplistic (two-toned squares, highlighted outlines, etc.). I had the basis for my setting.

It was then on to fashioning a storyline to tie things together. What were the vehicles players piloted? Why were players piloting them in the first place? Why were they forming teams? What was the source of the competition between teams? Where was all of this taking place? Answering these questions in a believable way filled in a significant portion of the storyline. The details and "polish" could be added later...

Progress Backlog - April 4 (The Next Game Begins)

2007-06-12T13:24:00.000-04:00

[The following posts are backlogs of progress which occurred throughout the month of April 2007.]

Starting a new game is always an exciting process but, through the years, I've learned to be somewhat leery of it as well. It's in this early, formative time that ambition is necessary but, uncontrolled, it quickly leads to trouble down the road. Looking back, the past projects of mine which ended in... less than spectacular results were a direct result of overly ambitious designs. Finding a balance between envelope-pushing ideas while adhering to what can realistically be accomplished given a finite amount of time, resources and knowledge is key to ensuring a game not only gets off the runway but doesn't come plummeting back to earth soon afterwards.

Going further, it's vastly important to know (most likely through failure) one's limitation and consider them while brainstorming ideas for a new game. It's great to come up with a design for the next [WoW/Halo/Oblivion/etc.] killer with all of the sparkly bells-and-whistles that go along with that but if you're struggling to model a box, you're already off to a bad start. This may seem like a common sense, "Duh!" moment but it still needs to be said.

So, with all of that in mind, I began the process of thinking up ideas for my "Next Game." An odd source of inspiration this time around came from my Windows 95 disc. As I was going through an old box of software, I came across the CD, popped it in and found HOVER. Graphically, the game is pretty poor but it does have some fun gameplay that would have benefited significantly from multiplayer.

After playing HOVER, a simple game idea came to mind: multiplayer bumpercars with objective-based gametypes. Ramming into people with hovercraft in spectacular 3D while attempting to complete team objectives sounded like fun! Not only that but the game could be prototyped quickly (thanks to Torque) and the content (meaning art and sound) requirements would be fairly low. The projected sounded like something I could really dig into and be excited about working on.

And so the "Next Game" began...