Olivawgood name, isn't it?the foot of mt fujiRegistered Userregular
edited February 2009
The premise of this game is interesting enough but if it's based around rhythm the music would have to be pretty damn good or else the whole thing sort of falls on it's face
Is there any way to sort of do an Audiosurf and have people play the game with their own music? Or is this above and beyond the scope of this project?
Either finding or making royalty-free music that's good enough to listen to is something I'll need help with. An alternative is to make the game with commercial tracks in mind and distribute it without music. The user would then have to go buy the songs on iTunes or something and we'd convert them. I don't like that solution so much because it lends its self to someone pirating all the music and making an unauthorized complete distribution. Then I could be in hot water because of what someone else has done, not to mention I lose control over the distribution of the game.
I got sick of the problems with the rhythm concept so today I gave the overall class structure a good overhaul. I've now hit critical mass for code reuse and power. Check out this quick new demo. The first segment shows off AI and a new object type. The second segment shows the power of object-oriented programming.
Since alpha 3 was wildly popular (zero downloads! a new record!), I'm going to be putting a lot less work into making this accessible right away and a lot more work into forming something that's more like a game than a toy. Those builds take an hour or so to package up, that's precious free time for zero downloads.
Some things that I've done since alpha 3:
Player movement was entirely rewritten. Physics collisions were fun and all but caused too many problems. People expect a platformer to behave in certain ways. Missing a ledge by 1 pixel only to bounce off it hurtling in the opposite direction felt cheap and wrong. The way the player stuck to walls I thought would be a fun part of the gameplay, but was really just an elaborate bug in the collision detection. Plus it got annoying the way you couldn't jump if you were running at a wall surface.
The physics system is still in there for non-player/enemy objects. We can use it for projectiles or effects.
I moved physics behaviors into the game object classes, so object types get to determine if they bounce off of or slide along surfaces. This also enables relative velocities, so moving platforms are possible and will even transfer momentum when they stop. That'll create some interesting situations.
The camera now tracks the player instead of being glued to him. If you suddenly jump across the level (respawning), it scrolls, sort of like a Sonic game. I added some slack to the tracking too, so little pixel variations in the ground don't shake the whole screen like an earthquake.
I've implemented the system by which objects (including the player) take and deal damage. The player can punch, which deals 10 damage, killing both my balloon and Jumper test objects.
I've added a few features to the graphical tiling system. You can now tell tiles to repeat any number of times along the x and/or y axes. This adds a great deal of power to the system (and makes it actually useful!)
I did my best to redraw the main character. I whipped up the initial sprites quickly and I was having trouble adding new frames without making the animations jarring. Now everything looks pretty smooth. There are now animations for standing, jumping and punching.
Well, I guess I might as well keep the thread up to date.
The game mechanics are coming along nicely. The combat system is done. Characters have health, they can hit each other, kill each other, etc. There are hitboxes, invincibility frames, hitstun and more. Everything you'd expect in a typical brawler. If you check one video of this game out, check out this one.
I can't wait to get home and try this. I have the sinking feeling that it won't run well for me, but I'll give it a shot.
Have you scrapped the rhythm-based sections completely?
As for music, what file format does it have to be in? I've been looking for a reason to get back into making some tracks, and I wouldn't mind using this as that reason at all.
I'll do a little bit of polishing and bundle up Alpha 4 this afternoon for you if you really want to play around. Alpha 3 in the OP is really old and contains almost none of the cool stuff in that video.
The music is in .ogg format right now, but if a musician came along who wanted to make music, I could change formats easily to midi, mod, or anything that has some sort of Python binding (virtually everything under the sun). Everything is modular and the only thing that depends on the music is the rhythm code, which will need a full rewrite anyway.
The rhythm portions of the game are still there but I turned off all the visualizations because I've put its development on the back burner. I couldn't figure out how to fit it in well, so I kept things flexible and moved on to platforming and combat for now. If I were to uncomment a few lines, it would come right back, like it was on the screenshots on the last page.
Don't go out of your way to make Alpha 4 yet. You're better off spending your time working on code than doing that. To be honest, I haven't even been able to see a screenshot of this, let alone the vids (at work, and most stuff is blocked). It's more the concept that sounds interesting to me. I'll check it out tonight and listen to the sample song you put up to get an idea.
Out of curiosity, what style music are you looking for? If you could pick a few games that have the style you want, I can work from there and see what you think.
I honestly have on idea what .ogg is for a format, but I can certainly get stuff into a .mid/.mod format. Regardless, I can work on some stuff and go from there.
Don't go out of your way to make Alpha 4 yet. You're better off spending your time working on code than doing that. To be honest, I haven't even been able to see a screenshot of this, let alone the vids (at work, and most stuff is blocked). It's more the concept that sounds interesting to me. I'll check it out tonight and listen to the sample song you put up to get an idea.
Out of curiosity, what style music are you looking for? If you could pick a few games that have the style you want, I can work from there and see what you think.
I honestly have on idea what .ogg is for a format, but I can certainly get stuff into a .mid/.mod format. Regardless, I can work on some stuff and go from there.
.ogg is just a lossy compression of wave data. Similar to MP3, but royalty-free.
As for style, anything, really. Techno-type stuff is the easiest to make and find, so that's what I've been using. Anything with a good beat is ok, really. It just needs to work together with the level design. Ambient cave noises in a cave level, major key strings for happy outdoors levels. Anything. Let me know what you think tonight.
Holy shit, that was a lot of work. I decided that if I wanted my game to be a deep, unique experience, I'd really need to step up my ability to create dynamic levels. I revamped the entire system by which you define triggers to allow for much more rich creations. Then I wrote up documentation because hell if I'll be able to keep it all straight.
Trigger System Documentation
Overview
The game logic built on top of each level is made up of three structures: Effects, Conditions, and Triggers. Effects are actions the level designer can script into the level's config file. Conditions are tests to see if the current state of gameplay meets certain criteria. Triggers tie conditions to effects, allowing the level designer to make things happen given a certain set of circumstances.
Effects
Effects are in-game events that you can cause. They can be anything from creating an enemy onscreen to displaying a message for the player. To define an effect, in the properties file, insert a blank line and write: effect=EFFECT_NAME . EFFECT_NAME can be any name of your choice. On the next line, define an action, such as "spawn" or "block". Each of these actions takes a different format. Here is an example of an effect that spawns a Jumper enemy at in-game coordinates (100,100). The first coordinate is the X-value, starting with 0 at the left edge of the level. The second is the Y-value, starting with 0 at the top of the level.
The effect is named "MAKE_A_JUMPER" and the enemy spawned in at (100,100) is tagged as "MY_JUMPER". That way, the game knows exactly which instance of the enemy this effect made, and you can refer back to it later.
Multiple actions can be taken in each effect, but not actions of the same type. For example:
This effect enacts a block, then spawns in another Jumper enemy. A block is an in-game event that restricts the player's movement (and any enemies spawned while it is in effect) to a rectangle. You can read about them later in the document.
The order in which you list actions within an event actually does not matter. Events execute their actions in an arbitrary order that is subject to change. The jumper in the pervious example may or may not actually be confined to the block, as it might be spawned before the block is enacted. To ensure this does not happen, create separate events when things must happen in a specific order.
Here I've give two effects the same name. When this shared effect name is called, each effect under that name is activated in the order of definition. This is a quick way to ensure that multiple actions take place in the order you expected (or to activate the same action multiple times with one name to, say, spawn 50 enemies at once).
Conditions
Conditions are in-game events that you can detect. They are defined similarly to effects. To define a condition in the properties file, insert a blank line and write: condition=CONDITION_NAME. On the next line, define a test, such as "position" or "dead". Example:
This defines a test to see if the object named PLAYER has entered the rectangle defined after. (PLAYER is internally defined as the player object, but this could be set to any object name, including objects spawned by effects). Multiple tests may be set in the same condition, but these tests must be of different types. For example:
For a condition to return true, all of its tests must return true at the same time. As with effects, several conditions may be listed under the same name. All of these tests must return true at the same time for the condition to be satisfied. This is a good way to run two tests of the same type with one name.
condition=JUMPERS_DEAD
dead=MY_JUMPER
condition=JUMPERS_DEAD
dead=ANOTHER_JUMPER
Conditions have a sticky property to allow for some flexibility when testing for multiple conditions. If a condition has the sticky=1 property set, once it is satisfied, it will always return true. For example:
In this case, if the player kills off MY_JUMPER, it comes back, and then the player kills off ANOTHER_JUMPER, the JUMPERS_DEAD condition will return true, even though they were never dead at the same time.
In addition to all of this, conditions may have subconditions, set with the subconditions and notsubconditions properties. Subconditions are a list of conditions that must be met in order for the parent condition to return true. Likewise, notsubconditions are a list of conditions that must not be met before the condition may return true. For you programmers and engineers out there, there are effect actions to force conditions and reset sticky conditions by name, and circular references are allowed and will behave as expected. Yes, that means you can make memory configurations, like latches or flip-flops out of in-game events.
Alright, enough of that. Now for an example of subconditions:
Since before the battle starts, it will seem that all the warriors have died, we tell the game to only check to see if the battle has ended if it started. If the player takes an alternate route through the level, then wanders in to the battle area, we don't want the battle to non-sensically start, so we make a condition for the alternate route, then add it to the notsubconditions of the battle start condition. And since the TOOK_ALTERNATE_ROUTE condition is sticky, meeting that condition disables the entire battle sequence until the level is restarted.
As you can see, this method for event testing is incredibly powerful and should allow for non-linear play and puzzles in levels if the designer so chooses.
Triggers
Triggers form links between Conditions and Events. When a condition (or series of conditions) are satisfied, an effect (or series of effects) is triggered. Triggers are much simpler than effects or conditions. A typical trigger will take this form:
This trigger will apply the effect defined as EFFECT_NAME to the game once the condition CONDITION_NAME is met. Triggers are positive edge triggered. What this means is that once the trigger's conditions are met, the effects are activated ONCE. If after this activation, the condition is no longer met, the trigger is reset and may be activated by meeting the condition again. This behavior may be overridden by setting the trigger property oneshot=1. Oneshot triggers may be activated once and never reset. The property oneshot=0 will not cause any errors but is redundant
Triggers may take multiple conditions and effects in the form of a comma-separated list with no spaces. For example:
This trigger has multiple conditions, all of which must be met at once to activate its multiple effects (which will trigger all at once at this time). In addition, it has the oneshot=1 property, meaning once this trigger has been activated, it cannot be activated again.
The last feature of triggers is the notconditions property. Notconditions function exactly the same as conditions, only the testing logic is inverted. The listed notconditions must test to be false at the same time the conditions test true before the trigger may activate. Example:
As you can see, these three objects provide an incredibly powerful set of tools for creating puzzles and complex level interactions. As with any type of programming or scripting, a real example is worth a thousand pages of documentation. So play some of the simple test levels in the game and check out their condition, effect, and trigger definitions.
Effect Options and Actions
kill=OBJECT_NAME
Tell every object in play named OBJECT_NAME to die.
spawn=OBJECT_NAME,ObjectType,X,Y
Create a new object of ObjectType, named OBJECT_NAME, at location (X,Y). Coordinates are top-left based, meaning X=0 is the leftmost part of the level and Y=0 is the topmost.
block=LEFT,RIGHT,TOP,BOTTOM
Prevent the player from moving outside of the rectangle defined by the edges listed. Any enemies spawned while a block is in effect will be confined as well. Activating a block will flash a stop sign on the screen.
clearblock=1
Remove the block state and allow the player to move freely. The =1 is actiua
checkpoint=X,Y
Change the player's spawn point to (X,Y) and delete all oneshot triggers that have already been activated. Flash up the checkpoint icon.
victory=NEXT_LEVEL_NAME
Immediately stop play and load up the level: NEXT_LEVEL_NAME
locktrigger=TRIGGER_NAME
Prevent a trigger from changing/activating.
forcetrigger=TRIGGER_NAME
Force a trigger to activate (regardless of if its conditions are met)
resettrigger=TRIGGER_NAME
Reset a trigger and its conditions (and their sub conditions). Resetting allows sticky conditions and oneshot or locked triggers to be activated again.
lockcondition=CONDITION_NAME
Prevent a condition from changing.
forcecondition=CONDITION_NAME
Force a condition to become true. This is most useful for sticky conditions. Otherwise, it'll flick true for just one frame.
resetcondition=CONDITION_NAME
Reset a condition. This forces the condition to false and unlocks locked conditions. This is most useful for sticky conditions.
Condition Options and Tests
sticky=1
Sticky conditions stay true once they are met. They only go false on reset.
alive=OBJECT_NAME
Check to see if any objects named OBJECT_NAME are alive.
dead=OBJECT_NAME
Check to see if all objects named OBJECT_NAME are dead.
position=OBJECT_NAME,LEFT,RIGHT,TOP,BOTTOM
Check to see if any objects named OBJECT_NAME have entered the rectangle defined by the edges given. PLAYER is hard-coded by the game to indicate the player. _ALL_ is another hard-coded value, meaning every object in play.
subconditions=CONDITION_NAME,CONDITION_NAME...
Make sure all the conditions under those condition names are satisfied before allowing this condition to be satisfied.
notsubconditions=CONDITION_NAME,CONDITION_NAME...
Make sure all the conditions under those condition names are NOT satisfied before allowing this condition to be satisfied.
I've been hoping it wouldn't come to this, but I'm at a point with this project where software rendering is no longer acceptable. It's ballooning memory requirements beyond 500MB, it is causing a simple 2D sidescroller to take up 80% of a Core2Duo 2.4GHz, it's preventing me from adding more parallax scrolling layers or using any graphical effects beyond alpha layer blending.
I'm tired of it. Throughout the project I've been working towards this moment and now I think I'm ready to make the leap. I'm switching to OpenGL for graphics rendering.
Positions have been stored in floats since the second alpha, so I'm all set there.
Collision detection and all other object interactions have been wholly independent of drawing code since alpha 3.
Python has a great OpenGL binding that will allow me to rewrite as little as possible and keep perfect multiplatform support.
Preliminary tests show that moving to OpenGL will reduce resource utilization by 75% or more. That means TONS more CPU time for physics, characters, AI, and more. I'm glad I started with software rendering because it really pressed me against a wall in terms of fitting in time for everything else and still hitting the 60FPS mark. The basics of the game engine are finished and lean, leaving me plenty of room for creative new features.
That is, once I learn OpenGL and write all new drawing code. Man, that part is going to be a pain.
Music update: SDL does have good support for the MOD format, so that's a possibility for music. It would help me reduce distribution size too.
Sweet, good to know about MOD support. I've been working a little bit here and there working on some stuff. Mostly drum/bass lines for the moment. I'll keep it somewhat simple, as I'm still not up on how the ryhthm interface is going to work, but when i'm done with a couple tracks, you'll at least have more than two songs!
You've been using pygame this whole time Zack? How easy is it to learn? If someone knows how to program in both Java and C++, would you say it should be a little easy to pick up python?
If you need a few suggestions regarding "rhythm based" gameplay (not really)... I always dreamed about a 2D scroller in which the moves of certain enemies would define the background music.
A simple scenario: You have a boss fight. The boss has 4 different main "I rape the player" move sets he changes at random intervals. If he does move set 1 for example, the music goes frantic or however the move relates to it. The boss music had one overarching theme, so that the changes are not to jarring. This could be accomplished very easily, by having 4 different musics for each move (lets assume the bosses only has 4) which are simply faded in and out. A more advanced version could be that you have a static beat in the background and while the moves are performed a secondary music track is played on the same time which includes more err... "melody". I think this thing could be accomplished very easily with a few triggers which turn off/on certain parts of the music. But In haven't experienced a game which has done it this way.
A even advanced version would be to mess with the playback tempo or distorting the music in realtime (should be possible if you use the *.mod format I think) - but better to keep it simple now.
Another question - can you already create objects made of different parts in this stage? - As you might have guessed I love fighting huge bosses.
You've been using pygame this whole time Zack? How easy is it to learn? If someone knows how to program in both Java and C++, would you say it should be a little easy to pick up python?
Definitely. I went in to this project knowing C++, C#, and Java, but absolutely nothing about Python. I was able to pick it up as I went along. Some key things to know going in are:
Statements are terminated by a newline. There's no semicolon at the end.
Lines that start a conditional or loop end in a colon. This is enforced before the code runs. It still catches me.
Blocking of code is done with indentation of each line, not braces. Indentation really matters. It actually keeps code readable. You'll get used to it quickly.
"var++" is not a valid construct but "var+=1" is.
Class definitions and such are much less verbose than other languages. Look it up once and you'll likely remember it cold. Unlike C++ or Java, for me at least.
Python is is NOT weakly typed. It's strongly typed just like C++ or Java. Variables MUST be the correct type to work. However, it is dynamically typed, which was a new concept for me. You never define the type of a variable, because a variable is really just a name that links to an object. That object could be an int, a float, a class, whatever. You can change the type of a variable as you go.
Let's say you have an int, position. You feed the function move_left() your variable. move_left wants a float. So on the function call it implicitly converts. Then the function returns your new position as a float, which you assign back to position. You'd expect an error or at least a warning about data loss, right?
Wrong. It does NOT convert back because "position" doesn't have a type, nothing does. So now a float sits under the name "position". Everything has a type, Python is strongly typed. It's just that it can and does change the types of your variables at the drop of a hat.
position=int(35)
position = move_left(position)
print str(position)
>> 34.02
Just be aware of it. If you know this is going on, you can use it to your advantage and save tons of labor. If you don't, it can cause untold headaches as you track down some bizarre bug with your technically flawless code.
pygame is a really nice way to start making games. Python is a high-level language with garbage collection, completely cross-platform, and relatively fast. Pygame does all the work filling in the gaps where most people get lost making their first game. It handles loading images and sounds, drawing images, playing sounds, playing music. Really, after about a day learning curve, you're working on how your game plays and that's it. The technicals fade away and you haven't sacrificed one bit of flexibility. Even if you run into a limitation in Pygame like I have, you can always do a little work and suddenly you're multithreading or drawing with OpenGL without rewriting much of anything. It's great from prototype to serious game.
(Also, since Python can link to C++ libraries, there's never any worry about using any tech you find in your game. Stuff like OpenAL for surround sound or some physics library will always have some way of working with your game.)
If you need a few suggestions regarding "rhythm based" gameplay (not really)... I always dreamed about a 2D scroller in which the moves of certain enemies would define the background music.
A simple scenario: You have a boss fight. The boss has 4 different main "I rape the player" move sets he changes at random intervals. If he does move set 1 for example, the music goes frantic or however the move relates to it. The boss music had one overarching theme, so that the changes are not to jarring. This could be accomplished very easily, by having 4 different musics for each move (lets assume the bosses only has 4) which are simply faded in and out. A more advanced version could be that you have a static beat in the background and while the moves are performed a secondary music track is played on the same time which includes more err... "melody". I think this thing could be accomplished very easily with a few triggers which turn off/on certain parts of the music. But In haven't experienced a game which has done it this way.
A even advanced version would be to mess with the playback tempo or distorting the music in realtime (should be possible if you use the *.mod format I think) - but better to keep it simple now.
Another question - can you already create objects made of different parts in this stage? - As you might have guessed I love fighting huge bosses.
Multi-part bosses were something that I had in mind when I designed the game. The way they'd work is you'd spawn in the "core" of the boss, which would then spawn in its other parts. In-game objects can refer to one-another and spawn one-another. In the videos, you see the player tossing spiked balls. Those are just the enemies he fights with no hitbox for the environment and no AI.
Back to bosses, you could kill the other parts independently of the boss (and have them fall off/regrow) or they could share health with the boss. Sharing health would be a little tricky but not much more than overriding the "hit" method that gets invoked when an object receives a blow and forwarding it to the core object. In all, probably one or two lines of code. I've kept things as flexible as humanly possible, no small thanks to the way Python works.
Adding the musical element to the bosses would be easy enough, but I'd need to have a musical system to start with. None of that is written, so anything is possible there. I like your idea though. I'm adding it to my mental list of ways could bring rhythm back in.
Any hope for a linux binary or something like that?
I don't have the time or resources to figure out a good way to bundle everything up for Linux. The game absolutely will run under Linux if you get the data and source and run the "run_game.py" script.
You'll just need to make sure you have all the dependancies. Specifically, pygame and numpy.
Wow, thanks for the info Zack. When I get a break from classes I think I'll pick it up. I've been using Game Maker, but it feels so... Unprofessional. If I want to make a real game I think I am going to have to use pygame.
After a self-taught crash-course running from OpenGL 1.1 to 2.1, I got a moderately-featured sprite renderer working. I'm currently cleaning up the OpenGL drawing classes used in the prototype renderer to be drop-in replacements for the sprite classes in the game. Due to overhead, the performance boost won't be as big as I'd hoped, but my drawing capabilities have gone through the roof. Scaling, rotation, particle effects, and shader programs (heat ripples, water), are all basically "free" operations, independent of the performance of the game logic. I can also draw way more sprites, since the overhead is per sprite group, not per sprite.
I can only draw about 20 different kinds of sprites at once, but man can I draw a lot of them.
Get your fucking rap face on, little man, the project is now officially back off hold.
My OpenGL rewrite is nearing completion. I finished my sprite and collection classes (which load the sprites into VBOs and stream them to the graphics card for maximum performance). Of course, once it was all working right, it looked nearly the same as it did before, only with significantly less CPU usage and a much smoother frame rate (and no menus or HUD because I've yet to rewrite them for OpenGL). Yes, it's still entirely written in Python and fully cross-platform.
Some screens: I arbitrarily rotated the camera to show off what I've done.
It's so funny how superficial changes to a video game can really screw with you. I never realized how important the character animations are in a platformer. I mean, I knew they made the game look good, but they can drastically alter perception of how responsive the controls feel and the kind of visceral reaction you get from a game.
I implemented sprite rotation in OpenGL and since the code runs every sprite update anyway, I decided to add some rotation to the main character animation in lieu of true walking.
What I do is rotate the player sprite based on its horizontal velocity, so when you're running, it looks like you're leaning into it a little. When you jump, I scale the rotation up so it looks like more of a dive in the beginning, but as the vector shifts back toward the ground, you straighten out for the landing. It actually looks very good. The way the sprite is drawn, I don't even have to alter the hitboxes because it's really close enough.
But holy shit does it screw with you. It gives the character more visceral feel when you control him. At first I started missing jumps that I've made a million times while testing. The game feels a lot more alive than it did before even though no mechanics have changed at all. On the downside, it makes turns seem more sluggish. It doesn't make sense, but I guess I'll take the good with the bad.
I'll make a video soon, showing off the new animation and a few new OpenGL rewrite features.
Also, does anyone with some knowledge of OpenGL know how to make particles some shape other than a square? No matter how funny I think it is, Playstation 1 era blood looks a little out of place in my game.
ZackSchilling on
0
Zilla36021st Century. |She/Her|Trans* Woman In Aviators Firing A Bazooka. ⚛️Registered Userregular
Also, does anyone with some knowledge of OpenGL know how to make particles some shape other than a square? No matter how funny I think it is, Playstation 1 era blood looks a little out of place in my game.
I read the link. It talks about multisampling and distance attenuation but nothing about changing the shape from a square to a circle (or textured polygon).
ZackSchilling on
0
Zilla36021st Century. |She/Her|Trans* Woman In Aviators Firing A Bazooka. ⚛️Registered Userregular
edited March 2009
Sorry. Yeah. Tired. :P
I'm sure though you must be able to simulate a 'particle' though using a GLSL vertex shader program, though right? After all a circle (or something circular) is just a square with vastly more points to it; right?
I don't know how much you intend to keep from this or where you want to go with it, but a random thought that crept into my mind while watching the videos: when under water his arms and legs should disappear and he should be able to move with zero/low gravity.
I don't know how much you intend to keep from this or where you want to go with it, but a random thought that crept into my mind while watching the videos: when under water his arms and legs should disappear and he should be able to move with zero/low gravity.
The original concept is that the arms and legs are some sort of musical energy streaming out. Since the guy's a robot, I figured it would make sense for him to sink. That said, any water in the video is strictly cosmetic and there to show off alpha blending. I'm thinking eventually I'll code in water to the physics and have it modify movement somehow. Maybe increasing friction and allowing "air" jumps to let the player swim.
On a stormy night, a secret robotics factory run by an unseen mad scientist is struck by lighting, accidentally freeing thousands of creations.
One project freed is the player, a man-sized robot with no mechanical arms or legs. Instead, he has black disks mounted on its torso that create energy jets. His torso is bean-shaped with a round head mounted on top. By design, the power of the jets must be regulated by an external waveform source. He wears what look like large studio monitor headphones but are actually a bridge between the jet regulation signal and the jet power controller. The jet regulation is driven by compact discs. Initially this is just an a-melodic test pattern.
(Stage 1)
The robot powers on with the other creations in the lightning storm and makes his way out of the factory, avoiding some of the slower creations in the process. He finds a music CD right away in the lab to replace the boring test pattern. This music is the soundtrack for the first level. There are some hazards to escape but not much more than a few live power lines that have fallen across the floor. The player walks past a giant cage ripped open. A few spiked balls linger here, idly jumping up and down in place.
(Stage 2)
The robot makes his way out of the lab and into the forest that surrounds the apparently secluded building. It is dawn. Traversing the forest, the robot begins to encounter more brainless jumping spiked balls, apparently escaped from the giant cage in the lab. They damage the robot if run in to but do not seek to harm him. Nests sit in the trees that are now on all sides. Spiked balls are hitting the nests and knocking them down. Birds are grabbing the spiked balls and flying away with them.
(Stage 3)
Eventually, the robot makes his way out of the forest and into some grassy hills. The spiked balls are becoming more numerous. Some are lit up red and seem to fly at the player. Birds are flying across the level with the spiked balls (but do not drop their payload unless hit).
(Stage 4)
The hills climb higher and higher and the birds become more numerous. The hills become mountains and the birds are seen flying up with balls and down without them. After climbing to the top of the mountain, the player comes across a giant pile of spiked balls, now inert. One last bird, a little red Cardinal, files in and drops a red blinking ball on the pile. All the balls turn red and start blinking, then jumping in unison. The birds retreat to a safe watching distance and the balls turn on the robot.
The robot dispatches all the jumping spiked balls and the birds come to celebrate, flying circles around him, the red cardinal landing on the headphones. It is now dusk. The robot comes to an overlook and sees the lights of civilization. All but one bird leaves. It remains perched on the headphones. It is the bird that dropped the red, blinking ball. The robot continues on towards a path down the mountain.
I just watched the newest demo on youtube after not looking at this in a while.
I have to say the whole camera rotation thing looks like it would make for a lot of interesting 2d platformer stuff. It needs some tweaking on delay before rotating, though, otherwise it will make people sick.
God damn why can't I focus long enough to learn how to program cool stuff like this.
The camera motion was just an exaggerated demo. The only effects that might make it into the game are the zoom (to achieve resolution independence or pan over levels in cutscenes) and maybe a SLIGHT tilt to give an enhanced sense of speed and better view of the level. The janky camera in the demo came from certain rotations getting read directly from the physics rather than being their own buffered and speed limited values.
Posts
Edit: Works wonderfully. :^:
FFXIV: Tchel Fay
Nintendo ID: Tortalius
Steam: Tortalius
Stream: twitch.tv/tortalius
It could still work.
Is there any way to sort of do an Audiosurf and have people play the game with their own music? Or is this above and beyond the scope of this project?
PSN ID : DetectiveOlivaw | TWITTER | STEAM ID | NEVER FORGET
From earlier:
My dev process:
- find an artist
- hug him/her to death and bask in their reflected glory
- ???
- PROFIT!
http://www.youtube.com/watch?v=fjjFOItdHeI&fmt=18
I bundled up a third Alpha release for google.
Mac OS X Binary: http://project906.googlecode.com/files/platformer-osx-a3.zip
Windows Binary: http://project906.googlecode.com/files/platformer-win-a3.zip
Data Files (REQUIRED TO RUN): http://project906.googlecode.com/files/platformer-data-a3.zip
(Decompress and place data folder side-by-side with the app/exe)
Controls:
Movement - Arrows
Run - Left Ctrl
Spawn Jumper - Tab
Spawn Balloon - Q
Swap Bodies with a Jumper - W
http://dl-client.getdropbox.com/u/107712/Title%20Screen.mp3
(I need help with the music very badly)
Some things that I've done since alpha 3:
Player movement was entirely rewritten. Physics collisions were fun and all but caused too many problems. People expect a platformer to behave in certain ways. Missing a ledge by 1 pixel only to bounce off it hurtling in the opposite direction felt cheap and wrong. The way the player stuck to walls I thought would be a fun part of the gameplay, but was really just an elaborate bug in the collision detection. Plus it got annoying the way you couldn't jump if you were running at a wall surface.
The physics system is still in there for non-player/enemy objects. We can use it for projectiles or effects.
I moved physics behaviors into the game object classes, so object types get to determine if they bounce off of or slide along surfaces. This also enables relative velocities, so moving platforms are possible and will even transfer momentum when they stop. That'll create some interesting situations.
The camera now tracks the player instead of being glued to him. If you suddenly jump across the level (respawning), it scrolls, sort of like a Sonic game. I added some slack to the tracking too, so little pixel variations in the ground don't shake the whole screen like an earthquake.
I've implemented the system by which objects (including the player) take and deal damage. The player can punch, which deals 10 damage, killing both my balloon and Jumper test objects.
I've added a few features to the graphical tiling system. You can now tell tiles to repeat any number of times along the x and/or y axes. This adds a great deal of power to the system (and makes it actually useful!)
I did my best to redraw the main character. I whipped up the initial sprites quickly and I was having trouble adding new frames without making the animations jarring. Now everything looks pretty smooth. There are now animations for standing, jumping and punching.
The game mechanics are coming along nicely. The combat system is done. Characters have health, they can hit each other, kill each other, etc. There are hitboxes, invincibility frames, hitstun and more. Everything you'd expect in a typical brawler. If you check one video of this game out, check out this one.
http://www.youtube.com/watch?v=TJte--n6DS0
(Sorry about the sound and frame rate at times, something went awry with the capture program)
Have you scrapped the rhythm-based sections completely?
As for music, what file format does it have to be in? I've been looking for a reason to get back into making some tracks, and I wouldn't mind using this as that reason at all.
The music is in .ogg format right now, but if a musician came along who wanted to make music, I could change formats easily to midi, mod, or anything that has some sort of Python binding (virtually everything under the sun). Everything is modular and the only thing that depends on the music is the rhythm code, which will need a full rewrite anyway.
The rhythm portions of the game are still there but I turned off all the visualizations because I've put its development on the back burner. I couldn't figure out how to fit it in well, so I kept things flexible and moved on to platforming and combat for now. If I were to uncomment a few lines, it would come right back, like it was on the screenshots on the last page.
Out of curiosity, what style music are you looking for? If you could pick a few games that have the style you want, I can work from there and see what you think.
I honestly have on idea what .ogg is for a format, but I can certainly get stuff into a .mid/.mod format. Regardless, I can work on some stuff and go from there.
.ogg is just a lossy compression of wave data. Similar to MP3, but royalty-free.
As for style, anything, really. Techno-type stuff is the easiest to make and find, so that's what I've been using. Anything with a good beat is ok, really. It just needs to work together with the level design. Ambient cave noises in a cave level, major key strings for happy outdoors levels. Anything. Let me know what you think tonight.
Trigger System Documentation
The game logic built on top of each level is made up of three structures: Effects, Conditions, and Triggers. Effects are actions the level designer can script into the level's config file. Conditions are tests to see if the current state of gameplay meets certain criteria. Triggers tie conditions to effects, allowing the level designer to make things happen given a certain set of circumstances.
Effects
Effects are in-game events that you can cause. They can be anything from creating an enemy onscreen to displaying a message for the player. To define an effect, in the properties file, insert a blank line and write: effect=EFFECT_NAME . EFFECT_NAME can be any name of your choice. On the next line, define an action, such as "spawn" or "block". Each of these actions takes a different format. Here is an example of an effect that spawns a Jumper enemy at in-game coordinates (100,100). The first coordinate is the X-value, starting with 0 at the left edge of the level. The second is the Y-value, starting with 0 at the top of the level.
effect=MAKE_A_JUMPER
spawn=MY_JUMPER,Jumper,100,100
The effect is named "MAKE_A_JUMPER" and the enemy spawned in at (100,100) is tagged as "MY_JUMPER". That way, the game knows exactly which instance of the enemy this effect made, and you can refer back to it later.
Multiple actions can be taken in each effect, but not actions of the same type. For example:
effect=ANOTHER_EFFECT
block=100,900,10,400
spawn=ANOTHER_JUMPER,Jumper,100,100
This effect enacts a block, then spawns in another Jumper enemy. A block is an in-game event that restricts the player's movement (and any enemies spawned while it is in effect) to a rectangle. You can read about them later in the document.
The order in which you list actions within an event actually does not matter. Events execute their actions in an arbitrary order that is subject to change. The jumper in the pervious example may or may not actually be confined to the block, as it might be spawned before the block is enacted. To ensure this does not happen, create separate events when things must happen in a specific order.
effect=ANOTHER_EFFECT
block=100,900,10,400
effect=ANOTHER_EFFECT
spawn=ANOTHER_JUMPER,Jumper,100,100
Here I've give two effects the same name. When this shared effect name is called, each effect under that name is activated in the order of definition. This is a quick way to ensure that multiple actions take place in the order you expected (or to activate the same action multiple times with one name to, say, spawn 50 enemies at once).
Conditions
Conditions are in-game events that you can detect. They are defined similarly to effects. To define a condition in the properties file, insert a blank line and write: condition=CONDITION_NAME. On the next line, define a test, such as "position" or "dead". Example:
condition=CONDITION_NAME
position=PLAYER,400,430,0,1000
This defines a test to see if the object named PLAYER has entered the rectangle defined after. (PLAYER is internally defined as the player object, but this could be set to any object name, including objects spawned by effects). Multiple tests may be set in the same condition, but these tests must be of different types. For example:
condition=CONDITION_NAME
position=PLAYER,400,430,0,1000
dead=MY_JUMPER
For a condition to return true, all of its tests must return true at the same time. As with effects, several conditions may be listed under the same name. All of these tests must return true at the same time for the condition to be satisfied. This is a good way to run two tests of the same type with one name.
condition=JUMPERS_DEAD
dead=MY_JUMPER
condition=JUMPERS_DEAD
dead=ANOTHER_JUMPER
Conditions have a sticky property to allow for some flexibility when testing for multiple conditions. If a condition has the sticky=1 property set, once it is satisfied, it will always return true. For example:
condition=JUMPERS_DEAD
sticky=1
dead=MY_JUMPER
condition=JUMPERS_DEAD
sticky=1
dead=ANOTHER_JUMPER
In this case, if the player kills off MY_JUMPER, it comes back, and then the player kills off ANOTHER_JUMPER, the JUMPERS_DEAD condition will return true, even though they were never dead at the same time.
In addition to all of this, conditions may have subconditions, set with the subconditions and notsubconditions properties. Subconditions are a list of conditions that must be met in order for the parent condition to return true. Likewise, notsubconditions are a list of conditions that must not be met before the condition may return true. For you programmers and engineers out there, there are effect actions to force conditions and reset sticky conditions by name, and circular references are allowed and will behave as expected. Yes, that means you can make memory configurations, like latches or flip-flops out of in-game events.
Alright, enough of that. Now for an example of subconditions:
condition=BATTLE_ENDED
sticky=1
dead=WARRIORS
subconditions=START_BATTLE
condition=START_BATTLE
sticky=1
position=PLAYER,500,530,0,1200
notsubconditions=TOOK_ALTERNATE_ROUTE
condition=TOOK_ALTERNATE_ROUTE
sticky=1
position=PLAYER,300,330,1200,1400
Since before the battle starts, it will seem that all the warriors have died, we tell the game to only check to see if the battle has ended if it started. If the player takes an alternate route through the level, then wanders in to the battle area, we don't want the battle to non-sensically start, so we make a condition for the alternate route, then add it to the notsubconditions of the battle start condition. And since the TOOK_ALTERNATE_ROUTE condition is sticky, meeting that condition disables the entire battle sequence until the level is restarted.
As you can see, this method for event testing is incredibly powerful and should allow for non-linear play and puzzles in levels if the designer so chooses.
Triggers
Triggers form links between Conditions and Events. When a condition (or series of conditions) are satisfied, an effect (or series of effects) is triggered. Triggers are much simpler than effects or conditions. A typical trigger will take this form:
trigger=TRIGGER_NAME
conditions=CONDITION_NAME
effects=EFFECT_NAME
This trigger will apply the effect defined as EFFECT_NAME to the game once the condition CONDITION_NAME is met. Triggers are positive edge triggered. What this means is that once the trigger's conditions are met, the effects are activated ONCE. If after this activation, the condition is no longer met, the trigger is reset and may be activated by meeting the condition again. This behavior may be overridden by setting the trigger property oneshot=1. Oneshot triggers may be activated once and never reset. The property oneshot=0 will not cause any errors but is redundant
Triggers may take multiple conditions and effects in the form of a comma-separated list with no spaces. For example:
trigger=TRIGGER_NAME
oneshot=1
conditions=CONDITION_NAME,ANOTHER_CONDITION,THIRD_CONDITION
effects=EFFECT_NAME,ANOTHER_EFFECT,BUTTERFLY_EFFECT
This trigger has multiple conditions, all of which must be met at once to activate its multiple effects (which will trigger all at once at this time). In addition, it has the oneshot=1 property, meaning once this trigger has been activated, it cannot be activated again.
The last feature of triggers is the notconditions property. Notconditions function exactly the same as conditions, only the testing logic is inverted. The listed notconditions must test to be false at the same time the conditions test true before the trigger may activate. Example:
trigger=DRIVE_CAR_FORWARD
conditions=IS_STARTED,GAS_PRESSED
notconditions=BRAKE_PRESSED,IN_PARK
effects=MOVE_FORWARD
As you can see, these three objects provide an incredibly powerful set of tools for creating puzzles and complex level interactions. As with any type of programming or scripting, a real example is worth a thousand pages of documentation. So play some of the simple test levels in the game and check out their condition, effect, and trigger definitions.
Effect Options and Actions
kill=OBJECT_NAME
Tell every object in play named OBJECT_NAME to die.
spawn=OBJECT_NAME,ObjectType,X,Y
Create a new object of ObjectType, named OBJECT_NAME, at location (X,Y). Coordinates are top-left based, meaning X=0 is the leftmost part of the level and Y=0 is the topmost.
block=LEFT,RIGHT,TOP,BOTTOM
Prevent the player from moving outside of the rectangle defined by the edges listed. Any enemies spawned while a block is in effect will be confined as well. Activating a block will flash a stop sign on the screen.
clearblock=1
Remove the block state and allow the player to move freely. The =1 is actiua
checkpoint=X,Y
Change the player's spawn point to (X,Y) and delete all oneshot triggers that have already been activated. Flash up the checkpoint icon.
victory=NEXT_LEVEL_NAME
Immediately stop play and load up the level: NEXT_LEVEL_NAME
locktrigger=TRIGGER_NAME
Prevent a trigger from changing/activating.
forcetrigger=TRIGGER_NAME
Force a trigger to activate (regardless of if its conditions are met)
resettrigger=TRIGGER_NAME
Reset a trigger and its conditions (and their sub conditions). Resetting allows sticky conditions and oneshot or locked triggers to be activated again.
lockcondition=CONDITION_NAME
Prevent a condition from changing.
forcecondition=CONDITION_NAME
Force a condition to become true. This is most useful for sticky conditions. Otherwise, it'll flick true for just one frame.
resetcondition=CONDITION_NAME
Reset a condition. This forces the condition to false and unlocks locked conditions. This is most useful for sticky conditions.
Condition Options and Tests
sticky=1
Sticky conditions stay true once they are met. They only go false on reset.
alive=OBJECT_NAME
Check to see if any objects named OBJECT_NAME are alive.
dead=OBJECT_NAME
Check to see if all objects named OBJECT_NAME are dead.
position=OBJECT_NAME,LEFT,RIGHT,TOP,BOTTOM
Check to see if any objects named OBJECT_NAME have entered the rectangle defined by the edges given. PLAYER is hard-coded by the game to indicate the player. _ALL_ is another hard-coded value, meaning every object in play.
subconditions=CONDITION_NAME,CONDITION_NAME...
Make sure all the conditions under those condition names are satisfied before allowing this condition to be satisfied.
notsubconditions=CONDITION_NAME,CONDITION_NAME...
Make sure all the conditions under those condition names are NOT satisfied before allowing this condition to be satisfied.
I'm tired of it. Throughout the project I've been working towards this moment and now I think I'm ready to make the leap. I'm switching to OpenGL for graphics rendering.
Positions have been stored in floats since the second alpha, so I'm all set there.
Collision detection and all other object interactions have been wholly independent of drawing code since alpha 3.
Python has a great OpenGL binding that will allow me to rewrite as little as possible and keep perfect multiplatform support.
Preliminary tests show that moving to OpenGL will reduce resource utilization by 75% or more. That means TONS more CPU time for physics, characters, AI, and more. I'm glad I started with software rendering because it really pressed me against a wall in terms of fitting in time for everything else and still hitting the 60FPS mark. The basics of the game engine are finished and lean, leaving me plenty of room for creative new features.
That is, once I learn OpenGL and write all new drawing code. Man, that part is going to be a pain.
Music update: SDL does have good support for the MOD format, so that's a possibility for music. It would help me reduce distribution size too.
If you need a few suggestions regarding "rhythm based" gameplay (not really)... I always dreamed about a 2D scroller in which the moves of certain enemies would define the background music.
A simple scenario: You have a boss fight. The boss has 4 different main "I rape the player" move sets he changes at random intervals. If he does move set 1 for example, the music goes frantic or however the move relates to it. The boss music had one overarching theme, so that the changes are not to jarring. This could be accomplished very easily, by having 4 different musics for each move (lets assume the bosses only has 4) which are simply faded in and out. A more advanced version could be that you have a static beat in the background and while the moves are performed a secondary music track is played on the same time which includes more err... "melody". I think this thing could be accomplished very easily with a few triggers which turn off/on certain parts of the music. But In haven't experienced a game which has done it this way.
A even advanced version would be to mess with the playback tempo or distorting the music in realtime (should be possible if you use the *.mod format I think) - but better to keep it simple now.
Another question - can you already create objects made of different parts in this stage? - As you might have guessed I love fighting huge bosses.
Definitely. I went in to this project knowing C++, C#, and Java, but absolutely nothing about Python. I was able to pick it up as I went along. Some key things to know going in are:
Statements are terminated by a newline. There's no semicolon at the end.
Lines that start a conditional or loop end in a colon. This is enforced before the code runs. It still catches me.
Blocking of code is done with indentation of each line, not braces. Indentation really matters. It actually keeps code readable. You'll get used to it quickly.
"var++" is not a valid construct but "var+=1" is.
Class definitions and such are much less verbose than other languages. Look it up once and you'll likely remember it cold. Unlike C++ or Java, for me at least.
Python is is NOT weakly typed. It's strongly typed just like C++ or Java. Variables MUST be the correct type to work. However, it is dynamically typed, which was a new concept for me. You never define the type of a variable, because a variable is really just a name that links to an object. That object could be an int, a float, a class, whatever. You can change the type of a variable as you go.
Let's say you have an int, position. You feed the function move_left() your variable. move_left wants a float. So on the function call it implicitly converts. Then the function returns your new position as a float, which you assign back to position. You'd expect an error or at least a warning about data loss, right?
Wrong. It does NOT convert back because "position" doesn't have a type, nothing does. So now a float sits under the name "position". Everything has a type, Python is strongly typed. It's just that it can and does change the types of your variables at the drop of a hat.
Just be aware of it. If you know this is going on, you can use it to your advantage and save tons of labor. If you don't, it can cause untold headaches as you track down some bizarre bug with your technically flawless code.
pygame is a really nice way to start making games. Python is a high-level language with garbage collection, completely cross-platform, and relatively fast. Pygame does all the work filling in the gaps where most people get lost making their first game. It handles loading images and sounds, drawing images, playing sounds, playing music. Really, after about a day learning curve, you're working on how your game plays and that's it. The technicals fade away and you haven't sacrificed one bit of flexibility. Even if you run into a limitation in Pygame like I have, you can always do a little work and suddenly you're multithreading or drawing with OpenGL without rewriting much of anything. It's great from prototype to serious game.
(Also, since Python can link to C++ libraries, there's never any worry about using any tech you find in your game. Stuff like OpenAL for surround sound or some physics library will always have some way of working with your game.)
Multi-part bosses were something that I had in mind when I designed the game. The way they'd work is you'd spawn in the "core" of the boss, which would then spawn in its other parts. In-game objects can refer to one-another and spawn one-another. In the videos, you see the player tossing spiked balls. Those are just the enemies he fights with no hitbox for the environment and no AI.
Back to bosses, you could kill the other parts independently of the boss (and have them fall off/regrow) or they could share health with the boss. Sharing health would be a little tricky but not much more than overriding the "hit" method that gets invoked when an object receives a blow and forwarding it to the core object. In all, probably one or two lines of code. I've kept things as flexible as humanly possible, no small thanks to the way Python works.
Adding the musical element to the bosses would be easy enough, but I'd need to have a musical system to start with. None of that is written, so anything is possible there. I like your idea though. I'm adding it to my mental list of ways could bring rhythm back in.
I don't have the time or resources to figure out a good way to bundle everything up for Linux. The game absolutely will run under Linux if you get the data and source and run the "run_game.py" script.
You'll just need to make sure you have all the dependancies. Specifically, pygame and numpy.
After a self-taught crash-course running from OpenGL 1.1 to 2.1, I got a moderately-featured sprite renderer working. I'm currently cleaning up the OpenGL drawing classes used in the prototype renderer to be drop-in replacements for the sprite classes in the game. Due to overhead, the performance boost won't be as big as I'd hoped, but my drawing capabilities have gone through the roof. Scaling, rotation, particle effects, and shader programs (heat ripples, water), are all basically "free" operations, independent of the performance of the game logic. I can also draw way more sprites, since the overhead is per sprite group, not per sprite.
I can only draw about 20 different kinds of sprites at once, but man can I draw a lot of them.
Demo:
http://www.youtube.com/watch?v=rW0Mz11BFh4
Get your fucking rap face on, little man, the project is now officially back off hold.
My OpenGL rewrite is nearing completion. I finished my sprite and collection classes (which load the sprites into VBOs and stream them to the graphics card for maximum performance). Of course, once it was all working right, it looked nearly the same as it did before, only with significantly less CPU usage and a much smoother frame rate (and no menus or HUD because I've yet to rewrite them for OpenGL). Yes, it's still entirely written in Python and fully cross-platform.
Some screens: I arbitrarily rotated the camera to show off what I've done.
I implemented sprite rotation in OpenGL and since the code runs every sprite update anyway, I decided to add some rotation to the main character animation in lieu of true walking.
What I do is rotate the player sprite based on its horizontal velocity, so when you're running, it looks like you're leaning into it a little. When you jump, I scale the rotation up so it looks like more of a dive in the beginning, but as the vector shifts back toward the ground, you straighten out for the landing. It actually looks very good. The way the sprite is drawn, I don't even have to alter the hitboxes because it's really close enough.
But holy shit does it screw with you. It gives the character more visceral feel when you control him. At first I started missing jumps that I've made a million times while testing. The game feels a lot more alive than it did before even though no mechanics have changed at all. On the downside, it makes turns seem more sluggish. It doesn't make sense, but I guess I'll take the good with the bad.
I'll make a video soon, showing off the new animation and a few new OpenGL rewrite features.
Also, does anyone with some knowledge of OpenGL know how to make particles some shape other than a square? No matter how funny I think it is, Playstation 1 era blood looks a little out of place in my game.
I'm sure though you must be able to simulate a 'particle' though using a GLSL vertex shader program, though right? After all a circle (or something circular) is just a square with vastly more points to it; right?
http://www.youtube.com/watch?v=cBFoXqKrBa8
I don't know how much you intend to keep from this or where you want to go with it, but a random thought that crept into my mind while watching the videos: when under water his arms and legs should disappear and he should be able to move with zero/low gravity.
The original concept is that the arms and legs are some sort of musical energy streaming out. Since the guy's a robot, I figured it would make sense for him to sink. That said, any water in the video is strictly cosmetic and there to show off alpha blending. I'm thinking eventually I'll code in water to the physics and have it modify movement somehow. Maybe increasing friction and allowing "air" jumps to let the player swim.
One project freed is the player, a man-sized robot with no mechanical arms or legs. Instead, he has black disks mounted on its torso that create energy jets. His torso is bean-shaped with a round head mounted on top. By design, the power of the jets must be regulated by an external waveform source. He wears what look like large studio monitor headphones but are actually a bridge between the jet regulation signal and the jet power controller. The jet regulation is driven by compact discs. Initially this is just an a-melodic test pattern.
(Stage 1)
The robot powers on with the other creations in the lightning storm and makes his way out of the factory, avoiding some of the slower creations in the process. He finds a music CD right away in the lab to replace the boring test pattern. This music is the soundtrack for the first level. There are some hazards to escape but not much more than a few live power lines that have fallen across the floor. The player walks past a giant cage ripped open. A few spiked balls linger here, idly jumping up and down in place.
(Stage 2)
The robot makes his way out of the lab and into the forest that surrounds the apparently secluded building. It is dawn. Traversing the forest, the robot begins to encounter more brainless jumping spiked balls, apparently escaped from the giant cage in the lab. They damage the robot if run in to but do not seek to harm him. Nests sit in the trees that are now on all sides. Spiked balls are hitting the nests and knocking them down. Birds are grabbing the spiked balls and flying away with them.
(Stage 3)
Eventually, the robot makes his way out of the forest and into some grassy hills. The spiked balls are becoming more numerous. Some are lit up red and seem to fly at the player. Birds are flying across the level with the spiked balls (but do not drop their payload unless hit).
(Stage 4)
The hills climb higher and higher and the birds become more numerous. The hills become mountains and the birds are seen flying up with balls and down without them. After climbing to the top of the mountain, the player comes across a giant pile of spiked balls, now inert. One last bird, a little red Cardinal, files in and drops a red blinking ball on the pile. All the balls turn red and start blinking, then jumping in unison. The birds retreat to a safe watching distance and the balls turn on the robot.
The robot dispatches all the jumping spiked balls and the birds come to celebrate, flying circles around him, the red cardinal landing on the headphones. It is now dusk. The robot comes to an overlook and sees the lights of civilization. All but one bird leaves. It remains perched on the headphones. It is the bird that dropped the red, blinking ball. The robot continues on towards a path down the mountain.
End Level 1
I have to say the whole camera rotation thing looks like it would make for a lot of interesting 2d platformer stuff. It needs some tweaking on delay before rotating, though, otherwise it will make people sick.
God damn why can't I focus long enough to learn how to program cool stuff like this.
SC2 NA: exoplasm.519 | PA SC2 Mumble Server | My Website | My Stream