namespacekam-blog

[namespacekam-blog]

Sneak peek: Co-op dungeon crawler

This one is really exciting for me, because I love co-op games, and I'm really excited for our team to try our hands at our own spin on gauntlet.   In october, all we had was a box with some spawners, a single player, and some swords.  Mostly meant as a tech demo, this "kill box" was more designed to prove that we could handle things like lighting, physics, and shiny effects.  Playtesters ended up really enjoying dicing up low-poly rats, and most of our playtesting sessions would run for several minutes after I had announced there was nothing more for them to test.

Fast forward 2 months, and this is where we're at now

A boss!  An actual boss, and we're not even in alpha! We had only planned on having an extra-large rat with more hitpoints, but thanks to a sudden burst of scripting motivation, we arrived at a pretty detailed encounter, full of charge attacks, rumbles, and clinging rat minions. Rather than having classes and class skills, players will pick up two weapons, and that combination will be their "class".  As of now all we have is a sword and a shield, which still allows for some entertaining combinations.  It's pretty common for playtesters to grab two swords, but every now and then we have someone that picks up two shields and starts chain bashing enemies. Also featured is a working death system! Instead of sitting idle, players can wiggle a lit tombstone, making annoying sounds and encouraging their friends to help them revive.  We've come even farther since we made this trailer in october, and I'm really excited to show off that new stuff, so stay tuned for future updates

[namespacekam-blog]

Finished game! Forsaken

Looking back, we definitely pushed the bounds of realistic scope with this one. For a lot of us, sophomore year was the hardest year of school, and on top of that we decided on a puzzle platforming poetic experience. Well it turns out that poetic experiences are really hard, and so are puzzle platformers, so doing both in 6 months under a 21 credit courseload was basically crazy-talk.

In the end we focused on creating a poetic experience and ditching the puzzle platforming elements, which really hurt because we had some great plans for using those puzzle platforming elements to further our storytelling elements.  In particular, the small companions that followed the player were meant to overcome obstacles, and strategic use of these supernatural friends would be vital to overcoming puzzles.  Over time, we would start killing off your companions because we are sadistic jerks.  Once you had lost the ability to overcome certain obstacles, we would still feature those obstacles in subsequent levels, just as a constant reminder that your door opening/boulder smashing/high jumping buddy was dead now.  We had quite an elaborate ending planned out, and it still kills me that we couldn't get it into the game in our two-semester time limit. We had a really fantastic team, which is why we were able to do as much as we could, and in the end we made a game good enough to appear at pax, but this is definitely a game I want to revisit in the future and fully flesh out.

For any interested, check out a download here

[namespacekam-blog]

2D Lights: They are easy and you should be using them

Part 1 - Are lights worth the trouble?

Yes, 2D lights are totally worth the trouble. Hypothetically, let's say you're working on a game as a graphics programmer.  You've got a scene that looks like this:

You think it looks pretty good, but then your artist/designer turns to you and says "hey, what can you do to make this scene a little more atmospheric?"  Woah what, me? But I'm a programmer, are you sure you want that? Isn't there a running joke involving this exact situation where where "programmer art" ends up being the punchline? Aha, but you're not just any programmer -- you are the graphics programmer! So you've got some neat tricks to spice your game up visually. They'll look like the efforts your art team, but secretly they were the doings of someone who just thought of some clever math.  The snow already in the scene is a perfect example of this trickery at work: was it the careful skill of an artist?  Or did a programmer screenshot an asterisk, turn it white, and plug it into a particle engine? Who cares, it looks good! But let's say that you've already got a particle engine and people still want more cool visuals because particles aren't good enough.  Okay, next step up then:  Lights!

Still not good enough? Have even more darkness!

Okay, that's probably too dark, but you get the idea. Lighting is a pretty powerful tool; it's like handing your designers a dial that can change the feel of an entire level, and it's really not that hard to implement.  So how is this done? Part 2 - And then you said "let there be light" First, let's define a light. That's actually pretty easy, since for our purposes, a light is a circle of color where the alpha value is determined by a very simple formula:

