I did get something out of it. I learned how to prioritize features and that it’s really better to do something you want to do as soon as possible instead of waiting for the right time, even if it’s shoddy, because the longer you’re exposed to it the more improvements you can make. But that doesn’t really help because I still felt like crap working on the game, and I still feel like crap whenever I do anything positive, and the ego trip from reading the comments on it doesn’t make up for it in the end.

P.S. On a lighter note, the game was inspired by a Radiolab episode that discussed how fighter pilots performing high G-force maneuvers sometimes lose consciousness and have dreams and out of body experiences. I read that hallucinations can also happen due to sensory deprivation in high altitude flight. Of course, my game isn’t even close to the actual experience, but I thought it was an interesting idea.

Play Nuclear Test

Let’s pick a theme with more variety next time.

Criteria

To know what makes a good theme, first we need to know who it’s supposed to be good for. What kind of people participate in LD? Why do they participate? Here’s the reasons I came up with:

• It’s a fun, low-barrier-to-entry test of one’s abilities.
• It’s an excuse to work on something and get a feeling of accomplishment.
• It’s a social community event.
• It’s a chance to achieve fame and fortune, if you make a good game.
• Competing to win is a test of one’s mastery of design, coding, and art skills.

Now, participants are very varied people. We have different development styles, different skill levels of designing/coding/art, and different preferences with regards to game genre and style. A good theme should be able to accomodate as many of these as possible, while unifying the entries with a common inspiration. With the goals of LD participants in mind, here are my proposed criteria for a good theme:

1. Can be interpreted in a number of ways such that it is a key part of the game.
2. Sufficiently restricts freedom of choice, to stimulate creativity.
3. Can be implemented in different game genres, using different mechanics.

Reasoning

Note: these criteria are somewhat subjective, and I will list examples below that may have interpretations I didn’t think of, or that you disagree with. These are merely my own subjective opinion, and most of them would normally be voted on by everyone, to give them a fair chance.

1. Can be interpreted in a number of ways such that it is a key part of the game.

By “key part” I mean that if the theme was replaced, the game would be fundamentally different. In a game about collecting peppers, peppers are not a key part of the game unless the mechanics involve something specific to peppers (perhaps the goal of the game is to make the ultimate vegan pizza, for which they are a critical ingredient). If it can be easily replaced with apples or coins without changing the essence of the game, then it’s not a key part of the game.

This means that a theme like Kittens would have to be able to be intrepreted in ways involving the essential nature of the animal. For example, games about chasing mice, balancing on fences, ripping furniture. An interpretation involving merely collecting kittens does not qualify, even though it is a valid way to do an entry. Examples for a theme like Isolation could be: searching for civilization after finding yourself alone in the wild, trying to keep a crowd of people out of your house, performing chemistry experiments to isolate a certain molecule. Notice that there is much more variety in the kinds of games you could make with Isolation as a central theme. The Tower might be a theme that does not meet this criteria well.

This criteria also suggests a definition for the entry voting category called Theme: “On a scale of 1 to 5, how important is [theme] to the nature of the game?”

2. Sufficiently restricts freedom of choice, to stimulate creativity.

On the opposite end, a theme that has too many interpretations is not interesting. Abstract, Direction, and Evil are generic enough to apply to most games. There is little that can be done in the way of innovation with them. You might as well submit a game you already made. Minimalist and Exploration may be poor themes in light of this criteria.

3. Can be implemented in different game genres, using different mechanics.

People prefer different kinds of games, and they don’t want to play the same game 100 times. One Button, Cellular Automata, Bullet Hell, and Board Games all place restrictions on the game mechanics. This could arguably be a good creative design challenge, especially for playing-to-win types, but such themes could stifle participation from less hardcore participants.

Such themes also do poorly at criteria #1 in that they are not open to varied interpretation. I think a technical challenge theme is more appropriate for a MiniLD.

Types of Themes

The theme suggestions are generally one or more of:

• object
• idea
• action
• setting
• game mechanic

There are specific objects without special properties like Bacon, Diabetes, Dentist, which fare poorly at criteria #1, and in my opinion should never be themes. There are also useful objects like Missiles, Paper, Robots, Advancing Wall of Doom, which may have enough leeway in interpretation to be good themes.

The majority of theme suggestions are ideas, which include the far too vague (Absolute, Evil, Infinity), too specific (Fractal), and moods (Boredom, Confusion, Intrigue), none of which would make a good theme. Suitable idea themes that I believe meet the criteria are: Age, Escape, Greed.

