Projects slow down over time. It’s inevitable. Partly it’s because the more you add, the more complex the code becomes, and so the harder it is to make headway. Swapping out a part on a lawnmower is easy. Changing that same part on a fully-loaded 2011 automobile is likely to be an order of magnitude more complex. But mostly it’s because we tend to go for the low-hanging fruit first and tackle the thorny problems later.
I began writing this series of posts a week into the project, and I’ve been gradually catching up. To wit: I’m adding features more slowly than I’m writing posts about features. Now that I’m out of new stuff to show off, these posts are naturally going to become less frequent.
While we’re waiting for the next breakthrough, I thought I’d take a minute and answer a few of the questions I keep seeing again and again…
1. So what kind of game ARE you making? What is this? Adventure? Platformer? Dating sim? RTS? FPS? Puzzle game?
I’ve been avoiding this question because I don’t want to sidetrack this series. If I describe the game in mind, it will only spawn a thousand more questions and objections. “But how is THAT supposed to work…?” “That doesn’t sound like fun to ME.” I’ll have to explain, and clarify, and defend, and I’ll end up writing a design document in the comments. We’re here to talk about procedural content for now.
I’ve been talking about procedural content for years, and this is my way of putting up or shutting up. “Yes, this is possible, games industry, here is my proof-of-concept.”
The project will probably die before I reach the gameplay stage anyway, so it’s best to not get too worked up about it.
2. Do you plan to release a build that we can try?
Yes. I’m not sure when, but I’m very curious how this technology will work on all those computers out there. Also, I think the project will be easier to understand if you can walk around in the world yourself. More on this later.
3. What are you working on next?
My priority list. (Which is by no means a guarantee that I will work on things in this order.)
- Day / night cycle. Not just light / dark, but sunrise, sunset, changing sky colors and fog effects based on time AND environmental conditions AND climate.
- Trees. Procedural trees with distinct species. I’m working on this one now, and it’s a biggie. Much larger than rivers in terms of complexity and challenge.
- Avatars. I want 3d animated figures.
I’ll be honest. This is probably where this project will die. This is such a bitch of a problem that I can’t even begin to describe how much I’m dreading it. In my previous job, the 3D-character animations were handled for me by a third-party engine. (Renderware, the same engine used in Grand Theft Auto III.) I’ve tried twice before to make my own animation system, and both times it ended in frustration. It’s just a huge thing. It requires a well-defined art path. “Okay, you make the model in Blender and make sure to follow these steps. Then save it in this format. Now make the animations and save those in this other format. Maybe run a converter on them. Then my engine imports them. Then I’ll just move the character around using this nested hierarchy of transformation matricies that were probably devised in a foreign coordinate system and saved into a poorly-documented file format. And then I’m going to bite down on the barrel of this gun and we’ll see what happens after that.
- Move to vertex (and MAYBE pixel) shaders. There are things I’m going to want to do: Make the land curve away in the distance to hide terrain popping. Have trees and flowers gradually fade in. Replace the two-pass rendering I’m doing on grass with a single pass. I need vertex shaders for all of these. It’s going to be a big step, and it might mean relinquishing SDL. That will once again tie me to windows. It will also turn my tidy 100 lines of SDL code into a sprawling 700 lines of Microsoft-flavored Windows API calls. It will eat time, bloat my code, take away my portability, and generally annoy the hell out of me. I’m putting off this step, obviously.
- Weather. Particle effects.
- More environments. Lakes. Swamps. Forests. Sandy deserts. Steppes.
- Undergrowth. This might simply be an extension to the existing grass system, or this might be another, more advanced system.
4. Why does [feature] look so crappy?
Obvious answer: Because We’re still in the most early stages of the project. This is long, long before even the most hype-obsessed developer would let screenshots into the wild.
Other answer: The game doesn’t have a strong art design other than “pixelated”. So, it’s easy to look at the game and view it as something that’s supposed to be somewhat photo-realistic. Bare terrain doesn’t have a lot of personality. This will change as features appear and the style of the world takes shape. Nobody (sane) looks at Minecraft and talks about the lack of realism. The art style sets the tone, and the eyes accept things as long as they fit.
Check out Part 23 of Goodfellow’s Let’s Code series, he’s dealing with this same issue right now. Interestingly enough, he’s taking the opposite approach. He’s using tech to cover his lack of art, and I’m [planning on] using art to cover my lack of graphical tech.
For reference, I’m aiming the art style somewhere between World of Warcraft and Minecraft.
5. When will it be done?
Don’t make me slug you.
In Defense of Crunch
Crunch-mode game development isn't good, but sometimes it happens for good reasons.
Silent Hill Origins
Here is a long look at a game that tries to live up to a big legacy and fails hilariously.
Steam Summer Blues
This mess of dross, confusion, and terrible UI design is the storefront the big publishers couldn't beat? Amazing.
Could Have Been Great
Here are four games that could have been much better with just a little more work.
Crash Dot Com
Back in 1999, I rode the dot-com bubble. Got rich. Worked hard. Went crazy. Turned poor. It was fun.