where distance refers to distance from the center of your light source, and intensity is your max possible intensity (in this case, it should be 1). If you've done any physics, you may note that this is pretty much the most basic equation to describe the intensity of energy as it radiates across a 2-Dimensional surface.  I'd say that describes a game's 2D light pretty well, doesn't it?  While it is certainly true that other 2D light systems use more complex polynomials to calculate light, this will do just fine for right now So let's say you plug one or two lights through your shader and save the resulting blobs to a single texture, which ends up looking like this:

So what's the best way to apply these lights to your world?  For my implementation, I decided the best way to make lights show up was to make everything else dark, which makes sense as a light shining in an already well-lit room should go pretty much unnoticed.  To that end, my light system contains a single ambient color value (in the examples at the top of this post, it was black with varying alphas) that is passed to the shader.  My final step to determine the color that will go to the backbuffer basically looks like this

the final step where a light's value is multiplied by the surface texture's alpha is the most important one -- it is the difference between a system where lights only show up when projected onto a surface, and a system that appears to just cheaply litter your screen with large circles. Final alpha multiplication skipped:

Done properly:

Part 3 - TL;DR

Render a blank quad to an empty texture

Use the shader to fill the quad with math colors

Only cast your lights onto surfaces with enough alpha to justify your light showing up

Darken the rest of the world for contrast

Insert whatever other methods you feel are necessary. If it looks right, it's right!

[namespacekam-blog]

Looking back: Flip Magic

This game will always hold a special place in my heart for being our first ever completed game.

The concept around this game was simple: you shoot objects with your wand, and then switch places with them.  Sounds like the makings of an okay puzzle platformer, right?  Well... more on that later, but if you're curious about the game there's a download link to the installer here  It's pretty interesting comparing the final version of our game with our initial plans for it. The rough framework remained the same: "simple, visually charming puzzle platformer" but 3 months of playtesting really changed how we viewed our game.  The first big change was this room:

As one of the first rooms in the game, the original idea was to just inform the player that they only had two non-movement action buttons, and then let them figure out what they did. There's only two buttons, so it couldn't possibly be that hard, right?? I ended up being the person mostly responsible for overseeing playtesting, and after a few weeks of adding way too many ticks in the "player seems visibly frustrated" box, it was decided that we should probably be a little more direct about teaching our players. This room was one measure we took.

In early versions of the "how to push your buttons" room, playtesters would actually ignore the illustrations and just walk outside, and then be completely lost as to what they were supposed to do. The glowing box ended up serving two purposes:

1) slow down players long enough so they actually look at the walls 2) give them something to experiment on with their powers

All said though, we had no designers available to us, so even though the early game was smoothed over, what we ended up with was a puzzle game designed by programmers. My puzzles are not good. One of our attempts to mitigate our stale levels was the box cannon, featured below

while it did make the game more engaging and less repetitive, it also made the game more frustrating. Turns out that precision events where you fly over spike pits and die if you fail your timing or miss your target don't make for very fun levels

This is about as far as our game got, because we only had a single semester to ship it out. I'm reasonably satisfied with the results, but there were really so many more things we would have liked to do, given enough time.  But above all else, what this game needed was a good gameplay and level designer.

The art style was cute and many playtesters really seemed to enjoy the little flipbook-cutscenes with the magical cat, and the basic foundation of the game could have led to a pretty fun game. But with a team of programmers at the helm, gameplay experience ended up suffering.  Despite this, our game ended up being well received for its charming visuals and cute story, which I suppose was another lesson in how people aren't always super focused on mechanics, and are perfectly willing to enjoy a game for other reasons.

[namespacekam-blog]

Looking Back: Rev

Trailer courtesy of our team's artist/sound designer

Installer can be downloaded from the DigiPen game gallery

