Game Dev 3: Voxel Terrain and Perlin Noise

I meant to post this about two weeks ago. I've been working on getting basic cube voxel terrain up and working. So today I present to you: Perlin noise! The colors present chunks of voxels that are being generated and displayed. I'm using 2D perlin noise to act as a height map.

You may notice I've got a FPS meter. I've created a basic font system from scratch that will let me write to the screen dynamically.

Each chunk is 16x16x128 voxels, and there are 64 total voxels, each colored with one of the 64 colors I'm using from a basic 6-bit color palette.

In other words... this is a fairly complicated scene! I did basic occlusion culling by marking voxels that were completely surrounded by neighbors. Essentially, I "hollowed" out what you see here. I also set up Face culling. This scene is about 10 million triangles, meaning that I am getting about 770 million triangles a second on my NVIDIA 660 GTX. Not bad!

On my TODO list: make some interesting terrain using layers of noise, include random seeds and enable dynamic loading of chunks from disk!

Game Dev 2: Voxel Terrain Generation

Voxel terrain generation is all the rage these days. Specifically, building a world out of cubes (either textured or otherwise). There are a number of games doing this, with the most well-known being Minecraft. Games currently in development such as Cube World and Timber and Stone also use them. Thought I'm planning on a different graphical aesthetic as opposed to using cubes, I'm still quite interested in the idea of having volumetric data for my terrain. This enables destructible terrain and generally makes procedurally generated worlds a bit easier to think about.

Perhaps one of the most interesting design decisions with using voxel terrains relates to data storage. Specifically, how to design your worlds such that the save game (world save) files dont get too big.

After much reading, the general design of voxel worlds seems to be as follows:

• A Voxel: A cube, often of unit length (e.g. 1) on each side.
• A Chunk: A set of voxels in 3 dimensions. In Minecraft, a chunks is 16x256x16 (xyz) voxels.
• A Set of Displayed Chunks: The active chunks that should be displayed to the screen, which essentially sets how much of the world can be seen at any given point in time. The number of chunks is usually tailored to match the users GPU configuration.
• A Game Chunks: The set of all active chunks at which the world is "alive". Used for game logic, NPCs, etc. This is usually much larger than the number of chunks being displayed.
• A World file: The set of all chunks in the entire Map. This is usually the set of visited (or seen) chunks in Minecraft. When the player is exploring, new chunks are generated on the fly and put into the world file.

So this leads to a bunch of interesting design decisions that impact the world size (and file size)

• Big decision number 1: How big is a Voxel in game dimensions, really? Will it be 1 meter on a side? 2 meters? 4? 8? Minecraft chooses 1 meter on a side.
• Big decision number 2: What is the max height (Tallest mountain) and the lowest depth (lowest cavern) of the map? Typically, this means the chunk y-dimension. Minecraft is 128 voxels high for each chunk (256 meters). 
• Big decision number 3: What is the maximum area of each world map? Minecraft is unlimited (essentially), but realistically how big do we want it for a game file? This essentially means managing what the max number of chunks in the x and z dimensions is.

Now for a thought experiment about the feasibility of representing the entire earth in voxel terrain using actual sizes.

• Assume that each voxel is 1 meter long on each side and storage is 1 byte.
• Assume the tallest point in the world is Mt Everest (8900 meters) and deepest point is the Mariana Trench (10,911m) -> y dimension in voxel map should be ~20000 meters (voxels high).
• Assume that the Earth is 510,072,000,000,000 square meters. If turned into a square,  22,584,774 voxels long per side.
• Conclusion: representing the entire earth as a (22,584,774 x 20,000 x 22,584,774) voxels will take - 8.8 EXABYTES of memory (9278156 Gigabytes).

Wow! So what did we learn... other than it would be impossible given today's technology to ever create a scale model of planet earth with voxels? Well, if we think a bit more, we realize how silly the thought experiment is that a game would doesn't need that much realism. A player could never visit all of those places in the world (even in an MMO).

So how big do we need? Well I suggest reversing the problem and starting with our ideal file size. My opinion is that the file should be between 50MB to 5GB in size, with a target of 100-500MB. This is not unreasonable, as I've heard of Minecraft savefiles taking up to 2GB before. Keep in mind that we don't need to have that entire file loaded in RAM, only sitting on the hard drive.

So, if we stick with the 256 height (a la Minecraft), we end up with a 4,579m x 4,579m game world at 5GB (Roughly the size of Skyrim), or a 452m x 452m grid at 50MB. So, we can see that using 1m voxels can meet our needs just fine.

A final thought: Generally speaking, a lot of the world is filled with large regions of similar types of blocks. In other words, block types come in large groups. Many designs do not take advantage of this fact, when there is a great opportunity for optimization. The most straightforward optimization may very well be lossless compression. There are a number of options here, but I think that dictionary-based algorithms seems like a good start. It optimizes for the large regions of similar blocks. I may investigate these optimizations for myself later. If I do, expect a post here. 