Actions (Fishing, Wrestling, Travel, Falling) are quite specific and difficult to interpret in creative ways. They generally make poor themes. Although, Conversation is an action that can be interpreted as “Communication”, an idea, and could make a good theme.

Settings (Caverns, Islands, Space, Forest) may result in good games, but also many similar-looking games. I do not believe settings are the ideal theme for a very large compo.

Game Mechanics (Strange Controls, Turn Based Eating, Bullet Hell, Board Games) dictate the actual design of the game, violating criteria #3, and resulting in too many similar games. In my opinion, these should never be themes. Note that Advancing Wall of Doom is not a game mechanic because it does not specify how it advances or what kind of doom it involves, therefore leaving room for interpretation.

Many themes fit into more than one category. They can be analyzed based on all of their obvious meanings.

Conclusion

Taking into account the number of participants and their motivations, the ideal Ludum Dare compo theme is an object or idea that performs well at the three criteria described above. Themes that obviously fail one of the criteria can be removed from voting in order to minimize the number of options to choose from. The rest can be voted on with us judging for ourselves how appropriate they are, keeping in mind that many different individuals want to participate, and that the theme that I want to do isn’t the same as the theme that I want everybody to do.

Of course, this is just what I think, and I don’t want to push my opinions. If you disagree, voice your reasons in the comments. On the other hand, if you think these criteria should be an official part of LD, please voice your support. Either way, thanks for reading!

Way back I used to play with SodaConstructor, an applet where you make 2D moving creatures out of springs and muscles (which are springs that expand and contract according to a sine wave) joined at the ends. A related applet was SodaRace, where you built a track for these creatures to race on, and tried to build the one that got to the end the fastest. Someone made a program that took a creature and randomly varied various aspects of its construction, put a bunch of these mutants on a track, and raced them, picking the fastest ones and repeating this in a process of evolution. It took hours just to get something remotely interesting, and days to come up with a maybe kinda cool result.

Same story for a bunch of life simulators that I’ve tried that you can google for. Usually the story is I run it, see a bunch of weird creatures move around randomly being stupid, and maybe if I leave it running overnight the next day I’ll see a bunch of one creature that moves around randomly, in a way that happens to not consistently lead to death. It’s watching paint dry.

There are several problems with simulating evolution:

1. It’s hard to come up with a digital environment that will support interesting evolution mechanics without simulating the trillions of atoms and chemical interactions that evolution has to work with. An arbitrary digital environment like a SodaConstructor applet will always have quirks that mean the most efficient creatures – the one most likely to be selected – also use the cheapest tricks and tactics, which includes bugs and glitches if there are any. Evolution will by definition test the very limits of its environment, so the tiniest glitch or imbalance in your simulation will completely throw off the quality of the results, if you ever get any.
2. No one has yet devised an evolution algorithm that knows which mutations are likely to be effective, so random evolution goes at a snail’s pace. Of course, which mutations will be effective depends entirely on the environment; for complex environments there might never be an algorithm any more efficient than Real Life(tm). This compounds the problem of making a suitable environment in the first place, because it means it could take days between test cycles developing a system that’s already extraordinarily complex.
3. The results are boring. It’s just the same kind of life (or computer programs) that we already see all around us, except inefficient, inelegant, and ugly, because of their primitive and largely random nature.

Evolution as a theme isn’t necessarily bad. There are other perfectly valid, doable interpretations of it. I’m just saying, if you voted for Evolution thinking you were gonna make an evolution sim, please reconsider.

UPDATE: Experience my poor art in a game, thanks to JonathanW!

I get peeved about things for no good reason a lot. One of those things is crappy art in games. I’m not really a great artist so I don’t know how to make good art, but I do know what I don’t like about bad art, so I decided to complain about it in the form of this exciting tutorial! I figure knowing what to avoid is at least as important as knowing what to do, so here is my guide to making really bad art for your game!

Color

Picking the wrong colors is obviously an important part of crappy art. The wrong color scheme can make people stop playing your game, or even not download it at all just based on the screenshots. It’s good to know how you can encourage that behavior.

Avoid complementary color schemes like blue/yellow, green/red, orange/purple at all costs, as they provide a good contrast and balance of hue. The mockup above is not the best example of this, as it manages to find balance between the green of the grass/foliage and the brown (red) of the wood, as well as the yellow sun against the blue sky. An easy way to avoid picking complementary colors is to use a scheme with only hues that are closer together, like nothing but green and brown.