Our first "legit" team game, this game will probably forever hold a special place in my heart. Despite the generic space shooter game template, I was really pleased with the time travel mechanic, and the particle system.  The very awesome custom soundtrack is also worth mentioning, but all the credit for that goes to our sound designer (and I'm toss in an obligatory plug for them here)

The particle system in particular was a joy to work on.  Initially I was stumbling around in the dark with this vague notion that "I should make some points, and those points should also make themselves move" and ended up with something that, to my complete shock, actually worked.

Our game did face its fair share of problems, however. Almost all design decisions were based on working within the limitations of our inexperience, instead of making the ideal dream game we all wanted to make.  As a result, many corners were cut; it's no coincidence that our game takes place in space with a plain starry background, that our enemies spawn in randomly selected clumps, that no structures or bosses ever make their presences known, and that my particle engine is only capable of creating fountains and explosions (although I did give those two things a crazy amount of options).

One problem in particular was the fact that we had no game designer. There were plenty of design majors seeking teams, but we just didn't manage to get any of them, so that job fell to me. One personal weakness (and this was especially true at the time) is that I tend to focus too much on execution, aiming for "the thrill of a challenge!" that tends to result in 90% of the people who play the game having no fun at all. Enemies were unforgiving, and late game the waves were just mean.  We didn't even have multiple lives until the last few weeks; it had just never occurred to me that it might not be fun to suddenly die and get kicked out to the main menu.

Luckily we did get some last minute advice from actual designers who managed to salvage quite a bit of my inelegant enemy designs, and the final product ended up being actually kind of fun to play!

Long story short though: don't let me design enemies.

[namespacekam-blog]

Looking back: Shiela, the robot car

It's been about a year since our final project for our intro to machine languages class, but I don't think anyone on our team will ever forget Shiela.

Our task was to program a PIC micro controller to make use of various other components (sensors, a motor, a power regulator, etc) to "intelligently" steer a toy car around a series of obstacles.  Programming in assembly itself ended up being one of the lesser challenges in this project.  The sensor readings that would gauge distances to objects would change based on the charge level of the battery, along with the speed and steering, but even those issues were small compared to the occasional risk of hitting a wall too hard and breaking pins off of our logic board.

I mention that because this is literally something that happened.  We had to connect one of our sensors to a different pin and rewrite the entire portion of the program that communicated with the sensor array to seek its connections elsewhere.

And then there was the time when, after changing absolutely nothing, our car started steering extremely erratically. Neither the multimeter nor repeated attempts to debug our code could uncover the problem; we would switch on the car, it would frantically bank to avoid an invisible obstacle, and then crash into a wall.  We were convinced that someone had committed some late night crunch change and just forgotten about it, because there was just no way that our car's brain would break if all the code was the exact same as it had been the day before.

it's really hard to describe exactly the exact mixture of feelings when we finally spotted the stray wire that had risen off the board to block one of the sensors, causing a rogue proximity warning that tricked our car into believing it was in danger of ramming into an object with its left tire..

I used to have the source code for this project posted, but in hindsight it's probably a bad idea to post what is essentially the answer key for this class's final exam on the internet, so I'm taking that down.  Rest in piece shiela!

[namespacekam-blog]

Finished Projects

Shiela Not a game, but technically our first group programming project to be completed at digipen.  Shiela was a robot car, basically a series of sensors and a simple motor, all hooked up to a PIC-18F452 chip.  All of the programming was done in assembly, and the goal was to get the car to steer down a track covered in obstacles to cross a finish line successfully. The due date was a week or so before our game project was due, so tensions were running high, but in the end things turned out well.

Flip Magic  Flip magic is a 2D puzzle platformer about a frail wizard's quest to get his hat back from his dastardly magical cat.  You shoot boxes with your wand to mark them, and then change places with the marked box to overcome terrain puzzles. A download link for the source code and installer can be found here

The puzzles, art, and music have a cute charm to them Rev Written in C and incorporating Fmod and OpenGL,  The player navigates a never ending gauntlet of enemies shooting as many as they can to score points and charge their rev meter, while avoiding hits.  If they take a fatal blow, but their Rev meter is full, the meter is spent and they're given a chance to hang onto that life.  The player is sent back in time to a few seconds before their destruction, but as a suicidal bomb drone.  The bomb drone must destroy the enemy that killed the player (or intercept the fatal shot) in order for the player to break the loop and survive.  If they fail, the player loses a life. Download link for this game's installer can be found here

[namespacekam-blog]

This is why we couldn't have nice things

At the very start of our project last semester, I threw together an extremely hacky input handler under the notion that I needed to just get it working, and I'd make it pretty later.  Step 2 never happened. Without going into too much detail, it involved switch statements hundreds of lines long, and was spread across 4 separate files.  Huge mess.  With a new project starting early, much fewer deadlines, and a chance to finally work in C++, comes new opportunities to clean up past mistakes.  Obviously I started by refactoring the input handler.

It's now much more concise,  and instead of manually scattering various read and update functions throughout the gamestate manager, it now inherits from an abstract class which hooks neatly into the system manager. Next on the to-do list will be working in directx.  I'm hoping we can get that figured out real soon, because I'm really looking forward to upgrading my particle engine so that it can function without digipen's AlphaEngine.

We've also got the story pretty much figured out now (and we've got two other backups planned in case that first one falls through) but I can't spoil it, or our producer would set me on fire.  Seems neat though.