Learning from other game devs 5: Marketing your indie game

I've been trying to understand the various options to market an indie game. Now, I'm nowhere near that stage in my game development, but I also am no salesman by training and certainly have a lot to learn in the area of marketing.

I've read quite a few things online and listened to quite a few podcasts where marketing is discussed. It turns out there is not silver bullet; there really are several different things you can do to help promote your game. Many people have suggested doing everything you can to help boost sales.

I've tried to enumerate most of the major options below. Most of these options should be done when the game is either in alpha/beta or is about to be released. One exception is Social Marketing, which should be started as soon as you have a prototype.


Social Marketing (Game Facebook site/Blog):

• Idea: Have a Facebook fan page or blog about your game. 
• Potential Exposure: Low to Medium. Continual.
• Crowd: All demographics. Mainly those people that already know about your game.
• Cost: Time to update sites regularly, respond to user comments.
• Side Benefits: Place to put up video/pics of game. Ability to contact fans of Facebook page for alpha/beta testers. Ability to track the web traffic of blog.
• Risk: If not updated regularly (at least once or every few weeks), fans can get irritated.

Get booths at trade shows:

• Note: This is pure opinion based upon my own reading. I have never been to a trade show.
• Idea: Have a booth featuring your game at a trade show like PAX, etc.
• Potential Exposure: Low. One time.
• Crowd: Hardcore gamers and other game devs.
• Cost: I've heard $3000 or more just for the booth. Adding in hotels and airfare up to $5000.
• Side Benefits: Potential to win an game award at the conference (if they give them out). Get valuable feedback from other game devs, easier access to publishers.
• Risk: Could be a complete waste of money and time. Not everyone does this.

Kickstarter:

• Idea: Start a Kickstarter campaign. Ask for a moderate amount of money... the main point is not to try and fund your development but rather advertise.
• Potential Exposure: Low to medium. Short-term.
• Crowd: Mainly hardcore indie gamers and internet users that pay attention to Kickstarter. To reach a larger majority of gamers campaign likely needs to go viral.
• Cost: Kickstarter takes a cut of the money (I believe), and you're on the hook to develop all the goodies (t-shirts, posters, etc).
• Side Benefits: Potentially gain a strong group of initial fans. Get alpha and beta testers to give feedback, do bug reports.
• Risk: Failed campaign is a huge blemish on your record surely to be mentioned any time to give an interview, etc in the future.

Give demos to YouTube Let's Players:

• Idea: Give demos to popular YouTube gaming channels so that millions of potential gamers can see it in action (And played by their popular
• Potential Exposure: Low to Extremely High. Short-term.
• Crowd: (Potentially) Millions of gamers from every demographic. I believe that the worry "Only kids under 14 watch YouTube" is a complete myth.
• Cost: Zero money. (See Risk)
• Side Benefits: If YouTuber loves game and decides to do a full playthrough, you get even more exposure.
• Risk: Youtubers are merciless and could make fun of and mock your game in front of millions of people. You had better be sure that the game is completely ready and that 100s (if not 1000s) of people already love it.

Get reviews from Gaming websites

• Idea: Give demos to gaming website so that they can review your game. A good review will push you up the metacritic page and be listed prominently on some distribution platforms like steam.
• Potential Exposure: Low to Medium. Continual. Reviews exist forever.
• Crowd: Hardcore and Indie game players that scour gaming sites looking for the next best thing to play.
• Cost: Zero money. (See Risk)
• Side Benefits:Your game could win an award (PC Gamer Editor's Choice), and can make the front page of the site for a few days. Game could go Viral.
• Risk: Similar to YouTubers. You must be confident your game is great, otherwise bad reviews will cause you to lose tons of sales. In other words you likely need a 75+ review minimum.

Do interviews with mainstream Media (TV like G4, print magazines)

• Idea: Do interviews about your game and have
• Potential Exposure: Medium. One time.
• Crowd: Mainly hardcore gamers. 
• Cost: Unknown. Very difficult to get these.
• Side Benefits: You're on TV, yay!
• Risk: TV may not give you very much exposure, as a person may need to be watching at a particular time on a particular day to see anything about your game.

Hire someone to market the game

• Idea: Pay someone that knows what they are doing to help you do all the above things. These people often have connections to help get interviews and game reviews at the major internet outlets. 
• Potential Exposure: Low to Medium. Short term. You are limited by how good and how much work the person puts in.
• Crowd: All demographics of gamers (Potentially, depends on the person hired). 
• Cost: I've heard $2000 to $4000 and up, depending on the amount of help needed. Note this does not include additional costs such as attending trade shows, etc which the person you hire may suggest doing.
• Side Benefits: The other connections the marketer has (such as other game studios they represent) and advice from the marketer themselves could give advice on things such as what features to add into your game or payment models (one-time, virtual currency, monthly, etc).
• Risk: Hiring a person doesn't guarantee sales, and any success really depends on how many connections the person has.

And that's the list so far. I think one thing that is definitely related to these options is getting a great distribution platform like Steam to sell your game. What do you think?

Learning from other game devs 4: Time management

Identifying and understanding other indie game developer's habits can really help improve your own game development. One particular habit that has been on my mind lately is time management.

Essentially, there are two types of indie game developers: those that develop games full-time, and those that develop games it in their spare time outside of a full time job (or studies, etc). Personally, I fall into the second category. You would think that a hobby developer wouldn't be able to learn much about time management from a full-time, but you would be wrong.  :)

Brendon Chung of Blendo Games is the developer of the successful Atom Zombie Smasher, Flotilla, and Gravity Bone (I highly recommend taking a look at all of those games). He mentions that he stays productive by focusing intensely for 30 minutes at a time when he is actively developing. That may not seem like a lot of time, but he swears by it. The key is to steer clear of all distractions (texts/emails/phone/news/TV). Just code. I think this hits home for me. I can hit stretches of hours when I'm "in the zone" with coding, but when I get stuck, I end up browsing online... wasting tons of time. One suggestion I think is helpful is to keep a timer. Try to go 30 minutes without any distractions.

The clear message I've heard from dozens of hobby developers is "Put the time in". You don't have to go to far to see how productive successful hobby developers are. We all need to learn how to develop good habits and put the time in. I personally think its easier to code a little everyday, rather than have epic coding sessions on the weekends. It becomes a habit if you code everyday, particularly if you do it at roughly the same time each day. For me, that means in the morning when I wake up, or a night before I go to bed.


Just remember, be a little better today than you were yesterday!

Game Dev 1: Choosing a color palette

I've been playing around with some ideas for a 3D game, which has forced me to think about art style a little bit. Though I'm not sure what type of level of modeling/animation I what to do, I think I've decided on one initial goal:

I want to do 8-bit color.

Why 8-bit? What does 8-bit really mean? Will it be true color from a changeable palette?

The why: I'm no artist, which likely means that my modeling and animation will be primitive. Given that, I feel pushed in the direction to simplify everything. Using 8-bit color seems to lend itself well to establishing a consistent style. 32-bit color (even 16-bit for that matter) is not going to be terribly useful. Will I really need to differentiate between that many red things? I should be able to do that anyways via lighting and other shading.

As a side note, in many ways I feel the same way about textures. If I have a low poly model and stretch textures over it, that can turn out quite bad. Best case, my graphics look circa 1995. Worst case, it looks plain hideous. Using textures may turnout to be somewhat of a risk, especially when considering that I'll likely have to make them myself.

The what: 8-bit can be interpreted a number of ways. For example, for 8-bit true color we can have 2 bits per channel (red, green, blue, alpha) which results in 64 colors. or 3 bits red, 3 bits green, and 2 bits blue which results in 256 colors. These are the two standard ways of doing things.

As an alternative, I can switch to using palettes instead. What this means is that I can pick a set colors to use from the space of 32-bit. For example, I could choose a set of 256 purely red colors (i.e. no green or blue). Choosing a palette enables me to pick several different color schemes for different parts of the game. As an example, I can choose of 256 colors for player models, another set of 256 for terrain, and another set of 256 colors for items.

By now you're saying "Wow, 64 colors? How useful is that??". Let me respond with a huge grin and list off some old school consoles and how many colors they can display.

NES: 25 colors (picked from a possible 56 colors)
SNES: Up to 256 colors (From a possible 32768)
Sega Genesis: Up to 64 colors (From a possible 512)

I might be showing my age here, but I remember Sega Genesis games having amazing color... and they only have 64 on the screen at one time! Go watch games like Sonic the Hedgehog on Youtube if you don't believe me.

The plan:

I'm going to try to do 8-bit color with an alpha channel, for 64 total colors. There will be no palettes whatsoever. Pulling from the public domain, here is a picture of a parrot rendered with 64 colors, and the palette of 64 true colors I can support:

Take a look at the parrot and tell me that doesn't look great! 64 colors in all their glory!

And finally, here's a shot from the engine I'm working on for my game showing off 64 colors. Note that there is still some tweaking to be done:

So..... what do you think?

Learning from other game devs 3: Minecraft networking

While reading Notch's tumblr, I came across a post that bothered me. Really bothered me. The post is about the implications of increasing the world (chunk) height.


http://notch.tumblr.com/post/7799649091/sharing-an-interesting-email

Designing programs is a huge tradeoff space, and trying to get to a local maximum rather than a global maximum in terms of optimization is a major pitfall for programmers. What do I mean by local maximum? Say that I have a game, and I want to increase frame rate, and with some minor violence to the graphics engine part of the code the best I can increase FPS is by 20%. Pretty good right? Now, I'll tell you if I scrapped the graphics engine, getting rid of all the assumptions (and therefore restrictions) I made previously and wrote a fresh graphics engine, I could increase FPS by 200%. Wow!

So, sticking with my assumptions already baked into my code, I'm limited in what I can do. Obviously, I've showed an extreme here. The reality is that sometimes handful of assumptions need to change, leading to little code change. The larger questions are: How do I know what needs to change in order to get a big benefit? Is it worth it (time, resources, expected results) to make the change?

Ok, back to the the post. There are a few things that bothered me, mostly related to assumptions that are being made. Please note I may not get this right, as I have a limited understanding of MC and opengl. Feel free to correct me. The point of this is to help me learn by getting my thoughts out into the blog, anyways :).



"- Network Implications: On SMP, Chunks need to be sent to many more people many times more often than in SSP. It can be taken for granted, from a client’s perspective, just how much data needs to be shoved around by the server...."  (all formatting is mine)

This argument seems like another Achilles heel for the proposal to grow the world height. However, there is a huge assumption that bothers me. Generally speaking, chunks do not need to be sent to many people many times. Initially (at creation time) they do, but only specific voxel updates (addition/removal) need to be sent to client.The benefit to arranging voxels in chunks is storage space, but you can imagine updating a chunk via a small packet says which voxels in which chunk need to change. This is an incredibly small amount of data, as very few voxels can change at any time, relative to the chunk size. Of course, I'm baking in my own assumption as well, namely that the client has a copy of the entire chunk (world) locally to begin with. This seems pretty reasonable to me, and there are a number of ways to accomplish this. Still, there doesn't appear to be a ton of traffic by increasing world height.

"- CPU Implications: Chunk terrain generation occurs in pieces ... Nonetheless, it’s still a cache-thrashing memory-fill operation. .... While this is relatively cheap for things like ore, it’s eclipsed by the idea that cave generation would need to occur along the entire Y axis, and being a recursive function, this has the potential to get very costly very quickly." (all formatting is mine)

This is a huge negative for trying to increase world height. Cache thrashing is horrible, and cave generation (when new chunks are constructed) can get intensive. However, there are a number of assumptions here. It is a big assumption that increasing chunk height will increase cache thrashing. In Notch's own words, a single chunk is 16x16x128 bytes = 32KB, already enough to thrash an L1 cache. You may be able to fit 8 regular chunks in the L2, and 128 in L3. Doubling the height would likely not cause any additional cache thrashing. Regarding cave generation, the assumption is that the same code scheme still needs to exist. In reality, there are a number of options. Manage the CPU resource by creating a thread just for terrain generation, and only activate it when you have spare cycles. Cave generation in particular is likely off the critical path anyway. In the worst case re-architect it and move away from a pure recursive (read CPU intensive) algorithm.

I'll leave the readers to think about and question the specific comments I've made. However, the suggestion of understanding what assumptions you are making can help put design decisions in perspective. The whole goal is to know what the options are. Its up to you can decide if trying to get closer to the global maximum is worth it.

Learning from other game devs 2: Notch's Tumblr

I was reading through Notch's tumblr last night, with the goal of understanding the progression from prototype to full game.

http://notch.tumblr.com/

Reading through it is interesting, as you see an idea from beginning to (basically) end, and get a small glimpse in how Notch thinks.

The thing that really struck me is how efficient (read: good coder) Notch is, and also how much time he was able devote to the project. Reading his progress, it really seems like 4-8 hours per day, every day. Granted, that's my estimate, and it could have taken him much less initially. I've read other game dev blogs which indicate similar time commitments.

Lesson learned: put the time in. It's difficult for me especially, as I have many other important things to do each week which take time. Church, work, exercise, driving (I spend 9 hours a week commuting to work), and time with my wife (dinner, etc). I really can't neglect any of  this. So where does the time come from? Well, I waste about 2 hrs per day surfing online, and another 1-2 watching TV. Gotta get that time back!

Learning from other game devs 1: Intro

I find myself often reading about other indie game developers' success stories and game dev blogs, and listening to podcasts with interviews of game developers of various success levels.

I've found that each developer has their own perspective and strengths (some many strengths), and I certainly appreciate that. Time spent listening to others is always a good opportunity to learn, and I thought it would be helpful for me to write down suggestions I've picked up and my own observations.

Let me first say that I am often take a critical mindset and openly question things that I. That's not to say that I don't respect these developers and their success; I certainly do. I'm merely trying to dissect things in my own way in order to learn. I'm just starting out with my first big project, and certainly

I certainly hope that this benefits everyone, and spurs interesting discussion. :)