• entries
37
52
• views
42597

## Viewback - A Video Game Design Tool

Viewback is a tool that helps game designers conduct usability play tests. It forwards the debug information from your game to your wireless device, where you can see it and the player can't. Now you can diagnose problems with the game while your playtester enjoys her experience. You can see changes to internal game state and send commands to the game in real time.

You can watch this video to get an idea of how it works:

[media]
[/media]

The Viewback server is written in C and can be easily integrated into any game engine. It uses a permissive MIT license, avoids blocking networking calls, and uses only a few hundred bytes of memory. The server compiles on any C compiler with no dependencies, and the monitor is available for Windows and Android, with OSX and iOS coming soon.

Since Viewback is written in C it can be used in just about any game engine environment. Any engine written in C or C++ (Id Tech engines, Unreal, Source) can use Viewback with no extra effort. Users of engines written in Java or C# (Unity, Minecraft) can either write language bindings or implement the Viewback network protocol on their own.

This repository contains the header and source code for the Viewback server, which will typically be integrated into your game's client, if your game is multiplayer. It looks like this:

# Installation Instructions

First, download the source code from the GitHub page and copy all files in the server directory to a directory inside your source tree. If you're familiar with git, you can use a git submodule for this purpose. Then add viewback.cpp and viewback_util.cpp to your project files. In whichever files you want to use Viewback, add at the top:#include "viewback_util.h"
Now you are ready to implement the API.

# Sample Code

This code uses the vb_util interface, which handles memory allocations for you. If you care about how Viewback manages memory, see viewback.h for an interface that allows you to allocate the memory that Viewback uses.#include "viewback_util.h"vb_util_initialize(); // This is optional.// A "channel" is a stream of data to be sent to the Viewback monitor for display.// Here we create an integer channel called "Health".vb_channel_handle_t health_channel;vb_util_add_channel("Health", VB_DATATYPE_INT, &health_channel);// The name you pass in here will be displayed in the server list on the monitor.vb_util_server_create("My Amazing Game");while (game_running()){ // Call this as many times as you like, but at least once per game frame. vb_server_update(game_time); // You can send data once per frame, or only when the data changes. It's up to you. if (!vb_data_send_int(health_channel, player->GetHealth())) printf("Error sending to Viewback channel\n");}vb_server_shutdown();
At this point you should be ready to use the Viewback monitor to see your data. If you are on the same WiFi network as the Viewback server then the monitor should automatically find the server. If your network is special then you may have to find the IP address and connect manually. Once connected you will asked to select a group to display, and then you'll be able to see your channels.

# Features

Channels

A channel is a stream of data to be sent to the Viewback monitor for display. Each channel has a type, currently supported types are integer, float, or vector. Depending on the type of the vector the data will be displayed in the monitor in a different panel. Floats and ints will be shown in the time display and vectors will be shown in the 2D display.

Groups

A group allows you to organize your channels. You can add a channel to a group and then activate a group to see all of the channels in that group. For example an "Animation" group may contain these channels:

• PlayerYaw
• ViewVector
• PlayerVelocity

while the "PlayerMovement" group would contain

• PlayerVelocity
• JumpButton
• OnGround

A channel can belong to multiple groups or no groups.

Labels

Integer channels are often enumerations - i.e. each value represents a state. These states often have names and looking at the names is nicer than looking at the numbers. So for integer channels you can specify that a certain value has a name, and this name will show up in the monitor instead of the number. For example for the PlayerState channel you may have these labels:

1: Respawning
2: Alive
3: DeathAnimation
4: Spectating

Whenever the channel has the value of "2", the monitor will show the "PlayerState" channel as being "Alive".

Controls

You can specify controls to modify parameters of your game in real time. These controls appear in the monitor and when they are manipulated by the user, the callbacks that you specify will be triggered in the game code. There are currently two types of controls supported.

Buttons

When pressed, a callback function in the game will execute. For example, a "Pause" button could call this function:void viewback_pause_callback(){ Game()->TogglePause();}
Other ideas for buttons:

• Take a screenshot without leaning over your playtester.
• Turn cheats on and off.
• Activate the bug report system.
• Reset the level if your playtester got stuck.

Sliders

When the slider handle is moved a callback in the game will execute. Sliders can specify integer or float values. Some ideas for sliders:

Adjust the difficulty of the game if your playtester is having trouble (or not enough trouble)
Adjust the number of bots in the game
Real-time tuning of a design parameter that you've been trying to get right, like the player run speed or jump height.

Console

If your game has a console, you can forward the console to Viewback. Output from the console will appear in the Viewback monitor and the user can input commands into the monitor which will get forwarded to the game.

Don't have a console in your game? No sweat, you can use the Viewback monitor as your console. Just call the Viewback vb_console_append() function with whatever messages you want to see, and it will show up on the Viewback monitor.

Status

The status string is like the console but it's always visible. New status lines replace old lines and they never scroll off the screen. Use it for things like the framerate, memory used, and how many monsters are currently spawned.

## More Math for Game Developers

Learning math is fun when it helps you design better games. Here are some of the recent videos in my video series, Math for Game Developers.

Delta time and the game loop
The Approach() function
Euler Angles
Cross Products
Ray/box intersection
The Remap() function
Projections

Wow, that's two months worth of videos! It's been pretty crazy as I've been skipping around from topic to topic, but I'm about to start into a series about matrix transformations. I'm really excited about it! Subscribing to my channel or following me on Twitter will keep you up to date with each video as it comes out every week.

## Math for Game Developers Video Series

I've launched a new Youtube series, Math for Game Developers. Each week I'll be showing how to solve a new problem in game development using math, and I'll be building up a math toolkit that you can use to solve any game dev problem.

1. Moving a character with vectors:

2. More moving characters:

3. Finding the distance between two characters:

4. Fast way to compare distances:

5. Speeding up and slowing down characters:

This is very basic stuff, just showing the basics of vector maths, but
eventually I'll be progressing to explaining the math behind more
on solving specific problems that come up in game dev all the time. When
I was just learning game development I couldn't be bothered to learn
any math unless it helped me in some way, so every video I make
solves a problem.