[namespacekam-blog]

Digipen Student Showcase!

REV made the digipen freshman student showcase!  Ustream recorded the broadcast here

http://www.ustream.tv/recorded/31678583 (our segment begins around 21:20)

still waiting on the showcase.  Also, we've formed a bigger team and started working on our sophomore year game, will start posting things as soon as there's things worth posting about

[namespacekam-blog]

Exciting news, plus a trailer!

It's been a while since I posted any updates, but good news everybody: Rev made the freshman student showcase!  Now we get to put our game up on display and watch it get completely crushed by all the upperclassmen games, woohoo!

Here's the trailer we'll be showing off this coming friday, our producer Kori Loomis did a great job throwing this together for us

[namespacekam-blog]

Update soon!

Beta presentation for rev was today, a ton has changed since the alpha build, will be posting videos and screenshots shortly

[namespacekam-blog]

Rev Particle System

I've never really talked about how I went about designing my particle system, did I?  I think now is a good time to fix that.  But first, a quick update!

I recently made some cool new changes for the particle system of our student game, Rev.  As a recap, Rev is a game being made by myself and 3 others, it's written entirely in C and runs on nothing but FMod and a wrapper for openGL's line drawing functions, and we have a single semester to finish it.

I recently added the ability to offset the spawn locations of particles into different shapes, including rectangles, circles, and lines.  Line emitters can have their angle and lengths specified, and the circle emitters can have a set minimum and maximum spawning radius.

Here's a peek at how I'm structuring everything.  The structure of the individual particle is pretty obvious, so I'll just talk about what's in my emitter and why I made those (possibly poor) decisions.

I chose to store my particles in an array.  At first I considered using a list, but it was pointed out to me that a list would be too much hassle for too little benefit.  For one thing, putting a hard cap on the number of particles any single system can emit is a good thing, and what's the point of going through the hassle of maintaining a list if you're never going to allow it to grow past a certain predetermined size? But by using an array, I give up the super fast adding and removing of objects that I would have had with a linked list.

Or do I?

When a particle "dies" instead of shifting around my entire array to remove it, or letting it sit there and be useless, that dead particle simply trades places with the rightmost "living" particle, and I update a counter that indicates how many living particles I have - all my active particles end up in one block at the beginning of the array, and all the dead ones are at the end.

The order those living particles are in gets totally scrambled, but since it doesn't really matter what order they're updated in, that's not an issue, as long as all living particles are updated once per loop.  What this means is that if I have an array ready to hold 10,000 particles, but only 10 currently exist, my update will only iterate through the first 10 spots, and instead of searching the entire array for a "dead" spot to hold a new particle, I can just slot it in at the index my "active particles" counter says is free.  If that counter is equal to the total size of the array, I know in a single check that I can't make any new particles, instead of having to search the entire array for a free spot and then return an error when there isn't one.  Here's a diagram to help illustrate the process

