Pretty freakin awesome.
Sunday, March 18, 2012
Saturday, March 17, 2012
Wednesday, March 14, 2012
FFTs, and attacks!
Major strides forward today! We worked for many hours, and have some good stuff to show for our efforts.
After a bunch of false starts, David got the FFT stuff working, so in the background you can now see a cool yellow-y real-time spectrum analysis of the music track as it's playing--and it scrolls as it should, in time with the music!
I also reworked the input code so that now it handles attacks the way we want it to, and created our first attack! Right now it's a yellowy ball of particles that shoots out and damages anything in its way.
Now that we've actually got both our core gameplay mechanics working, we can begin to see how the game actually feels when you try to play it. It's...rather tricky, but in a good way (the difficulty we're testing it on is also pretty intense). Handling a constant stream of rhythmic bullets with one hand while also trying to coordinate attacks with the other seems to have just enough of that "two things at once" feeling that it's doable, but very tricky to get used to, and really works your brain. I like it! It reminds me of when I first started playing games like Sequence. In fact, you could say our gameplay is somewhat similar to that of Sequence in that you're forced to try and handle offense and defense simultaneously, but the presentation is much different...
After a bunch of false starts, David got the FFT stuff working, so in the background you can now see a cool yellow-y real-time spectrum analysis of the music track as it's playing--and it scrolls as it should, in time with the music!
I also reworked the input code so that now it handles attacks the way we want it to, and created our first attack! Right now it's a yellowy ball of particles that shoots out and damages anything in its way.
Now that we've actually got both our core gameplay mechanics working, we can begin to see how the game actually feels when you try to play it. It's...rather tricky, but in a good way (the difficulty we're testing it on is also pretty intense). Handling a constant stream of rhythmic bullets with one hand while also trying to coordinate attacks with the other seems to have just enough of that "two things at once" feeling that it's doable, but very tricky to get used to, and really works your brain. I like it! It reminds me of when I first started playing games like Sequence. In fact, you could say our gameplay is somewhat similar to that of Sequence in that you're forced to try and handle offense and defense simultaneously, but the presentation is much different...
Tuesday, March 13, 2012
Continuing progress...
More work got done..."yesterday", and by "yesterday" I mean Sunday night. My sleep schedule is such that the mapping of my "logical days" to actual 24 hour periods is sometimes...uh...shaky.
Anyhow, we actually managed to get some cool features in, although our game doesn't -look- that different. On David's side, he got environment mapping working so our player blob has nice reflections (ooooh). And the blob physics are better now. Also, we're now using libvorbis ourselves to decode the music ogg files rather than having SDL_mixer stream it for us. This'll let us do cool FFT stuff on the music stream (ahead of time, when needed) before passing it off to SDL_mixer to be played...we're planning to use said FFT data to generate the terrain/backgrounds.
On my side, I got random note generation working (wasn't actually that hard at all). More impressively, I also made the length of the enemy bullet rhythms variable as a parameter in the MIDI annotations. =And=, you can also specify the time it takes for the player blob to bounce up and down. It gets even cooler too--you can have the up bounce and down bounce take different amounts of time, =and= you can even change the bounce times, and the enemy bullet rhythm durations in midsong via control changes! And it all works, and stays in sync with the music like it's supposed to. Whoo! I also made some major optimizations to a few of the Song class in translating between time and beats and whatnot, so that they weren't super-stupid sluggy O(n^2) operations. There's still some stuff in there that's not really that efficient, but I don't think it's really worth it to optimize those. Amdahl's Law, blahblahblah yeah.
I also tried to wrestle with particle rendering...our particles are currently being rendered with point sprites. Which is all efficient and everything, but the problem is that plain point sprites aren't scaled with distance from the camera, so they don't exactly look right. We originally tried to use the built-in distance attenuation, but the parameters for that seemed pretty finicky and I'm not at all confident that we could get those to scale things correctly. Our second attempt involved modifying gl_PointSize in the vertex shader by dividing by w, but somehow that just slowed performance down a lot. In any case, the other problem with point sprites is that they're not quite as dependable--you can't know what the maximum pointsize is for a given implementation, for example.
So it's best to use quads...but billboarding a quad for each particle is actually kind of non-trivial, as you have to make sure that it faces the camera. And there's also the issue of how to specify the vertices efficiently, because you only have one set of vertices/colors/etc but you actually want 4, with a different offset for each...so yeah, that question is still sort of up in the air.
Anyhow, we actually managed to get some cool features in, although our game doesn't -look- that different. On David's side, he got environment mapping working so our player blob has nice reflections (ooooh). And the blob physics are better now. Also, we're now using libvorbis ourselves to decode the music ogg files rather than having SDL_mixer stream it for us. This'll let us do cool FFT stuff on the music stream (ahead of time, when needed) before passing it off to SDL_mixer to be played...we're planning to use said FFT data to generate the terrain/backgrounds.
On my side, I got random note generation working (wasn't actually that hard at all). More impressively, I also made the length of the enemy bullet rhythms variable as a parameter in the MIDI annotations. =And=, you can also specify the time it takes for the player blob to bounce up and down. It gets even cooler too--you can have the up bounce and down bounce take different amounts of time, =and= you can even change the bounce times, and the enemy bullet rhythm durations in midsong via control changes! And it all works, and stays in sync with the music like it's supposed to. Whoo! I also made some major optimizations to a few of the Song class in translating between time and beats and whatnot, so that they weren't super-stupid sluggy O(n^2) operations. There's still some stuff in there that's not really that efficient, but I don't think it's really worth it to optimize those. Amdahl's Law, blahblahblah yeah.
I also tried to wrestle with particle rendering...our particles are currently being rendered with point sprites. Which is all efficient and everything, but the problem is that plain point sprites aren't scaled with distance from the camera, so they don't exactly look right. We originally tried to use the built-in distance attenuation, but the parameters for that seemed pretty finicky and I'm not at all confident that we could get those to scale things correctly. Our second attempt involved modifying gl_PointSize in the vertex shader by dividing by w, but somehow that just slowed performance down a lot. In any case, the other problem with point sprites is that they're not quite as dependable--you can't know what the maximum pointsize is for a given implementation, for example.
So it's best to use quads...but billboarding a quad for each particle is actually kind of non-trivial, as you have to make sure that it faces the camera. And there's also the issue of how to specify the vertices efficiently, because you only have one set of vertices/colors/etc but you actually want 4, with a different offset for each...so yeah, that question is still sort of up in the air.
Sunday, March 11, 2012
Long Overdue First Post
We've been working on this thing since March 1st (about 1.5 weeks ago), and have made major strides of progress in that time, so this is a totally overdue post. On the plus side, the reason I've been procrastinating on writing this is mostly because we've been focusing on actually working on the project instead, so that's not quite a bad thing...
Anyways, here's more or less what the current state of affairs looks like for our yet-to-be-named CS248 video game project (excuse the shoddy YouTube quality):
We're using OpenGL for graphics, SDL for input and windowing/etc, SDL_mixer for audio, and a handful of other libraries too (SOIL, GLEW, etc).
So...lots of things going on here.
First off, we have our audio calibration screen, which right now is also serving as a test screen for our blob physics engine. Since we're making a music game, one of our highest priorities is making sure that everything is as tightly synced to the music as possible. We're using SDL_Mixer for our audio, but using custom music callbacks to ensure that we have precise information on exactly where we are in the music. We also compensate for the slight audio delay that results from audio buffering (which is what the calibration screen does). Whenever possible, we play sound effects early (compared to the graphics/gameplay) to compensate for audio buffer latency.
The blob engine was done by David so I'm guessing he'll have a lot more to say about that, but essentially, we figured early on that since we have absolutely no experience with 3d modeling and 3d animation, it would probably be better (and more interesting?) to base the animation of our characters/entities on physics simulations rather than trying to build our own 3d models. So we (and by "we" I mean David) have come up with this engine that constructs a sphere and then hooks up the vertices with spring forces and such so that it has some element of elasticity. The cool part is, we can even add point forces and planar forces and all sorts of other things to deform the blob in cool ways. You can see this in the calibration screen (when we press a direction, it applies a force to deform the blob and you can see it propagate through), as well as in the main game (the player blob reacts to the walls as it bounces off of them). We haven't implemented it yet, but eventually we're hoping to use random forces to procedurally generate different enemy blob models. (right now all of the enemies just look like perfect spheres...) The energy bullets also slightly deform the blob as they spiral in and get absorbed, which is cool :)
Of course, while trying to get the actual physics working right, we've run into a plethora of fantastic disasters...everything you can imagine, including having the blob collapse in on itself, explode out to infinity, become a spiky mess, stretching out to become a pong-like paddle, and...well, all sorts of other indescribable frankenstein creations. It's been fun...
So, as for the actual game...
It's a music-based game. You control a blob character that bounces up and down on the left, and enemy blobs (though right now they're just smooth spheres) spawn on the right. The enemies shoot colored energy bullets at you, which hit you on the beat. I implemented a basic particle effect system, so each bullet is actually made up of a bunch of particles. The cool part here is that the orbit radius of the particles responds to the beat...and even cooler, the particles actually orbit faster on the beat too!
Anyhow, each bullet color corresponds to a certain rhythmic pattern (e.g. red = 2 eighth notes, green = 1 quarter note, blue = eighth rest + eighth note). If you tap 'F' to the correct rhythmic pattern as the bullet hits you, you'll "absorb" the bullet and gain some energy (with a nice happy chime sound). If you don't, or screw up, the bullet will instead hit you and make you lose energy (with a not-so-happy sound).
I should note that the bullet-patterns aren't specified in our code anywhere--instead, we're using MIDI annotations to specify them. This works very nicely with my music production workflow in FL Studio because I can just make a separate annotations track and lay it out in the same view as my actual song patterns. Eventually ("eventually" meaning later tonight) we're also going to implement random bullet generation, which will also be controlled by MIDI control values. By the way, the frequency of enemy spawns is also controlled by MIDI control values, and is pseudorandom based on the seed you specify. The pseudorandomness will allow you to generate random levels, but also replay a level generated in the same way by specifying the same seed.
So far, this is just a pretty standard music game where you press a single button in time to oncoming events. But here comes the twist: the enemies also slowly drift over to your side of the screen, and after enough time, they'll slam into you, dealing a considerable amount of damage to your energy that you can't avoid.
So how to deal with that? Well, we haven't implemented it yet, but by pressing 'J' in specific rhythms, you'll be able to spend your energy to launch cool attacks at the enemy blobs! Of course, you'll have to time your rhythms in order to aim your attacks at the right height level, and do this in the midst of absorbing bullets with 'F' as well!
More powerful attacks will require more complex rhythms to be pressed, and will also require more energy to be used up, so there's a certain risk/reward factor we're hoping will be interesting--powerful attacks will be much more effective at clearing the screen of enemies, but at the risk of being harder to perform, and using up more of your health.
So that's our game! Of course, there's a lot of work to be done--we haven't even started doing attacks, for instance...but we're already well on our way, and even in its current state it's pretty cool.
I should note that the song we're currently using is something I basically composed on my laptop using FL Studio concurrently as a break activity from working on the code. It actually started off as a one-measure loop, all on middle C, but that got old to listen to real fast, so I gave it some actual pitches and expanded it some more. Then when that got old, I added drums, and...well, you get the idea.
It certainly helps that I've had so much experience doing OHC that making music quickly is pretty much a no-brainer for me at this point. Since each level of our game is going to be based entirely on the song plus associated MIDI annotations, this means I'm going to be able to pump out a lot of levels really easily, which is great!
From here, there's much to be done; for example sphere mapping to make the player blob reflective, random note generation (i.e. more MIDI processing), proper shaders for things like particle effects, getting started on player attacks, random background terrain generation, and all sorts of other good stuff. Whoo!
Anyways, here's more or less what the current state of affairs looks like for our yet-to-be-named CS248 video game project (excuse the shoddy YouTube quality):
We're using OpenGL for graphics, SDL for input and windowing/etc, SDL_mixer for audio, and a handful of other libraries too (SOIL, GLEW, etc).
So...lots of things going on here.
First off, we have our audio calibration screen, which right now is also serving as a test screen for our blob physics engine. Since we're making a music game, one of our highest priorities is making sure that everything is as tightly synced to the music as possible. We're using SDL_Mixer for our audio, but using custom music callbacks to ensure that we have precise information on exactly where we are in the music. We also compensate for the slight audio delay that results from audio buffering (which is what the calibration screen does). Whenever possible, we play sound effects early (compared to the graphics/gameplay) to compensate for audio buffer latency.
The blob engine was done by David so I'm guessing he'll have a lot more to say about that, but essentially, we figured early on that since we have absolutely no experience with 3d modeling and 3d animation, it would probably be better (and more interesting?) to base the animation of our characters/entities on physics simulations rather than trying to build our own 3d models. So we (and by "we" I mean David) have come up with this engine that constructs a sphere and then hooks up the vertices with spring forces and such so that it has some element of elasticity. The cool part is, we can even add point forces and planar forces and all sorts of other things to deform the blob in cool ways. You can see this in the calibration screen (when we press a direction, it applies a force to deform the blob and you can see it propagate through), as well as in the main game (the player blob reacts to the walls as it bounces off of them). We haven't implemented it yet, but eventually we're hoping to use random forces to procedurally generate different enemy blob models. (right now all of the enemies just look like perfect spheres...) The energy bullets also slightly deform the blob as they spiral in and get absorbed, which is cool :)
Of course, while trying to get the actual physics working right, we've run into a plethora of fantastic disasters...everything you can imagine, including having the blob collapse in on itself, explode out to infinity, become a spiky mess, stretching out to become a pong-like paddle, and...well, all sorts of other indescribable frankenstein creations. It's been fun...
So, as for the actual game...
It's a music-based game. You control a blob character that bounces up and down on the left, and enemy blobs (though right now they're just smooth spheres) spawn on the right. The enemies shoot colored energy bullets at you, which hit you on the beat. I implemented a basic particle effect system, so each bullet is actually made up of a bunch of particles. The cool part here is that the orbit radius of the particles responds to the beat...and even cooler, the particles actually orbit faster on the beat too!
Anyhow, each bullet color corresponds to a certain rhythmic pattern (e.g. red = 2 eighth notes, green = 1 quarter note, blue = eighth rest + eighth note). If you tap 'F' to the correct rhythmic pattern as the bullet hits you, you'll "absorb" the bullet and gain some energy (with a nice happy chime sound). If you don't, or screw up, the bullet will instead hit you and make you lose energy (with a not-so-happy sound).
I should note that the bullet-patterns aren't specified in our code anywhere--instead, we're using MIDI annotations to specify them. This works very nicely with my music production workflow in FL Studio because I can just make a separate annotations track and lay it out in the same view as my actual song patterns. Eventually ("eventually" meaning later tonight) we're also going to implement random bullet generation, which will also be controlled by MIDI control values. By the way, the frequency of enemy spawns is also controlled by MIDI control values, and is pseudorandom based on the seed you specify. The pseudorandomness will allow you to generate random levels, but also replay a level generated in the same way by specifying the same seed.
So far, this is just a pretty standard music game where you press a single button in time to oncoming events. But here comes the twist: the enemies also slowly drift over to your side of the screen, and after enough time, they'll slam into you, dealing a considerable amount of damage to your energy that you can't avoid.
So how to deal with that? Well, we haven't implemented it yet, but by pressing 'J' in specific rhythms, you'll be able to spend your energy to launch cool attacks at the enemy blobs! Of course, you'll have to time your rhythms in order to aim your attacks at the right height level, and do this in the midst of absorbing bullets with 'F' as well!
More powerful attacks will require more complex rhythms to be pressed, and will also require more energy to be used up, so there's a certain risk/reward factor we're hoping will be interesting--powerful attacks will be much more effective at clearing the screen of enemies, but at the risk of being harder to perform, and using up more of your health.
So that's our game! Of course, there's a lot of work to be done--we haven't even started doing attacks, for instance...but we're already well on our way, and even in its current state it's pretty cool.
I should note that the song we're currently using is something I basically composed on my laptop using FL Studio concurrently as a break activity from working on the code. It actually started off as a one-measure loop, all on middle C, but that got old to listen to real fast, so I gave it some actual pitches and expanded it some more. Then when that got old, I added drums, and...well, you get the idea.
It certainly helps that I've had so much experience doing OHC that making music quickly is pretty much a no-brainer for me at this point. Since each level of our game is going to be based entirely on the song plus associated MIDI annotations, this means I'm going to be able to pump out a lot of levels really easily, which is great!
From here, there's much to be done; for example sphere mapping to make the player blob reflective, random note generation (i.e. more MIDI processing), proper shaders for things like particle effects, getting started on player attacks, random background terrain generation, and all sorts of other good stuff. Whoo!
Subscribe to:
Posts (Atom)