Make sure to neglect the other laws of color balance, too: brightness, saturation, and contrast. The mockup again fails to totally break balance in brightness, as it contrasts the bright sun and grass with dark wood tones and black outlines. However, notice that most of the colors are highly saturated, with the fluorescent radioactive grass taking up a significant portion of the viewing area, successfully creating a palette that is a total eyesore. Also, the bright red on bright blue text in the upper left creates a clash that can literally cause your monitor to ignite if left on screen for too long.

If you use shading, always use basic photoshop gradients rather than drawing shadows by hand. Gradients look especially cheap and cheesy when applied to complex shapes. Make sure the colors are flat without any highlights, which are areas of lighter color on the side of an object closer to the light source, which create a sense of believable lighting. Same with shadows.

Detail

If you have picked a simple set of matching colors, or perhaps a minimalistic palette of black and white, don’t worry, because there’s still a lot of ways to go wrong. Detail is the way colors are put together on a small scale. Artistic styles are made and broken in the subtleties of how things are represented in your art. Use the following tools to achieve a feel of poor stylistic choice: geometry (perfect rectangles/ellipses/lines), complex textures applied to simple shapes, large soft brushes or special brushes, ugly fonts.

Flawlessly rendered geometrical shapes are quick and easy to make, and give a sense of inorganic coldness and unrealism. Carelessly applied textures or photographic imagery in an unrealistic world (like the bell peppers in the mockup above) add unnecessary detail, deprive the imagination of the ability to “fill in the blanks”, and instantly cause stylistic clash in your game. Very soft and unusual brushes in a single color turn game elements into cheap photoshop scribbles, again creating detail that destroys the imaginitive nature of simpler art.

Make sure to use as many of these techniques in combination as possible. The bigger the variety of art styles on one screen, the more conflicted the game world becomes, and the easier it is to break immersion. If one game element has a black outline, use a blurry outline on the others! Make some things flat-colored stick drawings and others photorealistic, so that it becomes difficult to imagine them interacting with each other.

Composition

Let’s say that despite your efforts, you ended up with a decent color scheme AND a consistent art style. You still have one last chance to ruin the game experience. Composition is the arrangement of parts of objects, scenes, or levels on a larger scale. Draw all objects in poor arrangement and out of proportion, and you’re sure to create distasteful art out of the highest quality graphics.

Composition is the art of directing the gaze of the eye around the scene. Break the flow of a composition by crowding elements together and leaving unnecessarily large gaps of space. Notice how the “health” text is huddled annoyingly close to the edge of the screen, even though there’s plenty of open space available for it. The bell pepper next to the tree nearly touches it, and creates a pocket of blue sky that traps the gaze of the eye as it moves across the scene. The sun is crowding the tree, with open space to the left of them, again creating compositional imbalance. With enough lack of practice, you will be able to create many more of these annoying layouts and pockets of space than I was able to in the mockup above.

The shapes and sizes of objects are another place to create disarray. Notice how the trunk of the tree is too thick for the size of the foliage implied by the blurry blotch. The roof of the house is slightly too large, making it look top-heavy and leaning to the right. The sun rays, in particular on the top and right, generate a subtle aura of awkwardness with their sloppy restricted shape. The bell peppers may seem unrealistically large compared to the rest of the scene, but giant versions of small objects are not so uncommon in games. A more jarring size imbalance is the fact that the tree with a trunk the width of a door is no taller than a one-story house. Furthermore, the doorway does not seem capable of accomodating the stick man’s head.

Conclusion

Armed with clashing colors, conflicting styles, and careless composition, you are now able to make the worst art indie games have ever seen. If you like, make your own ugly eyesore and post it in the comments!

Thanks for reading! Questions and feedback are welcome.

Also recommended: Better Programmer Art, the classic tutorial on actually making art.

[Reference photo]

A lot of people think they can’t draw. The truth is, nearly everyone can, they just never learned how.

There’s visual drawing and symbolic drawing. Drawings that are like photographs, look real, use shadows to suggest at 3Dness are visual drawings. Simplistic children’s drawings with stick figures and simple outlines are symbolic drawings. Visual drawings are the result of the artist’s mind focusing on outline, color, proportion, how the subject actually looks. Symbolic drawings are the result of focusing on words, meanings, and mental representations of a subject.

To draw realistically, forget what it is you’re drawing, pay no regard to mental representations and ideas, and focus on the reality of the colors and contours of the subject. Visual drawing is like tracing what you’re seeing.

Without turning your head, notice the dark and light areas of this image. If you like, get a piece of paper, relax, and quickly sketch where the dark areas are without paying any attention to what the image is about:

Drawing is about seeing. Things take on interesting qualities when you see them for what they are, instead of what they represent. Pay attention to the subtle curves, angles, proportions of lines. Notice that wrinkles are edges between a shadow and a highlight.  Notice that eyes and liquids are tiny, bright dots of light.  Notice that faces are extremely asymmetrical – light on one side, dark on the other. When you notice these things, you enter a meditative, relaxed, wordless state of mind. This is the artistic mindset.

The artistic mindset is quite at odds with the programming mindset. Programming is largely about manipulating symbols and abstractions. It is no surprise that programmer art is so often like children’s drawings – simplistic and symbolic. This is not a bad thing, it just means the artist was paying attention to words and symbols in his/her thoughts, rather than colors and contours in his/her field of vision. The transition to the drawing mindset can take some time, 5-15 minutes. Above, you can see my progression into this mindset and the improving quality of my chair drawings. If you did the drawing exercise earlier you may have encountered some difficulty noticing the dark areas of the picture. If you keep drawing, this will become easier and easier. Avoid drawing and programming at the same time. Reading, talking, and thinking too much can knock you out of the drawing mindset.

You can think of drawing like copying arrays of pixel values from your vision to the paper, but your vision is infinitely detailed and you have to make choices about which details to transfer and which ones to omit. This choice is your artistic style. More detail is not necessarily better. Know when to stop: watch your drawing, when it looks like the subject, it is complete.

Realistic drawing from the imagination is more advanced than drawing from reference. It comes with practice. If you draw a lot, you will begin to notice patterns in the way that light shines on and interacts with objects, and learn techniques to draw various kinds of objects. Once you’ve had experience drawing from reference, you will be able to apply the skills to drawing from imagination. The other way to draw from imagination is to have a photographic memory that you can use as a reference.

Exercises: 1) Draw the contours of your open palm. At first you may need to look back and forth between your hand and the paper to get the proportions and angles right before you draw a line. Use existing parts of the drawing and the edges of the paper as a size/angle reference. 2) Close your fist, palm up, and draw it by shading the dark areas. 3) Draw any object you like any way you like.

Drawing is relaxing and a powerful way to train your mind and creativity. Nearly everyone can do it if they try.

Questions and feedback are welcome.

the “music” should be best appreciated as textural rather than melodic

falling off is the end

the fact that there’s no gameplay is intentional

the only part I didn’t finish is windows on downtown skyscrapers

the game does have meanings but none of them are related to each other

I get a kick out of the love/hate reviews

everything was drawn with a mouse

i hope the theme is snow because i know wher to get some LOL its in my back yard

i made a tutorial to help people I hope you like it

1. get an idea. like rolling snow balls
2. make a clear simple goal from it. “make the biggest snowball” isnt clear because you dont know biggest than what? i will use “roll up all the snow”. other good ones are: get to the exit without dieing, eat all the apples, kill the evil boss. if its not simple the game will be confusing
3. add obstacles to get in the way. if the snowball is too big it will be too hard to push so thats my obstacle (you can only push it downhill). it will be a puzzle game to rollu p all the snow by finding the right way to roll your balls LOL
4. make sure its not boring. if your game is about shoting enemys and theres no reason not to shoot them then its a crap game because “should I shoot him?” is a boring choice. good decisions make you give up something because fun is when you make risky decisions in your life. so the risk in my game is that rolling a ball makes it too big and then you lose the puzle
5. test it by makeing a simple version on your paper so you know its fun. delete all your boring ideas, you mihgt have a lot of them so dont fall in love with your turd game haha. look at my game that i made in like 10 seconds while i typed this (my camera string is not part of it tho):
   i also wrote down the rules which i edited until it was fun to play. can you get all the snow??? you move snowballs up down left or right, except against an arrow, unless they rolled into it. balls dont roll downhill automatically, you have to push them down. also its supposed to say “10 or more” snow. i already started that level it was kinda tricky
6. now you can add powerups very carefully but dont forget to make them intersting tradeofs and dont add them if they make the game boring. i could add a rule to remove one snow by melting it with pee but I havent played the game enough to know if it would be any more fun also its kinda gross

so now you can make your game. but watch out for these highly important tips:

• design while youre sleepy at night or just got up because thats when your brain is the best at creativity and art
• write down your ideas so you dont forget them when youre programming
• if youre not sure about an idea, do not do it. simpler is better.
• finish the game in 24 hours, because it always takes twice as long as you expect

good luck making your crap game, everybody! (plz vote this 5 stars if you liked it)

Several random walks. The final level generation algorithm isn’t much different.