(one thousand hours in ms paint)

naturally this method would never work unless I was only ever adding particles to the lowest available index, but by doing this, I can achieve constant time operations for adding objects to the array (removing technically isn't const since finding a dead particle that needs to be removed is still a linear time thing, but the removal itself is always the same number of steps), and my update loop knows exactly how many particles it should care about updating, wasting no time by trying to update more

The next noteworthy thing in the struct is the EMITTERTYPE enum. Left to default values when initialized, a helper function can be called to change the emitter type to emit in circle, box, line, or point.  paramX and paramY are conditional variables that do different things depending on what type of emitter the particle system currently is.

Most of the rest is pretty self explanatory.  At the end I have some #defined chars pretending to be bools (remember, C) that indicate if the emitter is infinite or active.  For this game my emitter is mostly used for explosions and "rocket trails" effects.  Mounting a fountain type emitter to the player's ship and switching it on and off based on player velocity achieves a pretty nice rocket trail effects.  On the other hand, declaring a system to have a finite amount of ammo is also pretty handy; this way I can have particle systems that spawn an explosion, run out of "particle ammo", stop spawning particles, and once all active particles are dead, quietly delete themselves without any further instruction from me.

Oh, and I have the bools last in the struct because chars are only a single byte, and while it's not a huge deal to lose 6 bytes per emitter to bit padded structs, there's no point in that when it's so easy to just arrange your members in a way to mitigate that.

[namespacekam-blog]

REV alpha presentation!

a lot of things happened this last week, one of the most significant things being the alpha deadlines for our GAM150 student games.  Here's the presentation by our team

for a better look at the alpha demonstration, here's a frapsed video of the game itself

Rev is written entirely in C and incorporates fmod and alpha engine (a wrapper for openGL that handles drawing).  All content property of digipen digipen blah blah legal stuff someone else owns our work.

[namespacekam-blog]

cache missing

so I was discussing my particle engine with a friend and he sent me this link

long story short, I thought that an array of structures was basically the same thing as a structure full of arrays.  Turns out it's not, and arrays of structs can be a really bad thing depending on the situation.  My particle system is exactly one of those situations.

I'd like to fix it now but alpha's due in about 5 days, and optimization isn't so high on the priorities list compared to making something cool to show off for our presentation ASAP.  Soon though...

[namespacekam-blog]

Babby's first particle system

My very first attempt at a particle system turned out much better than I had hoped.  I was a little scared that my tiny 1GHz single core homework netbook would crack under the strain of a particle engine, but looks like I underestimated the little guy.  Word is that we'll be discussing particle emitters in one of my classes in about two weeks, so what I've got now is going to change once I get a good look at the particle system of someone more experience, but for a first attempt I think this could have gone much worse.

Here's what things look like with no active particles, the number in the top left represents the time between drawing each frame

and here's what things look like with 5000 particles being sprayed in a circle with downward acceleration applied (also shown: my primitive attempts at parallaxing with two scrolling background props, not that it means much in a still image)

my emitter initialize function is like a mile long, but I can set up a min and max possible value for randomizing initial velocity, initial angle, particle lifespans, angle and magnitude of acceleration, lifespan, total particles in the system, particles emitted simultaneously, particle color, starting position, etc.  I can also mount the emitter to objects so they can follow it around, and trigger emitters on and off.

Next I'll be working on particles that change colors over time, particles that are images instead of tiny colored squares, and particles that kill themselves off after a certain amount of time.

[namespacekam-blog]

programming is sometimes frustrating and hard, especially as a student, but this video made me feel freshly motivated to keep going.  On a side note, babby's first particle system is coming along nicely, update on that soon.

[namespacekam-blog]

Good articles on particle systems

While working on my very first attempt at a particle system, I came across this article which is apparently recommended reading for anyone looking at making their own system. The article was referenced in another article about more advanced particle systems found here.  Both are good reads