I hope to help out people who are just starting their game dev career so
please let me know if I can improve the videos (other than the low
quality audio, a problem I'm working on) or if you didn't understand
something

## 5 For 5 Bundle Postmortem

This article was originally posted on the author's blog, Think Small

People are fickle with their money. Even 5 bucks can be a huge barrier to getting people to forking over their hard-earned cash. But, if you have a better mousetrap that people want then generally, so long as they know that you exist, they'll beat a wide path to your door. The operating phrase here of course is, "so long as they know that you exist." One of the primary problems that indie game developers face is that people simply don't know that they exist. It's difficult to compete with the marketing and PR departments of half a dozen major publishers, and so one way to push through the clutter is to offer your games at a discount.

In a recent interview Gabe Newell mentioned that he's observed a high price elasticity in game bundles. What this means in non-Economics-major-speak is that when the price of a bundle goes down the demand for a bundle goes up at a disproportionate ratio. So, selling a game for half as much doesn't net twice as much revenue, it for example can net ten times as much revenue. Being a marketing neophyte that I am I decided to listen to the advice of one of the most prominent men in the industry and I put together a game bundle of my own. The result of this was the "5 for 5 Indie Games Bundle" (or perhaps the "Buy Games Not Socks Bundle" as it was also called) which was released on the 22nd of last month and ran through yesterday. This is the final report.

Bundles sold: 3,642
Revenue: $18,094 If you compare that to the revenues of the Humble Bundle then it's a paltry number, clocking in at about 2% of the Humble Bundle's revenues. But given some of the other bundles that I've seen it actually did quite well. All in all I would say that given the type of bundle it was (there was no original pay-what-you-want device to draw it attention) it did fairly well and I'm happy with the results. This being the first bundle I've put together, I learned a few lessons. Here they are, distilled into a neat list for your amicable consumption. Quality is better than quantity. The 5-for-5 bundle began as a slightly different idea; to unite 20 indie games into one bundle for 20 bucks. I first started to do some market research to see how people in the bundle's audience (the core gamer) would respond to a bundle like that and the general reaction was, "I don't know if I could turn that down." That was encouraging and I began to dig a little more. But then, there was also a large contingent that replied, "I don't know how I could have time to play so many games, and$20 is steep even if it's $1 per game." So the bundle was simplified to 10 games for$10 keeping with the "x for x" theme. Even 10 games seemed to be a bit high as I soon realized that the logistics of coordinating ten game developers in a single bundle may prove to be somewhat difficult. I also began to realize that I had to make a tradeoff to get 10 indie games in a bundle - many of them may not fit my target audience, and many of them may not be of the required quality level.

In the end I decided to reduce yet again to 5 games, to keep things simple. Even this proved to be rather complicated, although manageable. I can't say whether the number of games in the bundle is a big influence on sales. On the one hand you could argue that a variety of games helped players pick up a bundle when they wouldn't have otherwise, but on the other hand you could argue that profit per developer goes up with less developers. I don't have that data but I think in the future I'm going to lean towards having less games in my bundles.

People don't like to feel like they are being ripped off.

I hate the idea that someone ever feels like I'm ripping them off. I never want to make a single dollar in this life that isn't honest and worked hard for. But at the beginning of the bundle I figured, "5 pounds? 5 euro? 5 dollars? All basically the same thing!" Not out of greed but just as a result of not thinking it through. I've seen lots of low-price-point items sell for one dollar in the US and one pound in the UK, even though that's not technically the same amount of money. So I didn't think about it much and this turned out to be rather shortsighted, as people grew quite mad. A number of people said, "I'm not buying this ripoff crap," which at first I wrote off to people having an inflated sense of entitlement. But after I fixed it those same people turned around and purchased the bundle. One person who purchased the bundle before the price change asked what I could do about it and I offered him a partial refund, but he passed on that because he just wanted to know that I was being fair. He just wanted to know that I was being honest. Good thing for me, I'm always honest.

People appreciate prompt customer service.

I think that during the bundle the median response time for people emailing me and asking for customer support could be measured in seconds. This is despite getting more than 200 emails due to a logistical error. About 80% of those emails were replied and the issue resolved within a minute of me getting them. The remainder were all resolved within 8 hours, and they only took that long because I was eating, sleeping, or maybe running with my dog. (Come on now, exercise is important!)

The response was clear. At least a dozen people commented on how fast my reply was, or saying, "I think that's the fastest customer service I've ever had." I learned how to do customer service by working at a big corporation having to do support on some of the most buggy software I've ever had to work on. You could say that I learned what not to do working there. The main thing people appreciate is not to have to wait to play the games that they paid for. In the games industry, reputation is critical and customer service is one of the best ways to keep a good reputation. But, it requires having your shit together and knowing how to find and diagnose problems, and having an answer ready for your customer before they email you.

Everything you say is marketing.

I forget where I originally heard this, but it's true. I'm a personable guy and I love engaging the people who play my game to see what they like about it. I very much am motivated by people who enjoy my game. I want people to feel like they can talk to me any time, because I genuinely like to talk to people who enjoy my games. So it's not difficult for me to be personal when replying to customer service emails. It pays off, at least a half dozen people mentioned in their emails that they are thrilled about how personal their support was. People respond very well when they know it's a person on the other side of the line and not a robot.

12 days was too long. 5 or 7 would probably have been the best choice.

If you look at the sales curve, the reasoning for this is clear. Sales drop off pretty starkly after the 4 day mark, after all of the websites that are going to cover you have already done so. In the latter days our sales were stamped out almost completely by other bundles and summer sales. The last 6 days were just a march to the finish with not enough additional sales to justify the extra work.

The 6th game tactic was a failure.

I decided to experiment by adding a sixth game to the bundle midway through. The intention was that just as the traffic to the website would begin to die down, another news flash update would pick it back up again.

This didn't work for what is in retrospect an obvious reason. Websites who had covered the bundle the week before were not going to re-post the news just because one more game was added, and people who had not purchased the bundle were not going to change their mind due to a single game being added. This also caused a load of logistical problems for me that took a lot of sorting out. In the end everything turned out to be fine, but it caused a lot of extra work for me and generally wasn't worth it. That's a shame too since Star-Twine (the 6th game) is a great game and really should have been rolled into the bundle from the beginning.

Marketing alone sucks. Get a professional.

I've been teaching myself the ins and outs of video game marketing for the past year and I can safely now say that I know enough about video game marketing to know that I can't do it. It's just not something that a developer can do. I looked for a year for a way to be able to do it myself, but it just doesn't exist. Even if you had the time to do it, you're competing with the large publishers who have seven digit marketing budgets and they suck all of the air out of the room. This is the only aspect by which I consider myself in competition with other game developers -- in the marketing arena.

Fortunately we were smart enough to hire a PR firm to help us promote this bundle. It was well worth the effort, I think our sales would have been half of what they were without the PR firm, and the difference comes out to be much greater than what we paid.

Bundles are a necessity.

There are many things that are a necessity for indie game developers. Having a quality and fun game is one of them. Having a good demo and video is another. But of course the overlooked one is marketing. It's almost an evil term for many game developers (the poor ones.)

Bundles are a great way to market the game since they get so heavily reported on. They increase the visibility of your game by pairing it with other games that players may know better. It's an important avenue of discovery. Those same players are more likely buy your next game at full price. This bundle was somewhat of an experiment for me to see how effective they were, but given how effective it's been I'm going to fold them into a regular part of my long-term plan.

Having an attractive "theme" worked.

I'm really an entertainer at heart. I didn't learn to program games because I like programming or computers, but more because I like to see people having fun with the things I create. As such I'm always looking for ways to tickle people's brains. Fortunately for me that's also a great way to sell bundles. As a group we came up with a theme for the bundle, "What can you buy with five bucks?" the first prospective item being a new pair of socks. Going on from there I picked up the domain name buygamesnotsocks.com and it became the "Buy Games Not Socks" bundle. People responded quite strongly to this. Someone made a #whoneedssocks hashtag on Twitter. One person claimed that instead of buying socks you could print out game screenshots and tape them to your feet. People seemed to enjoy the theme and I think it helped the bundle get re-tweeted a lot. A great deal of our traffic and sales came from Twitter and Facebook, and other social venues. Without a consistent theme I think it would have been much less.

The price was not too low.

Cliff Harris (maker of Gratuitous Space Battles) is constantly complaining on his blog about the ever-dropping price of video games. For the most part, he is right. A week or two before we launched our bundle, he made this post on his blog, bemoaning another bundle which had just come out which was selling 6 games for $5. Personally I think he was just mad that they had undercut his own bundle which was selling for$30. But, even so I think he's wrong.

Cliff posted on his twitter that he had made about $600 from his portion of the bundle, which means that in total (since there were 5 games) the bundle probably made about$3000 during its run. But the 5-for-5 bundle made that amount inside the first 24 hours. Because of the extensive press coverage we were able to reach out to a large group who would never have purchased these games otherwise, and there's also the residual benefits of increased exposure. \$5 is about what Windows users paid on average for the Humble Bundle. Yes, it's true that if we had sold the same amount of copies for four times as much then we would have made four times more, but I think we would have sold ten times as many less bundles and made less money overall.

In his post, Cliff argues about the "race-to-the-bottom" pricing syndrome that so many games suffer from and in many aspects (AppStore market, anyone?) he is correct. But I don't think indie games are suffering from this problem, and it doesn't apply to these five games because now that the sale is over, the games have all returned to full price.

This is something I underestimated greatly. We were only able to provide Steam keys for one of our games, although we did provide Desura keys for all of them. I know that people have an aversion to buying things that can go poof at any time. This is why business such as OnLive have such a difficult time convincing core gamers to use their services. Many core gamers dislike the idea of paying for something and not owning it outright and forever. So, when presented with games that can't be redeemed on some kind of download service, these people simply pass on the opportunity. It's not even worth the five dollars to those people. This was helped in the latter days of the bundle by making it more clear on the website that the games were redeemable on Steam and Desura.

Many are resistant to buying a game that's not on Steam.

There's not much I could have done about this one. I would love for Digitanks to be on Steam but I'm not quite ready to submit it yet. And other than Digitanks there were four other non-Steam games in the bundle. Even so, I think I lost a lot of sales due to the Steam-centric nature of the average core gamer. It doesn't matter that I think that our collective addiction to Steam is an unhealthy one. It's not my job to be proselytizer of Steam alternatives and also sell my bundle. The next time I do a bundle I'll be putting a larger focus on getting Steam support for all of the games.

Mac/Linux is a huge audience.

If more of our games supported Mac and Linux, I think I would have doubled our sales, easily. Many people asked if the games had Linux and Mac support. Many people expressed their disinclination to purchase the bundle without it. During the sale I toyed around in a virtual machine and got a Linux port of Digitanks halfway working. When I announced this on my twitter, two separate Linux-specific websites announced that the game would soon have a Linux port. (That kind of coverage is odd for me. I'm no Markus Persson, things I say don't usually get reposted as news.)

Linux and Mac users also seem to be a better audience to sell a game to. They are in general more willing to pay for things, and they have a lower quality expectation, which I think is actually to their credit. Linux and Mac users aren't inundated with a flood of games every week, and they paid almost twice as much as Windows users on average during the Humble Bundle. Plus, I love Linux and Mac, I don't see why there shouldn't be a port at this point. I'm making it a primary goal to support those platforms for future versions of Digitanks.

That brings this rather lengthy article to its conclusion. If you have questions or you want to talk about just about anything (especially video games!) I'd love to hear from you. Comment on this article or shoot me an email at [email="jorge@lunarworkshop.com"]jorge@lunarworkshop.com[/email]

## What Cesar Millan Taught Me About Life And Game Development

This is a repost originally from the author's blog, Think Small

About a year ago I went to the adoption shelter and happily brought home a happy little two month old black labrador mix puppy. I'd like to say that I rescued him from a harsh existence chained to someone's back porch, but the truth is that he's never known a hard day in his life. But as a first time dog owner, I confess I had very little idea on how to properly train this new barely-tamed animal I'd caged up in my home. He was militaristic about having fun. He saw everything as either eatable chewable or biteable. He was stubborn enough to start a stubble farm, and I didn't know how to handle it. As such, I turned to America's favorite crutch to educate myself in the proper raising and training of my furry little ball of biting: Television.

Anybody who has an affection for dogs has heard of the self-proclaimed "Dog Whisperer" who appears weekly on the National Geographic channel, claiming to be not a dog trainer but a dog "psychologist." His ways are odd and often awkward, but he gets results pretty quickly. But what I grew to like about Cesar wasn't what he taught me about how to deal with my high-energy dog, but rather what he taught me about how to deal with people, and how to approach situations. After a while I found myself applying these things not just to dogs but to life in general, including my game development practices.

Rules, Boundaries, Limitations

Every dog needs rules, boundaries, and limitations. Many people who call Cesar find they have troubles that stem from the dog having a free license to do whatever it wants. For fear of hurting or abusing the dog, or perhaps just out of love, they never tell the dog "no." The dog then becomes the master of the house, the insatiable monster who knocks over chairs and tears open the garbage. After all, nobody told it not to. According to Cesar, a dog needs rules boundaries and limitations. It needs to know its place as a mutt and not as the resident sock-eater.

Humans also need rules boundaries and limitations. Without a constraint to work inside, you can lose focus. If you're given the opportunity to go in all ways at once, you'll end up going nowhere. A good game design, especially one for a small game like indie developers typically produce, typically involves finding one or two novel elements and iterating on them. Even I find myself biting off more than I can chew even though I try so hard to keep the scope down. Sometimes I don't even realize I'm doing it, and it takes others chastising me to realize how much more ambitious I am than I have to be.

Continue Trying Until Something Works

When Cesar is working with a particularly difficult case, you can see a look of concentration across his face. He focuses totally in on this dog. Many times his first technique to help the dog doesn't work, but one thing I came to admire about him was how quickly he would decide that his current technique wasn't working, abandon it, and move on to another one. He would continue this until he found something that the dog would respond to. He unrelentingly tries one technique after another, switching between them so fast and with such confidence that often you don't notice that the whole thing is really just a series of attempts to get a response. He usually doesn't have to try more than two or three things to get the response he wants, but this process demonstrates that the problem isn't really with the dog. The real problem is, how much time are you willing to devote to helping this dog? With enough of a time investment, any problem is solvable.

Now dogs are quite different from games in that they're living things and you have a responsibility to help them if they need it. With games though, there's about a million and a half things to do and definitely not enough time to do all of them. But of the many difficult design problems I have to solve on a daily basis as a game designer I have to remind myself that all of them have good solutions. If I'm too attached to my current implementation then I might blind myself to a better one, but that better solution is out there and eventually I'll find it if I work on it long enough. We'll see if that happens before or after the deadline.

Exercise and Discipline

Cesar Millan thinks all dogs need exercise and discipline. It's 2pm and I haven't gone on my daily run. I usually try to go before noon but today I've been extra busy. What happens when I don't run? First I get ancy. I feel like I have too much energy that I haven't been able to get out. After a few days of not running, I start to feel a bit burned out. I get somewhat depressed and my motivation for working decreases. This causes me to want to run even less and it becomes a vicious cycle. Not running makes me depressed and being depressed makes me not want to run.

But when I go on my daily runs it's a different story. I find that the small amount of time I take each day exercising is more than made up by the extra productivity I gain. I come back from each run with a new burst of energy and drive to get work done. The next day I feel great and I run further than I did on the last day. Then I get back to my desk and do more great work. It's a positive reinforcement cycle that can last for weeks.

I think I'll go on that run now.

## The Cookie Caper - Or, How I Learned To Stop Worrying And Extort The Escapist

This is a repost of an article originally appearing on the Digitanks Blog

It can be difficult to get attention when you're a struggling indie game developer. The video game press tends to focus on the AAA titles. Little guys like me get lost in the rush. Publishers have a hojillion dollars to spend saturating the market with ads for the next big thing, but I have only my wits and questionable ethics, and really I don't have much in the way of wits.

With this in mind I endeavored to resort to what I call "alternative" means of persuasion to get into the public spotlight. You know, perfectly legitimate and convincing marketing counter-measures - bribery, blackmail, extortion. (Fact: these are legal in 48 states.) I'm not above certain methods if it makes me a hojillion dollars. Think indie game developers are only in it for the art? Not this one. I'm in it for the cold hard cash. Show me the money baby. I can go to confession when I'm famous.

I just needed to find a good target. Joystiq? No, they're too nice. Destructoid? No... I don't want to think what would happen to me if I crossed them. The Escapist! They will do nicely. They're usually pretty well-humored. I was at a game developer meetup a while back and I remembered one of the editors from The Escapist speaking at a panel session; she mentioned that she could be bribed with cookies. With this information, I began to formulate my dastardly plan. It would be called The Cookie Caper.

I needed to form a team. A super-team that could pull off this most dangerous heist. But where could I find reliable, trustworthy experts willing to commit to my entirely legal schemings? Every good team starts with "The Informant." Adam, also known as the artist who created the models for Digitanks, lives close to The Escapist's main offices. He could provide me with valuable clues about their infrastructure. Perhaps he could furnish a map of their ventilation systems. Next I needed someone capable of creating "The Goods." I would need the best cookie cooker in the world, someone whose cookie recipes make grown men foam at the mouth. I knew just the person: my mom. Finally I needed the proverbial "Inside Man."

Or, perhaps, Inside Girl? What about that girl who was working at The Escapist's booth at that conference that one time? She was gorgeous. What was her name? I think it was Claire. Yes, she'd do nicely. I dove into my stack of old business cards, and sifted through the people I didn't remember until I found hers. Yes! Time to send her an email.

Subject: Hello Claire

No, that's creepy. She doesn't know me that well.

Subject: Take My Cookies

No, that's even creepier.

Subject: Re: Inside Girl

Okay clearly this email was not going to work out. Forget about her, I could be the Inside Girl and deliver the cookies on my own.

To do that I would need more intelligence about the target area. I had Adam make a reconnaissance sweep of the area around the Escapist's headquarters. The intel came in as a text message:

High security. Cameras. Armed guards. Only one entrance, through the lobby. Address follows...

Adam's a good man to risk himself for a covert mission like this. The intel was solid, and I now had the geographical location of the target. Now for the Goods.

The plan was contingent on delivering the highest quality home-made-from-scratch cookies that money could buy, and the world expert at cookies is my mom.

Mom's a tough cookie: She can sell sand to an African; She can bargain a catch away from a wild leopard. She was a lead negotiator for the police during the 1997 Chatanooga Hostage Crisis. After she was through with them, the terrorists ended up surrendering for fear of upsetting their mothers. I would need a rock solid plan if I wanted to get her on my team, so I prepared my position and confronted her.

"Mom, I need you for a secret, covert mission. You need to bake a batch of cookies. For this service I'm prepared to offer-"

"Sure sweetie, anything you want."

"Oh. Uh, okay. Thanks mom."

"Don't forget to water my plants on Thursday."

"Okay, mom."

Operation Cookie Caper was a go. By the next morning the cookies were done. This is my photographic evidence of the goods:

I managed to break a ceramic plate in the process. A casualty of war: sometimes you have to make sacrifices to get your hojillion dollars. I promised mom I'll pay for it when I'm famous.

Then came the most devious part of my plan -- I took each cookie and cut it in half. That's right -- In half! Then I placed all of the halves in the delivery box and on top of them I placed this note:

Escapist Magazine, We have your cookies. We have included their severed halves as proof.

Give us one article in Escapist about Digitanks and one guided tour of your headquarters or you will never see your cookies again.

- Lunar Workshop Team

Cookies under arm, I went to the Escapist building. On the way in I passed the "armed guards" - an overweight mall cop with a taser. Clearly Adam had been exaggerating, so I confidently strolled past him to the elevator. It opened with a Ding! and I stood aside to let the current occupant out.

Out of the elevator stepped Claire, the girl from the conference. My mind raced, nagging for me to say something! But what? Anything! She walked past me, apparently not recognizing me, heading towards the main doors. I had to say something!

"Hi Cla-"

Ding! The elevator door closed and I ascended to the second floor, kicking myself in the butt. Forget about her. Eyes on the prize. Nothing can stand between me and my hojillion dollars now! I puffed out my chest, burst out of the elevator, and stormed directly up to the receptionist, a cross-looking middle-aged lady with a phone to her ear, clearly completely uninterested in me.

"A package for you."

"Do I have to sign?"

"Um... no."

"Okay, thanks."

With that I turned around and got the hell out of there as fast as I could. The cameras would be watching. When I was out in the parking lot I flipped open my cell phone and sent a text to Adam to confirm mission success:

The eagle has landed!
The eagle has landed!

With a screeching of tires I tore out of the parking lot, high-tailing it back to the safety of my home office. Sitting down in front of my comforting bank of monitors I put the next phase of my plan into action:

Wait.

Yeah. I actually don't know what to do at this point. Pulling capers is fun and all, but what to do after it's all said and done? Did they even open the box today? Will they write it off as a dumb gimmick and just eat the cookies? Or will I get that tour and an article about my awesome game? Will I get my hojillion dollars? I suppose I'll have to wait and see.

And what about Claire? Maybe I'll see her when they deliver on the tour that I strongly requested? Maybe I should ignore her and pretend like I don't know her. Or maybe I should just stop thinking about it.

She'll notice me when I'm famous.

Update: My rotten bribery appears to have worked.

## Form and Function The CPU Visual Design

This article was originally posted on the Digitanks website

Okay I promised that I?d write twice a week and that?s not working out. I confess! I?m too busy to write twice a week. So, from now on we?ll work on once a week postings. This week I?ve decided to give you guys a behind-the-scenes look at how the visual design for our CPU structure was decided on. I think I?m going to make this into a series because it interests me a great deal, it?s one of my favorite parts of game development. It?s one thing to let an artist loose on one of your assets and say, ?Make it look good!? but with a little bit of forethought and design, a game?s art pieces can be not only pretty but also contribute to the game in meaningful ways. So I?m sharing our design process in the hopes of helping others in their own game development exploits. (Also: if you want to get wasted tonight, it may be a fun drinking game to take a shot every time you see the term ?CPU? in this article.)

If you remember from the tank design article, the first thing I always do is establish my goals and constraints. It?s a classic problem solving technique, when approaching a problem where the solution requires divergent thinking, I always start out by figuring out where I don?t want to go.

1. It?s the largest structure, it needs to interact properly with the terrain even if that terrain is steep in grade.
2. It?s the center of the player?s base, and the essential thing to protect, the design needs to look imposing or important.
3. It needs to remind any computer-proficient person of a CPU.
In the case of the CPU we face a number of problems. Digitanks is a strategy game and the CPU is used to construct other structures. It also acts as the source of the player?s ?network? and all of the player?s energy expands from it. The goal of the game is to destroy the enemy CPUs, so they need to look like something worth destroying. That means they need to be large, and with largeness comes problems interacting with the terrain. The terrain in Digitanks is dynamically generated and can be rather steep, so large structures need to be able to rest on this terrain and still look natural. And of course, it needs to be reminiscent of a real-world CPU. Anybody who?s opened up the inside of a computer and looked at the mysterious gizmos and gadgets within should say, ?That?s a CPU!? when they look at our design. Not all of the structures in Digitanks follow the computer-hardware model, but for the ones that do we wanted them to be obvious enough to the typical gamer who doesn?t necessarily hold a computer engineering degree.

A typical CPU has two strong elements in its design, which are purely functional. The actual processing bits of the CPU, a flat square essentially, are hidden from sight below a large heatsink. Processors require these to keep from overheating and melting themselves from the billions of calculations running inside. A heatsink is a pretty recognizable piece of computer hardware, you see them all over the insides of these units, even on parts other than the primary CPU. Graphics cards have them on the GPU as well, and any gamer worth his salt will have installed an upgraded video card and seen this. The other dominating part of the CPU is its fan. These are the things that make the characteristic, reassuring humming sound that computers tend to emit. The nice thing about fans is that they rotate in place. A good animator knows that constant subtle motion is important for making things look natural and stand out from their environment. A fan would be quite an effective marker to help the player recognize the importance of the building. Imposing is not a problem here, I?ve had heatsink/fan combinations that take up the majority of the space inside the computer case.

So we?re going to steal (I mean borrow!) heat sinks and fans from real-life CPUs. The problem is, real-life CPUs are built solely with function in mind, they?re not built to be pretty or look good. The only people who ever see CPUs are the geeks in Best Buy who at best actually enjoy poking around inside computers, and those people dress in suspenders and plaid. Let?s face it, CPU designs may look neat sometimes, but only if they?ve been designed by the marketing department, in which case they?re probably not as functional. So we need to take these two basic recognizable elements and spruce them up so that they?re more pleasing to look at. So, I sent my artist off to do some concepts. Adam?s a fantastic guy and he came back with a pretty good first attempt. Usually I would go for 2d art for concepting, but Adam is able to construct simple things so quickly in 3d that we just skipped that step. As usual with first attempts though, it?s a bit lacking. I think that technically it satisfies the design requirements and incorporates all of our design sources, but it?s not entertaining enough. It doesn?t punch. It doesn?t look iconic. It doesn?t have the fizz bang pop crackle breakfast cereal element. Seriously, I want to feel like I?m watching a kid?s cereal commercial when I look at this thing. Seriously.

But, important in this design are the pins. This is how we decided to satisfy requirement number 1. The terrain in Digitanks is fully destructible and it?d have been a simple enough endeavor to automatically flatten the land around any structure that gets placed. However, I thought that would pose more problems than it would solve. What if two structures are placed close together? How would it handle very steep terrain? What happens when the leveled out terrain gets attacked? There?s just too many if?s in that design, and besides it removes what I think is a pretty cool visual style for the structures in the game, which is essentially to place them all on stilts. These stilts can be reminiscent of CPU pins. On every side, CPUs have pins that carry currents from the CPU to other parts of the computer, and with one stone we?ve killed a bird of terrain-steepness and a bird of CPU-resemblance. These pins would be long and stretch down below the terrain. Placed on a steep hill, some pins would intersect with the terrain immediately and others would extend down and touch the terrain further below. This also creates a space underneath where tanks can be seen more clearly.

The next revision was a great improvement. This time we stole a design from a radial heatsink. The radial design works great because it suggests more effectively that the CPU is the center of everything. It also complements the fan sitting so precariously on the top. But with our new radial design, we?ve lost the impact. It?s a bit less imposing now. The obvious way to address this is simply to make it taller. There?s also the problem of the empty space that sits between the circle and the outer corner of the square, it makes the entire structure look less imposing, which we decided to try to ameliorate by adding fins.

The fins didn?t quite do it. They certainly filled that empty space, but not enough to my liking, and they looked too out of place in the context of a CPU. This is when Adam had the splendid idea to take the radial shape and space-fit it to match the inner bounds of that square. It worked great and it was the last element needed to cement our CPU designs. The fins remained, but with a less obvious role.

That does it! At this point we?ve satisfied all of the designs and it looks great. It?s a combination radial design with a square CPU shape. It?s similar enough to a heat sink with an obvious fan on top (it spins!) that when my dad first saw it he instantly recognized it before I told him what it was. Also notice the angling of the pins, for a little bit of extra flair.

I like this design because it demonstrates the creative process pretty effectively. We started with our ?canvas? of limitations, and continued to throw out bad ideas and brainstorm until we found ones that were good. Neither one of us had a clear vision for what the CPU should look like when we began, but each of us had ideas and we were able to wrestle something good from them. What you didn?t see as a part of this article was the number of sessions that Adam and I sat down and talked (figuratively through emails) about the many designs which came up and how to improve the good parts and remove the bad ones. If we had used the first it may have looked passable, but we?ve ended up with something much better because we didn?t stick on the first thing, and we used each others ideas to make a better result.

In other news, I?ve launched two new methods of communication with me! I love it when people get in touch with me and give me their thoughts on my articles and on the game, so I?ve decided to become active on Twitter again. I used to think (in fact I still think!) that Twitter is for celebrities and socialites, but a lot of people have asked me if I have one, so I figure maybe now it?s time. I?ve also opened up comments on the Digitanks website. Feel free to post your thoughts in the little comment box below each article. Also a quick reminder, if you like what you see you may be interested in in joining the Facebook page or the Steam group. Until next time.

## Engine Roulette The Case For Using Custom Game En

This is a duplicate of a post from the Digitanks website

Disclaimer: This is mostly a rant of disorganized and sometimes half-baked thoughts that have been going through my head for a couple weeks. It may be a bit of a confusing read and for that I apologize. Still I think there?s a nugget of wisdom in here or I wouldn?t write about it, if you?re willing to piece together my stream-of-consciousness writing style you may derive some value from it.

One of the first problems a game developer will run into when beginning a new game project is what engine to use. Naturally you want to use the engine that?s most suited for your project. You?re not going to make a hidden object game on the Source engine, nor do you want to use the Popcap engine for a first person shooter. There is a slew of free and open source game engines available, and a cavalcade of commercial engines as well. But this is a fairly solvable problem, it?s a straightforward process (if everybody is relatively unbiased) to look at the requirements of your game and the capabilities of the engines on the market to decide which engine is best suited for your purposes at your price tag.

If only life were so simple? You see, in addition to a long list of features, each engine carries with it a huge array of baggage. It?s never just about a list of features. Each engine has other properties that aren?t really quantifiable. Depending on who you are as a game developer and what kind of game you want to make, there?s a number of ?question mark? factors that throw a stick in the spokes.

Let?s look at it from a modding perspective, which is where my background lies. Source has a huge online community of people who already play Valve games, and you?re basically selling to that audience. The upside is that Valve is well known for plucking talent from the indie and modding community. If you?re good and a little bit lucky, Valve or some company scoops you up and you get a job in one of the best places to work in the industry. Epic?s engine lacks the kind of community that Source has but it allows you to package and distribute Unreal SDK games independently for free purposes, so your audience doesn?t need to own a copy of any other Epic game to play it. So while you?re not really reaching the kind of crowd that you reach with Source, it?s easier to convince people to play your game since you don?t have to prefix it with ?First, buy a copy of Half-Life 2.? Another upside is that Epic runs their ?Make Something Unreal? competition periodically, the prize for which is a commercial license for the engine and a huge sack of cash. Now I personally am not averse to a huge sack of cash and I can point to a number of companies that have been built on this strategy, so this sounds like a good deal even though there?s plenty of competition in that area. There are other modding engines but I think these are the two big ones, and the conclusions that I draw are that these are good avenues to go down for game creation, but you basically need to strike gold if you?re going to get anywhere profitable with modding.

Besides, a couple years ago ?indie? became the new ?modding.? It used to be that two or three guys could get together and change a couple things around to produce a cool game in a couple of months. I used to work on The Specialists, which was produced essentially by one guy (not me) with one or two other people helping in a matter of months, and for a time it was the most popular Half-Life mod. Counter-Strike and Day of Defeat are similar stories. Ever since Half-Life 2 was released and the Source engine came out, that story has changed. Now the amount of work to make a AAA-quality game has exploded and mod teams just can?t keep up. That relegates the one and two man teams to working on indie games, focusing on design and gameplay over competing graphically with the AAA games. As such there?s a number of engines you can use, none of which I?m extremely familiar with. Unity has its new web thing, Torque and ShiVa seem to be dying these days, and then there?s a bunch of open source 3d engines. If there?s competition in modding though, there?s even more competition in indie games. We haven?t even gotten into the 2d platforming and shmup style games, of which there are literally shit-tons. You can take a look at this short video of
">over 200 free games to see what you?re competing against if you want to make an indie game. Shining against that backdrop is going to be a challenge to any game designer. For every iPhone game that makes a lot of money there are quite a bit of good, fun iPhone games that simply never see the light of day, because nobody famous ever links to them in their twitter.

Ultimately I feel like any of those paths is like playing roulette. It?s possible to have a really nice game that simply never gets seen. In modding your goal is to get picked up by a big company and that involves a good deal of luck. Showing a promise against the sea of commodity games can also be difficult. So where?s the solution? Part of the problem is a failure of imagination. You?re not going to be successful unless you can offer something that hasn?t been there before. The problem with game engines though is that they tend to only offer things that have already existed before, leading the developers of those engines down the same paths others have already tread. Portal required extensive expansions to the Source engine to be able to interact and view portals properly, and its source material (Narbacular Drop) used a custom engine. World of Goo was built from scratch using existing libraries but no single game engine package. The validity of the standpoint of using a custom engine can?t be argued with games like Minecraft. I can?t decide if the author of that game, (known on the internet as Notch) is a diamond in the rough or a genius game designer with too much on his plate. Minecraft is a fun cooperative building game, but his focus on Dwarf-Fortress style survival gameplay seems to be hit or miss. In any case, I don?t see an avenue for Minecraft having become as popular as it was without the web-based Java deployment that it employs. I also don?t see it happening from a technology standpoint in any existing engine. So the argument for custom engines becomes stronger. Incidentally this is the path that Digitanks takes. Using a custom engine let me prototype quickly and add things like terrain deformation that would have been quite difficult in other engines.

But doesn?t this fly in the face of standard business thought? What ever happened to the idea of reusing code? The whole point of having game engines is so that you can save yourself a lot of work. Imagine the mass of code that gets duplicated every time someone starts a new project, like physics, localization, rendering, and networking. Aren?t I creating a huge amount of work for myself by not standing on the shoulders of giants?

Well, yes. None of this should really come as a surprise. My grandfather always told me that anything worth doing is going to be hard. (That?s a lie my grandfather doesn?t speak English that well.) I still make a conscious effort to take advantage of work other people have done. I?ve covered this on the blog before. I use other people?s network code, rendering code, and so on. But there are parts of Digitanks that are so different from other games that it?d probably actually take longer for me to rework another game engine to use them. I used Source for years, and before that I used Half-Life, and before that I used Quake. I could have developed Digitanks in Source, and given my familiarity with the engine it probably wouldn?t have been all that challenging. If I did that though I?d be playing roulette. To succeed I would have pretty much needed to be picked up by Valve, which is a huge gamble. So I?ve taken the lesser trodden path. That comes with a completely different set of problems that I have to face, like building my own community, and getting people interested in an unknown indie game, but it?s a set of solvable problems that I?d much rather tackle than taking a chance at a throw of the dice with the bigger engines.

## Digitanks Wins A Richter Award At PAX!

Okay, it's story time.

Among the many things that occurred to me at PAX I at one point found myself standing in front of the creators of the Blamimations, Scott Kurtz and Kris Straub. Fortunate as I was to happen upon them (by standing in line at their table for five minutes) I decided to ask them a question of grave importance. If you go to the Blamimations website it humbly reads, "The triumphant return of the Richter Award winning series." Now I've seen every Blamimation since day one and never have I seen a single Richter award. So I spent a little bit of time on Google trying to find out, what the hell is a Richter award? Google gave me no answer. I see Webbys and Hugos but no Richters. Putting this question to Kris I received a grin and then the following answer:

"A Richter award is a prestigious imaginary award given to those who have exemplified excellence and created a masterpiece of art while positively affecting the lives of everybody on the planet."

(Or something like that, where's a tape recorder when you need one?)

At this point there was a man sitting next to him who asked, "Who's eligible for a Richter award?" To which Kris replied, "Well, everybody." The question naturally followed, "Can I have a Richter award?" and so Kris gave the guy a Richter award. Then he turned back to me, "And you can have one too."

THERE YOU HAVE IT, FOLKS!

I am now in the alumni of the prestigious Richter award winners. Digitanks is indeed an example of an excellent masterpiece that has positively affected the lives of everybody on the planet, so I can think of no lesser award that it would be deserving of. Thanks Kris! And thanks for drawing that ghost with a boner on that poster you signed for me.

A number of other amazing things happened at PAX. The reboot of Duke Nukem Forever by Gearbox, the first gameplay footage of Portal 2 coop, the announcement of FireFall (I still have no idea what the game is about) and lots of other fun happenings. Additionally I encountered three wonderful journalists from three amazing websites and I got to chat with them for a while about Digitanks. I'm pretty new to all of this PR stuff, so they were kind enough to show me the ropes, in addition to interviewing me about the development of Digitanks. My appreciation goes out to all three of them.

Later in the week I'll be returning to my usual 2-3 times a week update schedule as I plan the last month or two of development before the first Digitanks public release! See ya then.

## PAX, Contests, Etc

I haven?t posted here in a hot minute. I?ve been extremely busy. I?ve been getting ready to go to PAX, and getting a third demo together for all of my adoring fans. On top of this, I have to walk my dog every single day.

Part of the problem I?ve been so preoccupied with the demo is because I added a major new feature which I?ve had some trouble getting to be fun enough. I had some serious doubts about whether or not it would actually work, but I?ve managed to wrest a good deal of fun out of it, and I?m not confident enough that I?m ready to show it off.

You can also see the new user interface that we?ve been working on, vastly improved from the old for better readability and usability. Adam?s been doing some good work on this. There are actually graphics for all the buttons now! And that ?Turn? button is exactly what you think it is.

Once I get back from PAX I?ll be working on putting that third demo together and releasing it to the general public. I?ll also get back to writing those essays on game development that I do from time to time. By the way, if anybody is going to PAX and wants to meet up and have a drink, just drop me a line, I love to meet people.

Now you may remember that a couple of months ago I submitted Digitanks to a number of game development contests, including PAX 10, IndieCade, and a couple others. Well the last of those submission results came back today and it turns out that I didn?t win a single one! I didn?t really expect to win any because the game at the state of submission was rather lacking on features, but it still saddens a very small place of my heart. Oh well, there?s always next year. There?s another competition coming up next month that I can enter and not win, so I do look forward to that.

## Screenshots from Fans

After the demo was released, some of the people who played it have sent me screenshots of their games, so I thought I would share them here.

From SchnappleMcG:

From Raidyr:

Thanks for sending the screenies over guys!

To play the game head on over to the Digitanks website.

I was informed that the anti-spam mechanism on the forum was keeping registrations, but it looks like that?s been fixed now so if you had trouble accessing the forums before please give it another try.

## Your Chance To Pulverize A Digital Landscape

The base-building demo of Digitanks is now ready. You can download it on the download page. If you enjoy the demo, please take a stop by the Help Us page to see how you can assist in the development of Digitanks. Here's a screenshot of the downloadable wares in question:

Many people have asked for a central place to voice their thoughts on the development of Digitanks. To this end I've erected a forum for the purpose of discussions of all things Digitanks. Discussion of other things is optional but encouraged. I decided against a blog comment system in favor of this since I think this will keep things more organized and in a central location, but if you think a blog comment system would be better then please make sure that opinion reaches my ears at some point. I hope that this forum won't become a wretched hive of scum and villainy as so many locales on the internet tend towards, but I can't guarantee anything.

Also an additional reminder: If you spend any time on Steam or Facebook, please note that we have groups on those systems specifically for the purpose of showing fandom and appreciation for this wonderful game, and I invite you to join them and share your feelings. If at any time in your recent past you have Dugg something, note that there is also a button that would facilitate your Digging on the top right corner of this page. And I suppose that if you've ever Tweeted something, now would also be an appropriate time for such things.

## Losing Sleep

A couple nights ago I was taking a break playing City of Heroes. After that article I wrote that mentioned the bubbler I had a hunkering for playing it again. After playing for a little while my GPU overheated and the computer shut off. Well that's happened before so I took out my trusty can of air and cleaned out the laptop's internals a little bit. Most of the time it's just extra dust buildup that prevents the fan from cooling effectively. After I left it to cool off for a while I turned it back on.

Windows would not boot. It just refused to boot up. It does that on occasion but usually I run the system restore and then it works again. Windows Vista can be finnickey that way. But this time, no cigar. After endless tries rebooting and running the system restore I finally gave up and decided to reinstall the entire thing, taking the opportunity this time to upgrade to Windows 7 x64. (I like it a lot, by the way, except for that the OpenGL drivers for my NVidia card randomly spaz out and claim that they don't support framebuffers.) I've backed up all my data so I didn't lose anything but the time required to reinstall everything to get productive again.

It came at a very bad time because I'm trying to get another demo ready. I was originally shooting for Sunday night, but I wasn't pleased with the state that the game was in. The fun is definitely there now, but it's still in an infant state. I'm cultivating it and growing it to make it something worth writing home about. I don't want to release another demo until I'm largely satisfied with the fun level. I also want to make a bigger splash this time and attract more attention to the project, which requires a little bit of ground work. That means not getting much sleep, but hey I knew what I was getting into when I started this.

Adam came over today to talk about the progress of the game. We have a first iteration of every structure except the resource node in the game. He's done a fantastic job in making all of the buildings look unique and cool-looking. I had him sit down and play the most recent version and he built up a huge base. He was still expanding and conquering when he realized he had to go, but I quickly snapped a screenshot of his handywork.

The good news is that the playtesting is starting to show a lot of progress, but the bad news is that I now have a list two pages long of things that need to be fixed before we can release the demo.

By the way I've added a Digg button to each post. If you like Digg and you enjoy the post, please take the time to visit the website Digg it. I'm going to be trying out the Digg button to see if it does anything for me, we'll see if it stays or not.

## A New Screenshot

This is a post duplicated from the Digitanks website.

Today?s update brings a new screenshot from Digitanks-land. Click on it to view full size.

Featured in this new shot is are the new CPU and buffer models. A long time friend of mine, Adam, is helping design and construct the models. These designs are still in progress, we?re trying to work out the details on how we want them to look, so the textures and geometry of them are far from finalized. But, they should give a rough idea of what the end result will look like. There?s a chain of buffers leading up to that small gray box, which is placeholder art for a resource node. The blue circular object right next to it is a resource collector that the player is trying to construct. The yellow tank on the right has decided to attack, and I?ve responded with some tanks of my own. The large blue tendrils coming out from all of the structures is the player?s ?Network.? It defines the player?s territory and helps support friendly units. In the future, I?m going to write a blog post detailing how we came to the design decisions that we did concerning the structure models, but for today it?s just a screenshot.

I spent most of the past few days revamping the tutorial. My previous goal for the tutorial was that the player could learn the game as he was playing. This is pretty common in first person shooters, and that?s where my previous experience comes from. However, it?s just not realistic in a turn-based strategy game. Civilization IV, for example, has Sid Meier personally teaching the player the basics of Civ, and the new Red Alert 3 has special tutorial missions that instruct the player before he even gets into the game proper. It?s a noble goal to not require the player to play a tutorial, but I think it?s standard practice in a technical and strategic game like Digitanks, and limiting myself in that way was starting to detract from the player?s experience, since the in-game tutorial lacked sufficiency to cover all of the required topics. So, I decided that my approach about it was all wrong, especially when a couple people (you know who you are, thanks!) wrote me telling me about how it was wrong, all wrong. The new tutorial is much better. It removes the player from having to learn under pressure, and hand-holds the player through the process of moving, aiming, turning, promoting, and setting the energy for a tank, and has him kill an enemy tank for practice. It?s so easy, that my mom (notorious non video game player) completed the tutorial with only minor difficulty. This tutorial is so easy that I think that my dog could be trained to complete it, if he had opposable thumbs and could operate a mouse. So, my next goal is to get an equally easy tutorial that teaches the player the base building mechanics. That?s going to be a bit more of a challenge, but I?ve already finished the first draft so all it really needs now is some good playtesting.

Adam, like I mentioned before, is helping with some of the artwork. He?s pretty keen and he?s a great guy, and his help is allowing me to focus more on the design of the game. My role as the ?Facilitator of Fun? is playing the game, figuring out what the most un-fun part of it is, fixing it, and playing the game again, ad nauseum. I mean that quite literally, it?s beginning to be a bit of a drag. A week and a half ago the game was completely not fun, and slowly I?ve been wrestling small inklings of fun into it. There?s a fun game in here somewhere and I just need to chip away at the stone until its true form emerges. Some of the problems are systemic and cause me to re-evaluate the way I think about the design of the game, but the majority of the problems are either minor playability issues, a multitude of which must be waded through as if I were swimming through a game development quagmire, or else AI problems. It?s funny how many problems in gameplay stem from the bots that control the computer opponents ? if they don?t behave in a reasonable way, the player stops having fun. After all, a bot that simply lets you roll over his base with no questions asked isn?t very fun. You could say I underestimated the amount of time I scheduled for myself to design fun gameplay at the onset of this project, but really I underestimated how hard it would be to make convincing AI?s. They don?t even have to act the way humans do, so long as they provide an appropriate challenge. That is in itself a challenge for me, so Adam?s work is immensely helpful in allowing me to concentrate on it.

In any case, being so hard at work as I am, I?m planning on releasing another demo in near future that will showcase the new base-building aspects of the game. I?m also getting closer to creating a feedback system for the website. Thanks for following Digitanks development and thanks for your patience!

## Simplify, Organize, Prioritize

This is a duplicate of a post on the Digitanks website

Lately I've been feeling like I have way to many things to do and not enough time in the day, so at the risk of sounding like a middle manager rife with meaningless anecdotes about synergizing with improved productivity, for this edition of the Digitanks development journal I thought I'd share with you how I keep my sanity in three easy steps. My past week has been spent just refining existing gameplay so there's not much game-wise to post about, so read on to learn about my patented method of attacking problem solving.

## Simplify

You've been working all day. You're tired. You have one more thing you need to do before you go home, but it's a monster. It's huge and complicated and you can't fit it all in your head. You have no idea how you're going to even approach the idea of solving this problem, and you don't know where to start. You need to simplify.

As I've covered in previous articles (I think?) any problem can be broken down into a number of smaller steps. Once you get the problem down to a series of bite-sized steps, it suddenly looks like a piece of cake. It gives you a starting point, and it helps you stay motivated since you're only having to attack one small task at a time, and you no longer have to look at the bigger picture.

When I began working on Digitanks, it seemed like a huge undertaking. So much stuff to do! So I sat down with a piece of paper and wrote out all of the individual parts of the program that I would need to tackle.

• Application framework

• Tanks shooting and dying

• Base building

• Multiplayer code

• Units

and so on. Each task takes in the order of one or two weeks to complete. Then when I begin each task I break that up into smaller tasks. How many structures will I need? What new structural code will I need to write? How long will designing the gameplay take? I make a list of tasks that I'll need to do for that features to be complete. Now the work is as good as done, I only need to go down the list and do each thing.

You can also conceptually simplify a problem. I spend a bit of time each day (usually in the morning just after I wake up, or in the shower) reflecting and thinking about the problems I have to face on that day. Oftentimes just thinking about a problem can reveal its inner simplicity. Like Cesar Millan says, life is really very simple, but people tend to complicate things. (Cesar's my hero by the way, my dog is well trained and behaves thanks to all the stuff I learned from his show.)

A while ago I had a problem with one of the libraries I use to render text to the screen. At some point if I was drawing too much text, the library would start crashing, because it had too many file pointers open to the same font on the disc. It was affecting both Digitanks and SMAK, (they use the same UI library) but Digitanks was affected even more since it can draw a great deal more text at any time. I was at a total loss of how to solve this, since it happened deep in the bowels of a support library that I didn't understand. I ignored the problem for a while (ignoring a problem in hopes that it goes away can be a fairly effective way of solving the problem, sometimes -- just don't try it with your bills) until the day that I realized the problem was really very simple. I was opening one font for every bit of text I wanted to draw, instead of opening one global font object and using it for all of the text. It ended up being a 10 minute fix once I realized what the real problem was. But, rather than bang my head against the keyboard for hours or days, I just let the problem stew in the back of my mind until the inner simplicity became apparent.

## Organize

Organization once conquered the world. It's a fact. I'm talking about the Romans. Many problems present themselves because of lack of organization. I can't tell you the number of times I've had to go in and rip out a bunch of code that was just too messy, due to not having been properly thought out ahead of time. After I think of a better way to organize that code, typically the number of lines of code gets reduced by half or more.

One of the bits of feedback I received from playtesters was that lack of camera control was a major drawback. So, some time after the last demo, I put in some basic camera controls, where clicking on a piece of terrain would move the camera there and using the scrollwheel could zoom in and out. Over time though, the camera code became a mess, it was scattered all over the place. It was very difficult to debug or change something. Eventually I said enough is enough, and I created a "camera class" which was a single, centralized place for all camera-related programming to remain. Then, when an important event happens that requires the camera to be centered, it calls into the camera class to center the camera at that spot, and the camera class handles all of the specifics. Now all of my camera-related code is in one place, it's very organized.

I tend to be a neat person. I really don't have many belongings, just my laptop, some musical equipment and a futon for sleeping on. So my floors are always clear, tables don't accrue oddities, because I have no problem throwing things away with they're no longer needed. When it comes to my desk though, it will tend to accumulate crap. I'm typically engrossed in my work, and I don't like to have to tear my attention away to do other things, so they get piled up on my desk with a promise to take care of them "later." Of course, "later" never comes, and the piles continue to grow higher until the moment that I say "enough is enough" and turn my attention to reducing them. Here's where organizing comes in. Some things go in the trash pile, some things go in the "file pile" to be put in cold storage in a filing cabinet and hopefully never seen again, and some things go in the "need my attention" pile. Then, after everything's taken care of, my desk is clear and organized with everything in its place -- this is typically the period where I'm the most productive.

Now it is possible to be too organized. In my last post I talked about how the Romans lost the battle of Cannae. The reason for this is that the Carthaginians knew about the Roman's organization and exploited it. They knew that the Romans would advance in their tightly knit columns, carefully monitored by the now-predictable generals whose strategy was to advance until the enemy was obliterated. So, the Carthaginians allowed them to advance, slowly retreating the center of their lines, but leaving their flanks to envelop the sides of the enemy force until the Romans found themselves surrounded. They were so organized that they had forgotten to be agile enough to respond to new circumstances.

I worked once at a company that was about three programmers. They decided to implement a new all-in-one project-management, issue-tracking, and time management software system. The problem was, there was only three of us. There weren't hardly enough people to actually merit using all of these complicated procedures. It was eating up more time in the updating of the system than it was saving in organization benefits. We were all three in the same room, if we wanted to know the status of an issue we could lean over our shoulder and say, "Hey John, what's the status of the menu bug?" and John would reply, "Oh I fixed it a couple hours ago." In an organization of 30 or 300 people, you need sophisticated software to handle that, but with just three people, we became a slave to the process of updating the software, and actual work ended up suffering.

## Prioritize

So now you have your organized list of simple problems, just waiting to be solved. Problem is, there's about ten thousand of them. If you're like me, for any project of nontrivial size, you have a list ten miles long of things remaining to do, many of which you'll likely never have time to complete within the time allotted for yourself. You need to prioritize.

Many tasks can be put into one of two categories. It can be the kind of task that nets you 80% of the gain for 20% of the work, or it can be the kind of task that can net you 20% gain for 80% of the work. I call the latter "polish work" and the former "fantastic." In the excitement that's associated with any project, it's really easy to get caught up in the latter, especially if you have the kind of workhorse personality that I do. Artists tend to polish something to a fault. It's never perfect, and you can always tweak and tweak and tweak ad infinitum. Ten hours later, you realize you wasted the entire day on a model of a dirty shoe when your main character is still a big box.

Every day before I start work, I take a look at all of the things that Digitanks needs, and I work on the parts that are the most sorely lacking. For instance, at the moment a lot of people have been mentioning that they're frustrated by the lack of movement in Digitanks. This is kind of strange to me since in many turn-based games the movement per-turn is very limited. In Civilization, the first units the player gets can only be moved one tile per turn, but nobody complains. I increased the movement radius, in fact I almost doubled it, but that didn't really solve the problem. I think the reason that people are bothered is that in Digitanks there's no tile grid, so players take movement for granted. The game looks more like StarCraft, and players expect to be able to move wherever they want. That's my biggest problem, so it's what I'm focusing my time on right now. My solution is a pretty simple one, if you click to move outside of the tank's movement radius, the game will remember that and automatically move that tank over the next couple of turns until it gets to the location the player clicked. Now, there's another issue that I have yet to deal with, which is that the top of my tank's turrets look BORING! They need something to spice them up and make them look less plain. But it wouldn't be a very good use of my time to work on that when the structures are still large boxes, so I put it at the bottom of my priorities list.

The way to get everything done that you need to do is to prioritize which items are most important, and do those first. You may not get to the things on the bottom of the list, but you can sleep well knowing that you made the most impact you could.

By the way, lots of people have been asking me to include a way to allow comments on the blog's homepage. I'm working on that. For now, if you have something to say, just send me an email. I love getting emails!

## Lessons From World War 2

Studying real-world battle tactics isn?t something I do a lot, and by no means am I any kind of expert on the subject, but I do enjoy to read about the topic and watch documentaries about warfare. It?s a great way to waste time under the pretenses that I?m learning something that might actually one day be completely useless to know. Actually that?s a bit harsh, when I was in high school I used to complain that all of those AP Physics and Calculus courses I took would never be used in the ?real world? and now here I am developing video games and applying those Physics and Calculus concepts on a daily basis, so maybe I should learn tank warfare tactics in more depth, in preparation for my starring role as World War 3?s greatest tank commander. Following in the footsteps of Rommel and Patton, I?ll redefine what tank warfare means and singlehandedly win the greatest war humanity has ever known!

Or I?ll just use the concepts to design a fun artillery game. I think we?ll go with option number 2.

So these Military Channel documentaries about tank warfare are pretty neat, but they really only cover warfare from a strategic, high-level point of view. Very rarely do they ever go into the nitty gritty tactics of tank warfare. While I knew the basic pros and cons of the tank versus the infantry, I still had never learned before now why exactly tanks became of such a strategic importance on the battlefield and how they play such a vital role in modern military conflicts. So, I went to the best place to learn about such things, which of course is Wikipedia. Here?s what I learned.

To understand why tanks are so important to modern warfare, I?m going to take you all the way back to the ancient Romans. Warfare is of course as old as mankind itself, and in the beginning stages, the basic strategy of warfare was ?get a bunch of guys together and go kick the shit out of those other guys over there.? I?m sure that was the basic tactic for thousands of years, until the Romans came along and introduced organization. The incredibly organized and disciplined Roman legions could take on forces much greater in size than their own, since they formed organized units with columns of incredible killing efficiency. The Romans specialized in a new type of warfare that involved creating big lines of men that were difficult to attack from the front. I?m no war historian, so take everything I say with a grain of salt, but I think it?s safe to say that the Romans developed the idea of ?battle lines.? These lines had incredible defensive power, and since they were so difficult to defeat, they managed to conquer the entire known world at the time.

Now, the graphic I chose to accompany this article is actually rather ironic, because it?s from the Battle of Cannae against Hannibal and the Carthaginians, which is the first major battle that the Romans lost. They lost it because Hannibal exploited a weakness in the Roman?s organizational system, letting the Romans advance and enveloping their flanks until the Romans found themselves surrounded. It?s the first recorded instance of the use of a ?pincer? movement. But in any case?

This is the way warfare was for many thousands of years, with the two sides lining up on the battlefield and facing each other, lobbing cannons at each other and generally trying to kill each other. Sounds like an honorable way to die, nobly facing your enemy. Fast forward to World War 1 and the 1910?s. At this point we had gone past the spears and archers of the Romans and developed rifles which were accurate many hundreds of yards away. It was no longer prudent to line up facing the enemy on a battlefield because the enemy would just shoot you. That kind of thing had died with the American civil war, and with the advent of rifled barrels. So now the thing was to dig trenches in the ground in order to provide yourself cover. Each side would dig a trench at their battle line, and these trenches would provide the soldiers incredible defensiveness to the attacks of their enemies. It?s hard to shoot someone who?s protected by a couple yards of dirt. Just like what happened with the Romans two thousand years prior, once again we have a superior defensive ability revolutionizing the way wars are fought. It?s so much easier to be defensive than it is to be offensive, since you can just pile on another layer of protection, but developing a new weapon that can be safely and efficiently wielded on a battlefield is far more difficult.

So the Germans and the English sat in their trenches, each having a very high defensive position, and played a game of trying to attack the other side. That meant leaving your heavily fortified trench and running out over an open, war-scarred field in an attempt to reach the other guy?s trench so that you could gain a couple of yards. It made no sense! Warfare had gotten so incredibly defensive that the costs for attacking were just way too high. New weapons needed to be developed with enough offensive power to overtake the trenches. Enter TANKS!

Tanks are mobile weapon platforms. They?re really just a big cannon on wheels with armor. They work because they help attackers to punch through a defensive line, mitigating some of the defensive advantages that the defenders have given themselves. With enough of this mobile artillery, attackers can create a hole in the enemy?s line, and then by pushing more tanks and infantry through that hole, they can widen it and advance on their ultimate targets.

Tanks aren?t magical war-wands though. You can?t hold down a battle line with tanks. They need infantry to support them, or they?ll become targets. They need to be manned with humans, and humans have needs other than killing, so if tanks run too far ahead of their supply lines their human occupants won?t be able to do things like eat, much less restock their armaments. They?re also expensive to produce, so you don?t see them in great numbers. As such, there typically aren?t enough tanks to cover the entire battle front, and spreading the tanks out too thin is a great way to ensure that they?re overwhelmed easily, so they need to be concentrated to have an effect. So, one of the main aspects of tank warfare is the intelligence and information aspect ? where are the enemy?s tanks? You don?t want to attack the point in the enemy?s line where their tanks are, lest their tanks provide support to the infantry there. When the Allies landed in France in World War 2, they launched a massive intelligence campaign designed to fool Hitler into thinking that they intended to land at Calais, when in fact they landed at Normandy. As a result, Hitler stationed his tanks at Calais, where they were not present for the actual landing. If they had been at Normandy during the landing, the Allies may have failed their landing. A similar situation happened with Patton?s forces in the landing in Sicily, where Allied intelligence fooled Hitler into placing his tanks in Greece, instead of the actual Italian landing location.

Now oftentimes when I?m trying to develop gameplay mechanics, rather than thinking up things that are new and avant-garde I simply find another already existing and fun mechanic, and imitate it. Yeah, I?m a ripoff. Before you judge me though, bear in mind that the vast majority of games are in fact just ripoffs of other games, except maybe for one or two core mechanics that make then unique. Digitanks already has these mechanics, so I?m not looking to invent anything new, because while ?new? is good, too much ?new? is a recipe for failure. In any case, if I?m going to rip off an already existing mechanic for gameplay, why not rip off actual war? Men have spent their entire lives and written volumes in this complicated endeavor, and if I can capture a simplified version of it then it can maybe be pretty fun.

So, I decided to distill the game into a small number of basic elements. (I like to break down problems into smaller ones to make them easier to solve.) Tank warfare involves:

• Highly defensive, mostly stationary infantry elements
• Highly mobile and offensive tank elements
• Supply lines which must remain unbroken
So, I built my units and game mechanics with this in mind.

Mechanized Infantry ? These units can fortify to increase their defensive position. They can be used to defend key areas and create a ?front.? Once fortified, attacking them from the front becomes difficult and overwhelming force must be used, but they?re still vulnerable from the sides.

Main Battle Tank ? These are mobile, strong offensive units which are difficult to produce, but pack a real punch. A single Main Battle Tank can?t punch through enemy lines alone, but a coordinated attack can make a hole large enough to compromise even the strongest enemy position.

Supply Lines ? The closer you are to your base, the stronger your units become. Venturing far into the depths of the unknown stretches your supplies thin, and is a great way to be picked off easily. However, if the risk of leaving your supplies behind is outweighed by the benefit of a surprise attack, it can turn into an advantage.

The idea is that players will balance these three elements while growing their base and finding the weak spots in their opponents defensive positions. Once these mechanics have been solidified, I plan to add bonus units such as artillery and air support, which can help to soften an enemy position, making it easier for the tanks to move in.

Now I just know that as you read this article you had ideas and want to make suggestions to me. Well, I would love to hear your thoughts! So please email me and tell me all about how my ideas suck and/or are awesome.

## I Take It Back!

This is a duplicate of a post from the Digitanks website.

Merely days after my exasperated exclamations of hopelessness, ModDB (IndieDB?) featured me in their video spotlight. My huge thanks to their team for their support. Also a huge thanks to everybody who sent their kind words. I don?t get discouraged so easily Also thank you to the slew of new playtesters who sent in their feedback recently, lots of new ideas are helping me improve the game every day.

I thought I?d share some of my work for the last couple days, here?s a screenshot.

Here you can see that I?ve implemented (at great expense to my sanity and with tremendous cursing of OpenGL) a ?fog of war? where the areas far from the tanks are not visible. In this screenshot, a group of enemy tanks have just emerged from the fog of war to attack the player?s base. Much to the dismay of the enemy team, their main battle tank is being pelted by my own tank and artillery. On the left you can see my base, with a Buffer supplying the troops (explained in a previous post) and a resource collector. These are still just large blue squarular blocks, which are stand-ins for the art that?s going to be developed in the coming weeks. So far the list of structures that can be built at the base is as follows:

• CPU ? This is the command center of the base, and allows all other structures to be built.
• Buffer ? This extends the base?s range, and helps pour out ?data flow? into the surrounding terrain, marking the player?s territory.
• Power Supply Unit ? This structure mines ?electronode? resources to generate production points for your base.
• Mech. Infantry Loader ? This structure can use production points to create Mechanized Infantry units.
• Main Battle Tank Loader ? This structure also uses production points and creates Main Battle Tank units.
Interestingly, ever since the scope of the game expanded, the interface has suffered. In the first demo, there was no need to have to click on tanks to select them, because a max of five tanks (all the same) meant that scrolling through them with space bar would be sufficient. Also, the ?auto-progress? feature that automatically proceeded you through the movement options was a useful thing to have. But now, with dozens of tanks possible, neither of those really make sense, so I?m having to go through and change the way players interface with the tanks.

Previously I decided on a left-click-command and right-click-camera methodology, but that?s starting to get weak. After a lot of debating with myself, I?m getting rid of the auto-progress and reversing those mouse buttons, so left click is camera and unit selection, and right click issues commands. This matches more the StarCraft way of doing things, and we all know how successful they are. I hope that this makes the game a bit easier to get into since the kind of person that enjoys StarCraft I think would also enjoy Digitanks. (After all, I enjoy StarCraft.) One other thing that the game is major league lacking is better camera control, and that?s on my short-term immediate list of things to do.

## Why Do I Even Bother?

The other day I was crawling ModDB (IndieDB?) and I came across a quizzical mod. ?A mod? can barely service to describe it accurately, perhaps if the standards for the term were set in 2003. Its screenshots look like a Quake mod, and in fact the title of the mod seems into indicate that it?s a Quake port of Left 4 Dead, with some other odds and ends thrown in. They claim they?re developing it for the PSP and their most recent post indicates that their team has broken up and they?re reorganizing with some slightly different and altogether over-optimistic goals. Okay that?s fair, I can?t say I was never involved in some unrealistic, overengineered project that was doomed to failure. I hope that when the project dies they find themselves on better ground and learn from their mistakes like I did.

What really irks me about this game is that they have over three hundred watchers on ModDB. Digitanks has been around as long as these people and it only has 79 watchers. How the hell did he get over 300 watchers for a game that looks like Quake with half of the game torn out? Is there some kind of marketing guru genius behind their operation? Do they have a djinni caged in some arcane container, imprisoned as he does the bidding of his watcher-hungering masters? Or does this speak to the kind of person who frequents ModDB, who prioritizes an unoriginal de-make over a good-looking authentic game? It all begs the question, ?Why do I even bother?? I honestly can?t decide if it?s something that I?m doing wrong or if it?s just the forces of the world going against me. I?m trying really hard to get people interested in my game, because I think it?s a damn good game and I want to make a living making more of them, so I guess I have to figure out if I stand to learn something.

Anyway, there?s much to report on the development end of things. I?ve been hard at work doing a number of things, and I thought I would share some in-development screenshots with my crowd.

There?s a number of things going on in this screenshot. First and most obvious is that large blue box, which is a stand-in for the ?CPU.? The CPU will be the command center for the player?s base, it allows him build more structures and support his units. It pumps out ?data flow? into its environment, which can be seen by the light purple tendrils around it, which mind you are also stand-ins. This marks the player?s territory and is the mechanism for supporting units and buildings, anything inside that tendril area gets improved fighting characteristics. There?s also a smaller translucent blob near the center where the player is constructing his first building, a ?buffer.? Buffers serve to help the player extend his base by increasing the data flow in that area.

You can also see some new units in action, namely the artillery in the very center of the shot. They?re aiming at the yellow team off in the distance, and they?re sure to rain down some hell fire in a moment. The advantage of the artillery is the ability to wear into your enemy at extreme range, at the cost of mobility. While the artillery is deployed it can?t move, it can only fire within a small cone, and turning is rather costly, so finding a good vantage point for attacking the enemy will be a must. In the future, there will also be a fog of war that the artillery won?t be able to see through, so they?ll require a spotter if they?re to fire effectively. Lastly, the artillery lacks any short-range weaponry, so they need good protection from the other Digitanks, or they can get ambushed rather easily.

Next we have our Mechanized Infantry. You may recognize their tank design from the failed designs of the main battle tank, I think they?re much more suited for this job. These are highly defensive units make the enemy think twice before attacking your base. In this screenshot, a couple turns after the previous, we can see that the enemy is closing into an attacking position on our base. However, our infantry has dug into their fortified position, so they have a significant defense and attack bonus. You can see that the smaller blue square (the buffer, remember?) has now been completed, and it?s supplying those infantry with additional attack and defensive support, making them ready to take all comers. However, the downside is that as long as they?re fortified they?ll be unable to move or rotate. To attack a well-fortified Mechanized Infantry unit, you?ll need a good supply line, a number of strong well-organized attackers, and a little bit of the element of surprise.

On the top right you?ll see a number of yellow lines coming back from the enemy units from the direction of their base. These lines are those unit?s support lines. As long as they remain intact, those units gain an advantage with bonuses to attack and defense, and additional health and shield regeneration. However, if I were to move one of my units into an interception with those support lines, the enemy units would lose that advantage ? sounds like a good time to attack!

I hope this gives an insight into some of the neat things I?ve been doing. In the coming days I plan to make another post describing the process of how I decided on all of these mechanics, so stay tuned.

## How To Give a Rock A Personality

This is a post duplicated from the Digitanks website.

The problem with digital tanks is that they don?t have faces.

Tanks aren?t like cars. Cars have faces. Once you see it, you can?t unsee it. Why do you think Pixar had such an easy time putting faces on the front of their automobiles? It?s easy to instill a vehicle with a personality when it has a grille and two headlights. I?ve never even seen that movie and I still remember that tooth-faced redneck jalopy truck from the trailers. Just by looking at the car I can imagine how it talks and acts. That character speaks volumes without saying anything and already I?m relating to him, thinking about all the country bumpkins I?ve met in my life. Just by having a face, the human mind assigns anything a personality. But tanks just don?t do that for me.

Tanks though? Tanks have about as much personality as a rock. I?d really like my tanks to have some character in them. Some life. I?d really like them not to be just polygons on a screen. I don?t want players to think of them as just tanks, but as ?my cute little tankey buddy friends.? But, talking tanks is just crossing the line. Really, would you accept a talking tank? It works for cars, but it doesn?t work for killing machines. It doesn?t have to, though, because some of the most loved characters are ones that never talk. In fact, a common anecdote among writers is the ?less is more? mantra, and no talking at all can often have a greater effect on the reader than volumes of dialogue. The difference between a box and an Aperture Science Weighted Companion Cube isn?t how much it talks, but the amount of personalization that the player projects onto the object. Valve didn?t even set out to give the player an inanimate lovable friend that would stand the test of time and win all of the ?best incinerated sidekick? contests, but they succeeded so well with instilling personality into an otherwise lifeless object that here I am still talking about it, and the damn thing never spoke a word.

A long time ago I played a little indie game created for one of the LD48 competitions called ?Commies.? It was a fun little game where the player runs around talking to civilians to try to keep them from joining the ever-spreading communist plague. The civilians would occasionally emit icons above their heads to show their emotion, but if they interacted with a commie then they would eventually become one, and it was your job to intervene and set them straight. I talked to the author of this mini-game, and he said something that left an impression on me. I don?t remember what he said exactly, but it was more or less, ?Players will project a lot of personality onto a character given only a few cues.? It only takes one happy face floating above a civilian?s head for the player to think of the guy as having actual emotions. In the indie game World of Goo, the goo balls have little eyes and make funny ?Gamako!? expressions when you pick them up, but that subtle hint is enough for the player to treat them as living things, getting upset when they ?die? and wanting to save as many of them as possible. It?s much more effective to use subtle personality hints. Pokemon never say anything but their name, but everybody loves that little bastard Pikachu.

One of my favorite web comics is Girl Genius. It?s a long story about a girl who discovers she?s really a mechanical genius and can build amazing steampunk mechs in her sleep, which makes her a marked woman and she gets all caught up in blah blah blah, anyway, it?s a good story. One page in particular stood out to me because of its effective use of nonverbal communication. On this page a character named DuPree, who we know from previous episodes loves killing people, is put in charge of protecting the story?s antagonist from assassins. Due to entertaining circumstances she?s left unable to use her mouth, and the artist has her communicating using pictographs. It amazed me how effective this was. Suddenly a gag order is more efficient for developing a character than that character?s speech was. This was the kind of thing I wanted to try to take advantage of with Digitanks. My tanks couldn?t speak in words, but maybe they could speak in pictures?

It?s a problem, though. If a tank could speak in pictures, what would a tank say? A tank could be happy that you gave it a command to attack, but what would that be a picture of? A cannon firing? If a tank missed, what picture would be sufficient for displaying its disappointment? If a tank got damaged how would it picture its pain? I couldn?t imagine anything that would be satisfactory for me.

Of course, the solution is usually simpler than you imagine it to be. I was talking on IRC with a friend of mine, who commented that I was using a lot of smileys. I was feeling pretty silly at the time, and I had given her one too many smileys for her liking. They can come across as childish if they?re overused. I justified it to her saying, ?They?re a pretty easy way to communicate an emotion nonverbally.? That?s when it hit me.

It makes perfect sense that digital tanks would use text smileys to communicate. It all fits with the digital theme. The problem is integrating the smileys into their digital environment without them appearing out of place. My first try was with the cartoon-style word balloon that you saw in the post where I announced the demo download, but that didn?t really work at all. The classic speech bubble style looked too out of place in the digital environment, so this gray gradient (or shall I say, GRAYdient? lawl) approach is an incremental improvement on that. I?m also experimenting problems with people who think it says, ?D? instead of being a smiley, and I?m still considering how to approach that problem. I?m still experimenting with timing, with different smileys, and with the presentation of it, because I think that one of my biggest challenges will be presenting the smileys in a way that players accept it and use it as a channel for bonding with the tanks.

In all honesty, I?m the Doctor Frankenstein who instilled these tanks with their fabricated emotions, and even myself I?m starting to imbue them with actual emotions. Seeing a tank >.< (wince) when it gets hit almost makes me feel sorry for it. I resent my little tank buddies for zzz (snoozing) when I take too long to give it an action. I even share in the tank?s <3 (love) as he happily goes about executing the commands I issue. If it works for me then it has a good chance of working for others too. In time I hope to develop this concept so that the Digitanks become a beloved digital character to supplement their destructive prowess. The next time I get around to uploading another video, I?ll be sure to include the smileys so you guys can tell me what you think.

## Multiplayer Is Hard

This is a post duplicated from the Digitanks website.

Thanks to everybody who tried out the demo I posted this week. I?ve already started to receive lots of feedback on it and suggestions on how to improve it. Your input is hugely valuable to me. Some of the most common issues were the lack of good camera control and the lack of a good variety of tanks, issues which I?ll have resolved by the next demo.

Part of the original plan for Digitanks was to forgo multiplayer entirely. Multiplayer games are much more difficult to develop and test by an order of magnitude. There are a number of problems that need to be dealt with to develop multiplayer games. For one, data that is created, modified, or destroyed on the server needs to be sent to each client. Then, the actions of every client need to be sent to every other client. It also adds a layer of complexity to every feature in the game. In addition to the art, programming, usability and testing that every feature needs, these all need to work just as well in a multiplayer environment as a singleplayer one, which requires much more additional work, and commonly results in a headache and a hernia. Plus, I really just don?t enjoy writing multiplayer code so much. So, I decided to just leave multiplayer out of the equation to get Digitanks done faster.

Of course that plan had to change. As I started playtesting the game, I asked each playtester, ?How important to your purchase of the game is an online multiplayer feature?? and the number of respondents who stated that they wouldn?t purchase the game without online multiplayer stands currently at 88%. (n = 13) This is isn?t true for all games, for example I don?t think many people would require World of Goo to have multiplayer, but it seems that it?s very important for the kind of people who enjoy Digitanks. The recent Trine postmortem mentioned that they think they would have sold something like three or four times more copies of the game had it included a multiplayer feature.

Well, that?s a tough call for me, since multiplayer can be such a difficult beast, how can I justify the extra amount of work that?s required? I built the engine myself because I assumed that I wouldn?t need multiplayer, but now I?m faced with an interesting choice. I have to either accept reduced sales without multiplayer, or figure out a cheap and effective way to add multiplayer into an existing game. I have the advantage of the fact that a turn-based game is not as difficult as most to write multiplayer for, since there aren?t really many realtime events that need low-latency or immediate handling, so I likely won?t have to deal with multiple threads or synchronizing entity data across multiple clients if I can just inform each client of the other?s decisions.

The first step is to look at a number of multiplayer libraries to see which one is the most appropriate for me. To Google! The first result for a search on ?game networking library? is a tool called RakNet. It looks like a well-built, professional game networking library. It?s used in a lot of major game studios according to the website, and is free for indie game developers. I like the looks of this tool, but the license agreement gives me some pause. For the record, there are two types of license agreements that scare me: proprietary license agreements and GPL. LGPL is annoying since it requires dynamic linking, but I use one or two LGPL libraries with no problem (DevIL and SDL if memory serves) but I can deal with it. The problem with proprietary license agreements are that it?s tough to tell what?s really in them without a lawyer, and they can change at any time since they?re mostly designed to protect the authors. So, we?ll hold RakNet on the back burner and see if there?s anything else we can use.

GNE is the next option. It?s LGPL, putting it in much the same category as RakNet. The problem I see with both RakNet and GNE is that they?re a bit too high-level for me. I don?t want a tremendous amount of overhead with whatever tool I use, and both of these tools seem like they have a very high-level object-heavy way of doing things that I don?t necessarily agree with. Although I love object-oriented development, I tend to shy away from libraries that expose an object-oriented interface, a simple well organized series of c-exported functions is more desirable. I?d prefer something simple that I can plug in and get working quickly. The thinner my networking level is, the easier it will be to resolve problems I encounter with it. So I keep looking.

There are a couple of other libraries in the search result, but they?re all either outdated or just plain crappy. However, scouring some forums and mailing lists reveals a small library that everybody says good things about named ENet. It didn?t turn up on the search for game networking libraries, since nowhere on its front page does it even mention that it?s intended for games. Whereas the other libraries handle object data replication and things like automatic updates (stuff I don?t really need) all ENet does is provide a simple and lightweight wrapper over the operating system?s networking. That works out great for me, since using OS-specific calls is out of the questions (we do eventually want to target other platforms!) and the additional features that ENet provides don?t add any significant overhead or programming complexity.

So I have my library all picked out. All I need to do now is figure out how I?m going to structure my code most efficiently. The key here is time, how can I get this done fast? My players demand a multiplayer experience and I want to give it to them, butI want to do it in a way that will cost me the least amount of development time. I basically have two options.

1. Spend a lot of up-front time making a data replication system that automatically sends all data for an entity over the network to every client.
2. Make a simpler system that will take me a day or two, but might be a little bit more kludgy to use.
Choices? I?m always a fan of spending a little bit of time up front in the planning and tools development stage in order to speed up the actual development work. It?s a good plan and the time spent laying foundations and doing ground work usually pays off in the end with reduced development time, but that only applies to tasks that will be repeated multiple times. An IBM engineer once told me that if you?re going to do it once, just do it, but if you?re going to do it more than once, automate it. The sentiment is correct, but I don?t know if it?s really a time-saver to automate something if you?re going to do it twice. To me, you automate something if you?re going to do it 200 times, but I?m not sure Digitanks is that kind of project. Once I get the basic tank movement and interaction networking code in place, there?s not really much more that will need to be networked. Digitanks will be released by the end of the year and I?m likely the only person who will be programming on it between now and then, so there?s no need to automate everything.

The plan is to use each of the important functions in the game as proxies for network activity. For example, any time the FireTank() function is called, the networking layer will replicate that message to each client connected, so that same function is called with the same parameters on every client, and every client will fire their tanks. The system relies heavily on making sure that the same functions are called on all clients to retain the same state of data across all instances of the program. This design means that a simple programming mistake can make it easy for one or more clients to get desynchronized from the rest, so I?ll have to be vigilant in making sure that I don?t leave anything out. It?s been pretty tough to put all of that in place, but the results are actually pretty promising. I?m five days into it and already I have this to show for it:

What you see here is the same scene being rendered from two different angles in two different clients. Some of the tanks have been moved around and they all have aiming targets and different values for their power usage, and as you can see all of that data is consistent between the two clients. Multiplayer can be tough, but with a simple enough system, I?ve lowered the complexity to a manageable level. End result: You can expect Digitanks to feature online multiplayer when it?s released in September. I hope it sells a lot of copies!

## The Moment We've All Been Waiting For

This is a post duplicated from the Digitanks website.

I'm proud to announce that there is now a small demo of Digitanks available for download. If you download it you can make many Digitanks very happy.

This demo is really just a prototype. I plan to expand it in the future with more tanks, more weapons, and a base-building aspect, where you can build a digital base and conquer your enemy's bases. I'm designing the battle system so that it's very tactical (you can see some of that in this demo) but there will also be a good strategy element to the game. I've set a deadline for myself of mid-September to complete the entire game.

If you enjoy the demo and want to see it made into a full game, there are many ways you can help us out. I should now be able to resume my regular update schedule of 2-3 times a week.

## Getting Ready For The Competitions

This is a post duplicated from the Digitanks website.

I'm hard at work last couple days getting Digitanks ready for the competition that I mentioned I would be submitting the game to. That deadline is Tuesday but I'm going to have everything wrapped up by Sunday night. There's also the IndieCade deadline on the 20th and the Intel Visual Adrenaline deadline on the 21st, and I'll be submitting to those as well. I don't expect to win, but I am hoping to gain a little bit of exposure for the project. I've done a little bit of final work on improving the visuals that I would like to share with you:

Here you can see the projectiles with one of the new additions. If you look carefully you can see wireframe mesh looking things get shed from them as they fall. (They are more apparent when everything is in motion.) It's a very subtle effect but it's a funny story how I got the idea to do this. When I was writing the particle system (I couldn't find an appropriate freely available one) I accidentally got part of the material rendering process wrong, and the particles all started using the same texture, the powerup prism texture. Those triangular prisms you see in that screenshot are powerups, and they're made by having a wireframe-like texture on a simple prism model. That texture bled over to the particles for the projectiles, and combined with some hardware filtering artifacts made them look rather interesting.

So in any case, since I'm focusing on getting everything ready for that competition, updates will be scarce. However the good news is that after everything is all submitted, I'll be uploading a public demo so that everybody can get a chance to see how the game is progressing. After that, it'll be off to the races designing and developing more tanks, weapons, and a base-building system.

## Your Idea Is Too Big

This is a post duplicated from the Digitanks website.

Before we go into why your idea is too big, let's first take a moment to smell the roses and listen to the birds singing, the wind blowing, and the sound of tanks blowing up, because I just added the
">first slew of audio sound effects to Digitanks.

This video also features a composition by Jack Menhorn, who is not only a swell guy but a great composer. And now back to our previously scheduled article.

In my years before becoming a professional game developer, I spent a lot of time doing contracting for local companies. I was basically a gun for hire. I would come in, solve a company's problem, get paid and take my victories to the bank. It made me some decent money (while the economy was still good) and afforded me a lot of free time to pursue my hobbies, like game development. One of my largest clients was a man who owned a small company that sold a software toolkit. We'll call him John. John's tool was a pretty good tool, and John made most of his money by supporting his tool and bringing in contracts to develop his client's applications that use that tool. It made a good living for John, and I learned a good deal about software development from my time with him.

Only problem is, John's eyes were much bigger than his mouth. Every time his client asked him to make a modification to their products, John would get very excited and ideas would start spewing. He would look at the moon. I can't say John is alone there, I've worked with a lot of people like that. In fact I have to give him credit for that, because his big talking gave him the ability to pull in a lot of clients. It's how he makes his living, and he's very skilled at that. When it came to planning the actual work, he would plan a himself mountain. Problem was, John was just one guy, but he'd assess that mountain to be the size of a molehill, and he'd plan his time accordingly. It made for many deadline slips and upset clients. He'd also go out and buy lots of equipment for the work, which turned out to not be necessary later.

John was a great guy who did his job well and I learned a lot from his advice. I also learned a lot from his mistakes. One of John's vital mistakes, and the reason I eventually stopped working for him, was that his shoes were too big.

### Smaller shoes make for lighter walking

I'm a credits person. I like to see all of the people who were involved in the production of a piece of entertainment. It also gives me an insight into who's who in the industry. I sat through the entire list of credits in Avatar, after the entire theater was empty save me and my friends. I learned about Danny Elfman because I recognized his name from the credits of multiple movies that I had seen. I learned who David Jaffe is because I saw his name in one of my favorite games, God of War. In God of War 3, I stared, mouth agape, at the list of credits that seemed to run forever, including all of the outsourcing third-party development houses. It's become increasingly difficult to retain a mental list of important people when the credits list runs for fifteen minutes. Sony can afford to have a credits list that long though, they have the wallet to foot the bill. Fact of the matter is, Sony has big shoes.

While that credits list was running, I thought about the team that I was working with at the time. It was a seven-person team. I wasn't even paying any of them. How was I ever going to make something as awesome as God of War 3 with a team that small? I wanted to make the best game ever, I had big shoes, and my feet simply didn't fit. This was a real crisis for me, because the advice I've always been given is, do the best. Be the best. Second best isn't good enough. "Close enough" only works for horseshoes, hand grenades, and really big bombs. Nobody wants to pay for the average quality widgets, people only want to pay for the highest quality widgets, so if you want to be where the money is, you have to have the highest quality widget. Guy Kawasaki said, paraphrased, that you should never do anything if you're not doing it better than anything that's out there already. (Which makes me wonder why he's doing Alltop.)

Well I think Guy Kawasaki is wrong. It's easy for him to say that kind of thing because he's famous and it sounds good. Guy Kawasaki has big shoes. His thinking works very well when you have a multi-million dollar budget and dozens of people on your team. It doesn't work very well when it's just yours truly. One person can't possibly hope to reach to a place where these millions of dollars and hundred-man teams haven't reached already. Can they?

I'm not saying to think small. A person should think big. But more importantly, a small developer with a small team should realize that they have these limitations. But you can turn these limitations to your advantage. When our medium was small, games were largely created because of the physical constraints of the medium, which forced people to be creative. Mario is a plumber in red overalls because that was the easiest way to convey his character. Final Fantasy developed its turn-based battle system because that was the easiest way to program battles on a Famicom. In modern times we no longer have these limitations, but if we impose them again on ourselves, we can find creative ways to lighten our workload.

In Digitanks, my tanks hover around because I don't want to animate tank treads and I don't want to codify the tank-ground collision mechanisms. My terrain is randomly and procedurally generated so that I don't have to spend time making the tools for level development. My visual style is a simple Tron-like theme so that I can just make things glowy and they'll look good, and I no longer have to worry about realism or high visual fidelity. I've cut so many corners, but in being creative I've reduced my workload without sacrificing the quality of the game.

This is the classic tradeoff that every manager is taught: Cost, speed, qualities -- pick two. You can do it cheap and fast, but it will suck. You can do it cheap and good, but it will take a long time. You can do it fast and good, but it will cost a lot. Let's apply this to independent developers. Cost is pretty much fixed, indie developers have very little money. Speed is also fixed, a 6-12 month time frame for most indie games. That means "qualities" is going to suffer a great deal. We have to accept this fact. There's nothing we can do about it, it's a law of nature. It's simple physics. You will never be able to increase quality without spending more time or spending more money, and indie developers have neither of those two things. But we can find a way around this rule by cutting corners creatively, and finding a way to decrease the scope of a project without impacting the quality. In other words, finding a way to make your shoes smaller.

Moral of the story: Use your small size to your advantage.

### Smaller smaller smaller

I think it's important to quantify that "qualities" in this case isn't the same thing as quality. It's not a "Degree or grade of excellence" as the answers.com dictionary defines it. Rather, it's the scope of the project. The scope combines both quality and quantity, and all other things being the same, you can't add more of one without taking away from the other. You can make an expansive world with huge mountains and valleys and plains that stretch forever, but you'll pay for that quantity with terrible quality. Your mountains and valleys will be more like molehills and ditches, with the same grass sprite in every square mile because that's all you had the budget for. Or, you can focus on one square meter of land in its most qualitative detail. You can make that one square meter of land damn good-looking in the time you have, but it's still only one square meter.

The key to indie games is understanding what you can cut out in quantity to leave as much room as possible for quality. How much can you reduce the scope of your project so that you can increase the quality? I've spent countless hours pouring over my project plan, finding things that I can cut out. It doesn't matter what you are trying to do, there's always a way to make your game smaller.

If you read any advice to indie gamers you've heard this said before, but this time you'll hear it and it'll have new meaning: Find one thing that makes your game fun and iterate on it. The reason people say this is because indie developers can't afford to find ten things that make a game fun, like the AAA studios do. Focusing on your one fun element and making that as nice as possible is the best way to get the most bang for buck out of only a little bit of input work. Whatever is superfluous in your design, take the opportunity to cut it out. You'll reach your goal sooner, and your overall quality will increase, because the remaining features of your game will be more polished. The best way to do that is to make your work smaller.

Moral of the story: It can always be smaller.

### Baby steps

A good friend of mine once endeavored to start a web comic. He used his deployment pay from the armed services to invest in this new venture. You may not know this if you're not close to someone who's spent time in the military, but those people make bank, as they put it. They spend a lot of time in Crazystan or wherever, where they get paid all of these bonuses that they can't spend because they live on base and they're fed for free. So, when he got home he bought a new car (cash) and then went about investing in his project. He paid a large sum of money to an artist up front, he ordered a booth at a major convention, he spent a lot of money on building his enterprise. And hey, it was a damn good idea, my friend is an excellent writer and the artist he signed on was a fantastic artist, and they had a beautiful website. From a technical point of view, everything was set up for success and good to go. Six months later, the artist was forced to quit due to unforeseen circumstances, and my friend was out of all of his money. I'm sure you're not surprised at the result of that story, and honestly neither was I. I told him not to do all that stuff. Spending money on something that's not making any money is always a bad idea.

I have to admit that I've fallen victim to this kind of thinking before. It's easy to say, "I'll buy this expensive equipment now because it'll let me make a lot of money later." Well, it doesn't really work that way, because now you have a business plan that involves spending a lot of money up front in exchange for a questionable future revenue stream. That works for CEO's and VC investors (sometimes) not for indie game developers. For little people like us, it results in us losing our hats after we've spent ourselves into oblivion, and it's a well known fact that any plan where you lose your hat is a bad plan.

Now I have a better plan: Don't spend any money until you are making money. Not only does this rule prevent me from spending money on things that I really don't need, it also forces me to think more critically about how to monetize my ventures. It helps me figure out how to reduce the amount of effort and time it takes to reach a monetary goal. In my mind, you really can't make those steps small enough. The smaller your steps are, the easier they are to enact, the more celebrating you get to do for achieving your goals, and the faster you get to where you're really going. Every problem can be broken up into a number of smaller steps which can be taken one at a time, and each of those smaller steps can be broken up into individual tasks. Does your plan to make money involve not getting paid for 9 months? Well, that's too long. Let's think of a new plan that makes money in six months. Then let's take that plan, cut out some of the more complicated things, reduce the scope, and make it work in four months. Now that sounds like a better plan.

Moral of the story: You have to crawl before you can walk.

### Stand on the shoulders of giants

Here's the list of libraries that I use in Digitanks:

OpenGL
freeglut
freetype
ftgl (text rendering)
glew
SDL_mixer (sound - as of this week!)
glgui (internal - my opengl UI library)
common (internal - common functions shared by all my projects)
raytracer (internal)
modelconverter (internal - loads models)

Part of the reason I've been able to get Digitanks to the point it is so fast is that I used all of these libraries that I had lying around from previous projects. I didn't have to write a single one of these functions by myself. My new sound engine took me all of an hour or two to write, since SDL_mixer did all of the hard work.

Here's a list of freesound.org authors whose work I sampled for my sound effects:

AlienXXX, batchku, Chris Weaver, cognito_perceptu, CosmicD, daveincamas, dkristian, Halleck, HardPCM, HerbertBoland, ingej, ingeos, Koops, koostix, Lunardrive, Matias.Reccius, melack, metamorphmuses, Microscopia, Nbs Dark, Ohrwurm, Percy_Duke, PhreaKsAccount, ReWired, rutgermuller, sandyrb, Syna_Max, swelk, timlaroche, themfish, volivieri, 833_45

You think I'm about to go out and record all of those samples by myself? Hell no! I'm giving them all attribution in my game's credits of course, because they saved me a huge amount of time. In two days I added 9 high quality sound effects to my project, plus all of the supporting code. I can work at that kind of pace because I've managed to use the resources of others to my benefit.

Moral of the story: I need to play Shadow of the Colossus again.

Well I suppose I should wrap this up. As always, please tell me your thoughts, I'd love to hear what you think and how this article has helped you.

## Digitanks - The Early Bloomer

One of the first visual improvements I made to Digitanks was to add bloom. Ah, bloom, the often used and eternally abused layman's visual enhancement. It makes a simple-looking scene look more sophisticated by taking out that embedded polygonal look and imbuing the frame with gradients and natural, circular shapes. It's a relatively easy way to upgrade your game's visuals from 1998 to 2008 with not too much development effort. But, if you overdo it, it can look nasty and terrible.

One of the most notorious abuses of Bloom was in the original Fable. This game put bloom everywhere. Every bright portion of the scene got bloom on it. The problem is, that's not the way light works in real life. In reality objects will gain that halo if they have a very bright light falling on them, or if they're emitting light. In Fable, they made things glow just because. The guy's clothes, the sidewalk, the rocks and leaves, everything was glowy and it gave me a headache after a while. It was just uncomfortable to be looking at all of this glowy crap. I suppose it looks nice in that screenshot but not so much when you're playing the game.

In general, the rule of thumb you want to use is that if the object is either emitting light or a very, very bright light is falling onto the object it can get bloom. If you look at a stoplight at night, you'll see a red glaze around the light. (Hopefully you won't see a green glaze around the light, because that means you need to hit the accelerator.) That glaze looks really neat in video games. But you'll never see that glaze appear on the sidewalk. On a very sunny day in the desert, you might see this glaze on a white surface that's next to a dark area (say, the entrance to a building?) but you won't see it on the ground or on people's shirts.

I suppose you can't much blame Fable for getting it wrong, it was one of the first games to implement bloom. They were going for a semi-realistic, if not stylized environment where bloom simply doesn't fit all that well. It was a new technology, and they simply didn't know what the most effective use of it was. The game that I have to give credit to for the correct use of bloom is Tron 2.0. The rules I just explained to you about regular objects glowing? Well Tron 2.0 threw that out the window. They could afford to do that though, because they weren't going after that semi-realistic style. The primary difference is that Tron 2.0 has mostly dark backgrounds, so the glow of the bloom doesn't wash out the image and cause damage to my vision. Tron 2.0 even has more bloom than Fable did, but it ended up working better because of the environments of the game.

More recently in video games the technology of "high dynamic range rendering" has percolated into most AAA titles. This change has provided a much better use of bloom for photorealistic scenes. In HDR rendering, the scene is rendered with an infinite (well, almost infinite) range of light values, from totally dark to bright as the sun, and then a small slice of those values is removed and rendered to the screen. Parts of the scene that are too dark in that slice are rendered as completely black, and parts that are too bright are rendered as completely white. Bloom is used to highlight the parts of the scene that are overexposed and completely white. This is much closer to what happens in actual photography and with the human eye. One of the first games to use HDR rendering was Valve's Lost Coast demo, and the benefits of using bloom in this situation were clear. Lost Coast looked fantastic, and HDR is now a standard feature in all Valve games. The use of bloom this way in HDR matches what we usually see with our eyes and follows the rule I put forward before - only light sources and very, very bright surfaces receive the glowy effect.

So getting back to Digitanks. Bearing our examples in mind I set forth to add the perfect amount of bloom to Digitanks. At a technical level, bloom is just a blurring of the bright portions of the scene. The first step is to render the game scene to an off-screen frame buffer. Then, a filter is run over the scene so that the bright portions of the image are isolated. Lastly, the blurred images are superimposed over the final image. Let's take a look at the initial scene that we'll be dealing with. We have some bright elements like the shields, combined with some darker elements. Overall the scene is fairly bright. The first thing we need is a shader that passes the bright elements of the scene through while omitting the dark elements. For this I wrote what I call a "bright-pass" shader. Here's the glsl sources for it, non-technical people can just skip it:
 uniform sampler2D iSource; uniform float flBrightness; uniform float flScale; void main(void) {     vec4 vecFragmentColor = texture2D(iSource, gl_TexCoord[0].xy);     float flValue = vecFragmentColor.x;     if (vecFragmentColor.y > flValue)         flValue = vecFragmentColor.y;    if (vecFragmentColor.z > flValue)         flValue = vecFragmentColor.z;     if (flValue < flBrightness && flValue > flBrightness - 0.2)     {         float flStrength = RemapVal(flValue, flBrightness - 0.2, flBrightness, 0.0, 1.0);         vecFragmentColor = vecFragmentColor*flStrength;     }     else if (flValue < flBrightness - 0.2)         vecFragmentColor = vec4(0.0, 0.0, 0.0, 0.0);     gl_FragColor = vecFragmentColor*flScale; }

First, this shader finds the brightest value of each pixel. If the pixel is brighter than flBrightness, then it saves the value. There's a slight ramp near the cutoff point where the value is ramped in softly so that abrupt changes in pixel brightness don't cause lines. Three copies of the scene are made at three different resolutions, and the shader is applied to each copy at three different intensities. This is done to take advantage of the hardware acceleration's very fast image scaling operations. The highest resolution takes only the very brightest portions of the image, and the lowest resolution receives more less-bright portions of the image. This is done by passing progressively lower values into the flBrightness uniform in the shader.

One important thing to note about this bright-pass shader is that it doesn't take the average pixel brightness, but rather the brightest color value. That is, it doesn't take (r+g+b)/3 but rather looks at the brightest of the three to determine if it passes the filter. That's important, because it allows bright solid colors to pass. For example, the tanks in the game all have bright solid colors, in this case solid blue. Blue ends up having a bright value, but red and green have values of 0. If we had taken the average, we would have gotten (0+0+1)/3 = 0.3, which wouldn't have passed the filter. However, since we use only the brightest pixel to test, this bright blue value passes.

Once we have our bright scene portions isolated, then we can blur them. Each frame is blurred using a simple gaussian filter. I won't post the shader for that since it's mostly covered rather well in other places, but you can see the results. Just like before, the blur is applied to each of the three different resolutions. Since the lower resolution frame gets the same blur as the higher resolution frame, its blur is actually much more pronounced once it gets resampled up to the final image size.

The next step is to combine these three blurs together into a single frame. This is done using additive blending, which is fantastic for creating effects that seem to be glowing. The values for brightness were chosen carefully so that the parts of the scene that I wanted to stand out can be seen clearly. For example, the tank that has his shields up the highest (it has more energy for its shields since hasn't moved as much as the others) has a very bright bloom on its shields, while the tank with less shields has barely any bloom on his shields. So, the bloom actually helps to highlight the shield strength of the tank. The movement and range indicators also get bloom highlighting on them, to help them stand out from the terrain shader.

Lastly, the bloom gets combined with the original scene, again with additive blending.

That's it! The scene looks much more lively now. Notice the slight haze around the targeting trajectories and the brighter targeting rings on the ground, and the bright shields bleeding their energy into the surrounding terrain. The terrain also has gained a warmer feel to it. It complements the scene, and it doesn't get in the way, I'm pretty satisfied with this bloom.

If you want more technical details on how to implement bloom with glsl, there's a great tutorial on Phillip Rideout's website. Thanks for reading!