I really wanted a dark cave sort of game where you’re sneaking around shooting evil demons, like a rougelike, so my third concept was a top-down procedural cave shooter with realistic line of sight, styled in cavey gray and brown. I liked this idea and began working on a level generator which was a simple random walk that varied the size and direction of a “brush” at each step. I then did the line of sight by projecting 3D walls towards the camera from the 2D ground, not planning on adding any 3D beyond that. The level generator worked surprisingly well, and I decided not to write code for making rooms like I planned, instead letting the path wind around enough that it made rooms by itself.

I thought the final game would essentially be this.

I felt demotivated all day for various reasons, so progress was slow. By Saturday night I had a square player who ran around in procedural caves. I half-heartedly went back to bed for more ideas. Then, with great disgust, I realized the game was turning out to be another generic shooter, and that there were probably at least five others like it in the competition. Plus, I knew I was bad at coming up with actual content, like interesting enemies and non-abstract graphics.

I needed to have something more to present. If I couldn’t think of a good gameplay mechanic, then the only other option was to dress up a mediocre one as much as I could with crazy colors and special effects (don’t underestimate this strategy). I looked at my 2.5D game and realized that simply pointing the camera forward would give me a first person shooter, something I considered but hand-waved as too difficult and unnecessary. I knew then what I needed to do.

Fog is trivially simple to implement in OpenGL, but is a beautiful effect.

I used a color value that roughly cycles through the rainbow as the basis for most of the visuals. I took care to avoid staying within the 0.0-1.0 clamp for color values. The camera needed to move a lot, so I made it shake, recoil, and bob. Making explosions that feel good was critical to the game, so I added flashes of light with every bullet and enemy death. The enemies started as the most obvious thing I could think of, bouncing diamonds, and didn’t change much after that. The walls and enemies had directional lighting. I turned enemy deaths into laser light shows.

Unfortunately, all of this took up a lot of time, and since I only started Sunday morning, the compo was already nearing its end. I thought about the last compo’s complaints that I didn’t have a proper menu screen in my game. I saw little need for one, but figured as long as I’m going for show I might as well try to make a “real” game. Thinking about whether I should learn how to use fonts in OpenGL, I decided to just hard-code a 3×4 font. Much simpler. I slapped it on the start/pause/win screens, added a HUD, etc etc, and the entry was complete.

Complementary colors create a balanced, high-contrast color scheme.

My biggest regret is probably that I didn’t have time to make the enemies explode into actual debris. That would’ve finished off the visual effects, and is definitely going in the update. Sound and music would’ve made this the best game ever, but I hadn’t done much with sound before so I knew it was going to take too long to do it to my satisfaction. Better to leave it up to the imagination than to pollute the game with shoddy art.

Lessons I’m going to keep in mind for next compo: Everyone complains about polish, but polish takes at least 50% of development time, so make sure to finish the core game in the first 24 hours. This is difficult because good ideas can be a lengthy iterative process, so spend the day before the compo being well-rested and chillin to get into the creative state of mind.

I’m extremely happy with this entry because it’s a good demonstration of what I think big commercial games should be capable of. It’s retro and arcadey and exciting. This is what I want to play.

Download

The wiki mentioned that I should keep a log of some sort as I develop my game. I decided to write short entries in a txt file, then thought I would post it all when I was done. Now that my game is finished, I thought it would be a good idea to expand this short log into a full commentary-type thing of my Ludum Dare 14 experience. I will describe the development of DoomDrive in detail in the hopes that someone will find this interesting. Maybe this will make up for not doing a timelapse. Note: In this post, all times are EST and entries from the original log.txt file are italicized.

SF’s devlog

The first real language I learned was C++, I started learning it at age 11 when my older brother gave me a book about it. I didn’t know anything about compilers then so I couldn’t even write a program until much later, but I absorbed the information with great interest anyway. I love C++ for its speed and the amount of control it gives me over my code. When choosing graphics and sound libraries to start learning I did a few comparisons and settled on OpenGL with GLFW helper tools, and OpenAL. I haven’t had too much trouble with these (though my OpenAL knowledge is limited) and they’re what I know best so they’re what I used to make DoomDrive.

Saturday morning (18apr09)

2:40 – Forgot about LD for the past couple days, remembered it just now.
The contest began at 23:00 on Friday, so it was 3:40 in. I had decided to start developing a game (unrelated to any contests) a week before. It was to be my very first serious game (a space shooter, heavily inspired by the rather obscure Hell Fighter). I’d done enough half-projects experimenting with the aspects of game design – code structure, physics, graphics, art, sound, game theory, etc – that I knew I had a good grip on making games… I just hadn’t done it yet (other than a GameMaker game I made at 14, and of course Tetris). My problem was I never felt like doing anything. But over the past month I’ve been working on my mindset and setting clear goals and all of that personal development nonsense, so I finally felt ready to begin coding my first game ever. I did. Then I found out about Ludum Dare from browsing java4k-related stuff, realized it was gonna be the next weekend, and wondered if I should try it. I voted on the first three rounds, still unsure if I would participate, then kinda forgot about LD as I concentrated on coding my space game. I remembered it at a convenient point in time, thought “now or never”, checked out the theme, and immediately started thinking up ideas. Well, it didn’t take long to come up with one…

3:05 – Idea: Drive a 3rd person 3D car around a forest and ramp off rocks to get away from the wall. I haven’t done much 3D in OpenGL. I will most certainly get stuck on bugs until it’s too late. Whatever.
My conceptual vision also involved pools or rivers of water that you had to jump over by driving off cliffs. It just seemed fun in my head so I went with it. I was a bit pessimistic about it. It might have been because the idea of making a game in 48 hours sounded so absurd; I always thought a decent game would take at least a month to complete. More probably it was just a safeguard against being disappointed when I failed to live up to high expectations for myself.

5:05 – Should I sleep? I hand-coded a car model and not much else is working yet.
My idea meant mostly procedural, randomly-generated content. I love procedural, but the car model would have to be designed by hand. I began drawing it out as soon as I picked out the idea, because that seemed like the most natural thing to do at the time. Since it was so simple, I just punched in the numbers in a const array, remembering to keep vertices of quads in clockwise order (I later found out counterclockwise is preferred). The model (and the game idea in general) was probably influenced by Twisted Metal 4, a PSX game I played a LOT as a kid. My favorite car was Orbital.

Check out those ambient lighting effects. I chose these colors in GIMP. I thought the car should be a different color but the light gray sorta stuck.

5:30 – I’m making elementary math errors because I’m sleepy, so I will rest before continuing the game. Night.
I think this was when I was trying to figure out OpenGL lighting. I dunno why I did the most graphical parts of the game first, probably because it was what I would have to look at for 48 hours, and it’s more fun to code a pleasant-looking game. I never programmed lighting before but I figured I only needed simple stuff so I could learn it in time. I seem to understand complex ideas pretty quickly, at the expense of poor memory of concrete information, like names of functions, or the fact that Ludum Dare starts today. I think it helped that I slept twice during the compo, so that I worked for what felt like three days instead of just two. The best ideas happen in bed, and I like to think my brain is subconsciously thinking about things while I sleep.

Saturday

13:20 – I AM UP! I’ve been coding in my dreams all night long, let’s see if that helps me any.
That night I had the odd experience of watching a half-dream where a programming problem appeared as code before my eyes, and I solved it without consciously thinking about it. I think it was a premonition.

This seems incorrect somehow.

16:20 – Stuck on a dumb lighting problem like I expected to. Losing motivation. I’ll just ignore the problem for now.
17:05 – I couldn’t ignore it. The problem is lighting needs normals that I haven’t worked with much and mine are kinda wonky.
I made the mistake of trusting some lighting tutorial example code that seemed wrong at first. Wasted too much time on this and felt dumb afterward. I never did get directional lighting to work, which would have made sense since I wanted sunlight. I just did a point light that’s a fixed position from the camera. It looks about right. I didn’t even bother with specular or smooth shading, I knew I wanted the simple flat look when I first thought up the idea.

MERRY XMAS! Note: This screenshot does not demonstrate proper debugging procedure, don’t try to understand it.

Yeah fog! The car just hovers so far. I made a hazy sun by rendering the inside of a huge cone a fixed position from the camera (like a skybox) with the center almost white and the edges sky blue.

17:50 – FIXED IT! Now on to making game mechanics.
I believe I was messing with the car speed and turning and friction around this time. I obsessively tweaked these throughout development, up until the very end. I’m glad I did because the controls contribute a lot of the feel of an action game, though I still think it could be made more fun. You’ll find that I left in the code to tweak game constants if you press a number key or insert/del/home/end/pageup/pagedown and look at the stdout. I did something like “float SPEED=tweakvars[1];” in the game loop, ran the game and adjusted the value with those keys, and when I settled on a value I changed tweakvars[] to initialize accordingly. It’s a primitive system but it did the job.

The entirety of my collision detection code:
car.z<groundHeight(car.x,car.y)

19:10 – Well, at least it looks fancy. I’m gonna eat dinner.
21:20 – Time to figure out perlin noise terrain, then I will have awesome screenshots. My morale is back up and I’m doing way better than I expected, although I don’t think my forest is gonna have any rocks or trees. It’ll still be fun to drive around hills.
By this time I had a fairly clear vision of where my game was going.

21:40 – I’m humming tunes. I hope I don’t go insane from non-stop coding. I will listen to noise music for a while. I don’t know if doing that has any mental effects that are beneficial to programming games, but noise usually helps me clear my head.
Also tried trance. It seems to help at first, but becomes a distraction once I’m in the zone. I took a reasonable amount of breaks, but other than that I had been coding nonstop that day AND the day before (my space game), so I was already getting worn out.

Here you can see me trying to figure out vertex orders and terrain slope calculations. This is just scratch work so it’s probably wrong. I only write in cursive so people can’t read it at a glance (it’s actually less efficient than print).

22:35 – OH SEGFAULTS! My goal is to finish the terrain and the car “physics” before I go to bed so I can add the actual wall and maybe a little sound tomorrow.
Spoiler: The car is actually a single point. It does physics by controlling z height based on things like slope of the ground at x,y – the game is essentially 2D. The terrain is an array of z values. The car is either on the ground or flying. When not flying, the point follows the slope of the ground. When it crosses an edge between triangles, it checks the angle at which it hit, so that if the ground is curving up the car slows down, and if the ground is curving down the car ramps off into the air. However, there’s a problem in that this angle checking doesn’t happen when you land (only when you drive across an edge), which means if you’re flying and you land on the very tip of a hill, your forward velocity will not be updated to account for it, and you will get pushed up the slope way too fast, causing you to fly really far. This is a gamebreaker that I intend to fix in a postcompo version. (Note: The physics are actually an inaccurate fudge I came up with by just guessing at how the car should behave, and adjusting it to be playable. The postcompo version will be much better.)

The game doesn’t change much visually from this point on. Though I wanted to tweak the colors at the end, I didn’t have time and decided that was just polish for the postcompo version. Blue ambient with orange diffuse light worked pretty good. I noticed from using Hammer (the HalfLife 2 map editor) that shadows should be rendered blue (not gray) when sunlight is yellow – complementary colors.

00:05 – EPIC SCREENSHOTS! Just the car physics left now.
You can see that the procedural terrain gets generated as you drive. It’s stored in a 2D circular buffer, which was a little confusing to figure out how to do, but is very efficient (a single array on the stack). Random hills were accomplished with perlin noise. I made some with varying roughness factor (using perlin noise to vary it) roughly in the range 0.0 to 1.0, raised it to the fourth power to flatten out low areas (fourth power is called “quatric”), and of course scaled it to a proper height. The noise function returns a random value seeded by x and y position, so the infinite terrain stays the same every time you play. I figured if it changed all the time people wouldn’t be able to make maps of the best routes. No, no one would be that dedicated. I hope.

01:20 – But I mess with the camera instead. Getting sleepy.
The camera was another thing I tweaked all throughout development. My photographer side definitely had a hand in this. But again, I’m glad I worked so hard on it, camera problems are frustrating and awkward for the player. What bothers me is that you never get to see the awesome epic wall of fire in all its glory until you die, unless you turn around like I did for my official screenshot, and there’s no reason to do that. I considered adding a rearview, but what’s the point if it’s only there for looks? Maybe I’ll add an attract mode that shows the wall from a better angle.

02:10 – Decided on “Doom Drive” for the name. Physics will have to wait til tomorrow. I am falling asleep. Night.
04:10 – Ate, washed, went to bed, couldn’t sleep, but got some ideas. I always get ideas in bed. Ideas: I will reward airtime with a proportional amount of boost. The terrain will get more and more intense over distance, as a difficulty curve.
I knew I was going to bed way too early, but I was so tired of coding that I thought I’d fall asleep right away. I’m glad I got the boost idea because until this point the game was about finding the flattest (most efficient) route, and I wanted it to be about RAD AIR!

Why am I floating

05:05 – My car is floating aughhhhh oh no
05:25 – YEAH GRAVITY!
In my exhaustion my log entries have degenerated into basic feelings about what was happening at the time.

06:30 – God, there are so many bugs with driving backwards and stuff. Hmm, 16 hours left. Going to bed for real now. Night.
If you’re gonna use something like negative velocity values for driving backward, make sure to REMEMBER that when you do calculations. It can get frustrating to get stuck on a bug where your car falls through the ground when you drive backward. Humorously, before I added flying, gravity, and fixed the backward movement, the game played a lot like Big Rigs.

Sunday

14:40 – Slept nicely. Final stretch, here we go.

Worst concept art I’ve ever drawn. The music was actually gonna be just a repetitive trance beat, but making that sound good procedurally would take way too long for me, as simple as it is. I’m really sad I didn’t get to adding scoring, at least a timer, but I thought it would require displaying fonts, which I didn’t have time to figure out when I realized I had to.

Burninated! This is the first firewall (looked less refresh linesy in-game). Here the fire looks like crap because it’s a lit material instead of a plain color. Fire isn’t supposed to have shadows on it.

16:55 – Finished the firewall and boost mechanic. If I add a HUD and tweak the wall speed I will have a working entry.
19:35 – Woo, it’s playable! I will add boost effect and cam shake for fun, then submit.
DoomDrive has three kinds of fire: the enormous wall of destruction, the boost flames coming out the back of the car, and the car burning as it tumbles into space when you lose. They’re all just triangles with vertices that are randomized each frame. The boost flames are each a single triangle, but if you ask me they make a pretty effective flame. I like my burning car flames way better than a lot of the graphical fire I see in commercial first person shooters like HalfLife 2. Then again, I was never much into realism. Cam shake is the best thing ever. I knew the wall of fire wasn’t giving off quite the feeling of horrible doom and despair I wanted it to when it caught up with you, so I came up with cam shake to fix that. I think it worked.

These fire colors were a little too cartoony. I like everything to be desaturated and sad.

21:45 – 1 hour 15 minutes left and I am as finished as I will be. The game now features driving a car in 3D around rough procedural terrain with a wall of fire chasing you, a boost meter that increases with air time, with fog and a procedural noise algorithm I developed a while ago for sound effects. It’s almost over…just gotta see if it compiles on Windows. I’m sick of coding, but I’m really happy with what turned out.
Oh yes, the audio. I’m kinda into noise music, and I’m totally into procedural generation, so one time I made a procedural noise synthesizer that could be controlled by moving the mouse around a square window, the x and y values mapped to the two controls. It seemed obvious to reuse some of that code for sound effects for intense fire. Ogg audio demonstrating the noise synth.

22:45 – 15 minutes left. Submitted linux version. Gonna go try to compile on Windows. Wish me luck.
I ended up working on final touches for an hour. At this point I was in a bit of a code trance, completely exhausted from the past two days and starting to get apathetic.

00:15 – Last entry: One hour fifteen minutes past the deadline, Windows version compiled. Though it probably has crappy sound. Whatever. I’m done.
It only had crappy sound on my crappy windows box and apparently worked fine elsewhere, besides being lagged due to the way I tried to fix a problem with audio skipping in between buffers. Thanks to DrPetter for helping me get the right OpenAL libs since I couldn’t download the SDK on dial up.

END OF LOG

Some of my vertices turned out to be in the wrong order after all. Shoutouts to my good friend in Devon, without whom I probably wouldn’t have figured this out in time.

All in all

DoomDrive flew in the face of my own expectations for it. I’m happy. However, I’m friggin sick of coding, so I don’t know how long it’ll take before I recover enough to do a postcompo version. I want to make the game feel complete, though. I got this far, why not finish it off?

Ludum Dare has been a good lesson in getting the most bang for the buck. Things like fog effect, random triangle fire, cam shaking, are all very simple to implement, but add a lot to the game. Also, I learned you don’t need a full blown physics engine to have physics, as my single-comparison collision detection demonstrates. I never thought it was possible to make such great games in such a short time. This is definitely a motivating realization.

DoomDrive is the first serious game I’ve ever made, and I think it’s safe to say I’m gonna be doing more action games in the future, hopefully for a living.

It’s been beautiful, guys. On to voting.

Mama always told me to keep a safe distance between myself and the advancing wall of doom.

Navigate treacherous terrain while a giant wall of fire chases you at unreasonable speed! Increase your boost meter by getting rad airtime! And…that’s about it. All content including audio is procedurally generated, except the car model, which I punched in by hand. This means the filesize is small; the linux binary is 66 kB. Note: It seems I forgot to compile a linux version after my last change–putting in code to restart the game when you die and press space/shift. Also this doesn’t work like I intended on windows (restarts immediately if you’re boosting when the wall hits you). That and the fact that there’s no scoring are the biggest problems. I’ll do a postcompo version with some more polish later.

Controls: up, down, left, right to move. shift/space to boost.

THIS GAME HAS SOUND.

Official entry: Download 256kB (win32,linux)

DOWNLOAD THIS: Download 491k with DLLs (win32) if you’re not sure you have OpenAL. This is an update that’s way past the deadline, but it’s the same as above except with DLL files for audio.

Check out the postmortem for commentated journal and dev screenshots.