Principal Coding is done. That's right. I said it, the principal coding is all done. The different classes and objects and the level system works. The game, fundamentally...works now. Of course The Thief's Tale worked for a damn long time while I was still working on it, but now I can move along to the next large part of the project, which is building all the gods damned levels.
Which leaves me a little stuck you see. My initial reaction was just to reach for my trusty graph paper and get working, but that doesn't work anymore. The levels are simply too big. If I draw them in a way to fit them all on a single page, then they wouldn't be useful since they would lose all but the largest details. I also don't want to dive in and start with nothing because I loathe a false start and redoing work that I've already built. I get the impression that's probably going to be the best idea though - just get into the editor (PaperEd?) and start messing around. Try to do something and just see how it goes.
I'm reminded of something I read once, that said that the secret to making great games is to fail often, and fail quickly. Get it all out of your system and understand why it sucks so hard. Then you can get along to the good stuff and stop dicking around.
Having said that I have worked out how I would like the Critical Path to work. First, I'll explain. The Critical Path is a concept that is used almost exclusively in games. It defines the actions that a player must take to reach the end of said game. Movies, do not have this for example, because they will get to the end all by themselves. Books require that you read them, but that's not an action that you are taking it's a process of consumption which is a different beast altogether since it's passive. (That same passive/active thing is one of the reasons that a game, fundamentally, cannot be Art {I look forward to your letters}).
Anyhow, in Paper Zeppelin the Critical Path is the way that the levels are put together. The Structure in other words. It works like this, like the Design Document says : There are 17 levels. There is a single first level, and thereafter a different level is presented based on how well the player did in the level they just completed. This breaks down into 3 paths to get to the last level which is the same for every path.
As an example, a player starts the first level, and bombs the base and get 80% kill percentage, so they go to the "Hard" next level. Here they fail to bomb the base and only get 50% kills, so they move along to the "Easy" next level (level 3 now). Here they bomb the base and get only 30% kills since the cat puked on the floor and needed immediate attention. That nets the player the "Normal" 4th stage.
This means that, although the player will get to the "end" of Paper Zeppelin in 7 levels, they will miss almost all of it requiring multiple play throughs. Each time the Critical Path of the game is decided by the player and their abilities.
Of course, as a Designer, I demand Iron Fist control over some aspects of the game, and this is one of those things. Although I don't have a say as to what level a player will go to next, I have complete control over what order the possible Critical Paths may be in.
To wit, here are some of the ideas I had for different levels, based around things that would be easy to create art for, while simultaneously offering differing gameplay experiences.
Rolling Hills
Steep Hills
Islands
Desert
Mountaintops / Sky
Mountains / Caves
Train
Floating Islands
From here I figured that I would create nighttime versions of the levels that could support it. This leaves me with, in a cool bit of serendipity, 17 levels available. Working out the order, assuming that we start with Rolling Hills (the easiest concept since it is mostly flat) I want no repeats along a path, but also don't want the repeat a concept right after another one. So is level 2 medium is Desert, then level 3 hard, level 3 medium and level 3 easy cannot be Deserts too.
This may take some doing. In the meantime, at least I know what the first level will be.
Tuesday, May 24, 2011
Wednesday, May 18, 2011
More of a Particular Kind of Fun
Particles. Again with the particles. On the one hand, I am spending 2 days now working with particles, which given there importance in the project seems kind of small. On the other, the more things I can do procedurally, then the fewer things I end up having to animate. So a couple hours may save a couple days down the line. So I decided that what I really wanted wasn't (like in the last post) a rough approximation of a Particle System, but a real one.
Particle systems are sort of basic, since they don't really have any complex logic. What you need to know is where the particle starts, what direction it's going, how long it will do this and what kind it is. You can add all kinds of extra sauce questions then, like "Would you like that particle with gravity effects?" Or "Rotation is very popular this time of year, would you like a little of that as well?" The thing that makes them distinct from normal crap like bullets and enemies is that they, by design, have a little random thrown in. This random behaviour, along with the explicit rules that are set up for different kind of particles will produce wildly different effects.
For example, I created flames, which happen pretty frequently, don't last all to long and aren't affected by the power of G. Debris (like from an explosion) last much longer, have rotation and are affected by Newton's favorite force. Same system, totally dissimilar particles that I've created.
The thing that I'm struggling with now though, is the random part. Like I was talking about here, "random" numbers really aren't. In single cases, they will work just fine. However when you get a bunch of things all working with the same "random" numbers it starts to look stupid and quite altogether rehearsed. Right now, when something is smoking it smokes in time with everything else that smokes, and goes the exact same direction because they all share the same variant direction. Considering the whole point of Particle Systems in the first place (to try to emulate a natural chaotic occurrence) it all falls apart when they all mirror each other.
Otherwise, those, and the wrecks are all finished. The only things that I have left to code are background elements, which work like the ground for the most part. So yeah. Next up on the list is a figuring out the level loading logic so I can play several levels in succession. Then add the part where it loads differently based on how well the player's did. Oddly fun.
Particle systems are sort of basic, since they don't really have any complex logic. What you need to know is where the particle starts, what direction it's going, how long it will do this and what kind it is. You can add all kinds of extra sauce questions then, like "Would you like that particle with gravity effects?" Or "Rotation is very popular this time of year, would you like a little of that as well?" The thing that makes them distinct from normal crap like bullets and enemies is that they, by design, have a little random thrown in. This random behaviour, along with the explicit rules that are set up for different kind of particles will produce wildly different effects.
For example, I created flames, which happen pretty frequently, don't last all to long and aren't affected by the power of G. Debris (like from an explosion) last much longer, have rotation and are affected by Newton's favorite force. Same system, totally dissimilar particles that I've created.
The thing that I'm struggling with now though, is the random part. Like I was talking about here, "random" numbers really aren't. In single cases, they will work just fine. However when you get a bunch of things all working with the same "random" numbers it starts to look stupid and quite altogether rehearsed. Right now, when something is smoking it smokes in time with everything else that smokes, and goes the exact same direction because they all share the same variant direction. Considering the whole point of Particle Systems in the first place (to try to emulate a natural chaotic occurrence) it all falls apart when they all mirror each other.
Otherwise, those, and the wrecks are all finished. The only things that I have left to code are background elements, which work like the ground for the most part. So yeah. Next up on the list is a figuring out the level loading logic so I can play several levels in succession. Then add the part where it loads differently based on how well the player's did. Oddly fun.
Saturday, May 14, 2011
A Particular Kind of Fun
Man, it is so bloody late right now. 2:37 (37!) according to the clock in the corner of the screen. But it's been a very productive couple of hours. I'll start with the somewhat boring stuff, and then get to the titles.
As of now, Paper Zeppelin is pretty tight from a memory usage standpoint. I had noticed that after playing for a while, the whole thing began to slow way the heck down. I realized that all of the little things that the game had ever created were still around off screen somewhere living out a meek little existence sucking the memory teat. So I created a little function that goes around and asks them, "Are you on the screen still? What's that? You're not? Hey look, a distraction !" *bang*
Assume that that *bang* is either a Godfather-esque shot to the dome or a giant mousetrap, the analogy holds up either way and the thing runs really much better now. ("really much better now"...so, so tired)
Once I had that in place I created a little variable called escapedEnemies, which starts at zero and goes up every time the Reaper Function has to do some wet work. What that means is that whenever the player misses and enemy of some sort, that number will keep track of it and display a percentage of enemies wasted in the corner. According to the Design Doc, the progression of the player will be altered based on this ongoing percentage. Now I just need to add a quick variable to track bomb dropping and base destruction and we're all set for the triggers of level selection. Joys!
Then, for kicks I made bullets hit the ground. Before they sailed right through, and I have decided that I hate that more than Mondays and Denver the Last Dinosaur (he is so not my friend, nor a whole lot more). This was always the plan, but I never got around to it. Now it doesn't suck!
Finally I made some extra changes to get the resolution that I talked about last time up to date. It seemed that the enemies were all still on the 100 pixel thing, so they didn't ever appear on the screen. So that's better now too. I also made the adjustments to the collision detection, which strangely works so much better now that the tiles are all little.
Okay then, after all of that, the Title! (cue music...kazoo would be appropriate) I installed a kind of Particle System in the Paper Engine. A proper particle engine is something that usually appears in 3D stuff and I'm thinking that my usage of the term may be a little off. Basically, a Particle System is used to simulate certain behaviours which are tricky to model. It's kind of a "good enough" way of doing things. Stuff like Fire for example, is quite hard to render since it has a crazy wild shape. However, I can easily make a fire animation and spawn it up from whatever is "on fire" in the game. It looks not too bad actually.
How it works it I created a new type of Sprite that doesn't ever touch anything. It just does what it does. I set it up with a starting point and tell it what kind of particle I want and how long I would like it and it just goes. It's pretty cool. Right now it makes fire, which floats up and fire tends to do after I shoot enemies and they are heading Earthbound. I was going to add the smoke too, but I have to leave something for tomorrow. With the particle system in place now, I can quickly and easily add new kinds of particles. I can also rip the whole system, make a minor tweak, and make background elements work too. So overall, a good day. Now sleep is calling...so sweetly.
As of now, Paper Zeppelin is pretty tight from a memory usage standpoint. I had noticed that after playing for a while, the whole thing began to slow way the heck down. I realized that all of the little things that the game had ever created were still around off screen somewhere living out a meek little existence sucking the memory teat. So I created a little function that goes around and asks them, "Are you on the screen still? What's that? You're not? Hey look, a distraction !" *bang*
Assume that that *bang* is either a Godfather-esque shot to the dome or a giant mousetrap, the analogy holds up either way and the thing runs really much better now. ("really much better now"...so, so tired)
Once I had that in place I created a little variable called escapedEnemies, which starts at zero and goes up every time the Reaper Function has to do some wet work. What that means is that whenever the player misses and enemy of some sort, that number will keep track of it and display a percentage of enemies wasted in the corner. According to the Design Doc, the progression of the player will be altered based on this ongoing percentage. Now I just need to add a quick variable to track bomb dropping and base destruction and we're all set for the triggers of level selection. Joys!
Then, for kicks I made bullets hit the ground. Before they sailed right through, and I have decided that I hate that more than Mondays and Denver the Last Dinosaur (he is so not my friend, nor a whole lot more). This was always the plan, but I never got around to it. Now it doesn't suck!
Finally I made some extra changes to get the resolution that I talked about last time up to date. It seemed that the enemies were all still on the 100 pixel thing, so they didn't ever appear on the screen. So that's better now too. I also made the adjustments to the collision detection, which strangely works so much better now that the tiles are all little.
Okay then, after all of that, the Title! (cue music...kazoo would be appropriate) I installed a kind of Particle System in the Paper Engine. A proper particle engine is something that usually appears in 3D stuff and I'm thinking that my usage of the term may be a little off. Basically, a Particle System is used to simulate certain behaviours which are tricky to model. It's kind of a "good enough" way of doing things. Stuff like Fire for example, is quite hard to render since it has a crazy wild shape. However, I can easily make a fire animation and spawn it up from whatever is "on fire" in the game. It looks not too bad actually.
How it works it I created a new type of Sprite that doesn't ever touch anything. It just does what it does. I set it up with a starting point and tell it what kind of particle I want and how long I would like it and it just goes. It's pretty cool. Right now it makes fire, which floats up and fire tends to do after I shoot enemies and they are heading Earthbound. I was going to add the smoke too, but I have to leave something for tomorrow. With the particle system in place now, I can quickly and easily add new kinds of particles. I can also rip the whole system, make a minor tweak, and make background elements work too. So overall, a good day. Now sleep is calling...so sweetly.
Tuesday, May 10, 2011
Resolution Resolution
I've been doing a surprising amount of thinking about time and the length of things recently, mostly because when driving for 7+ hours the mind winders a bit. Occasionally it wanders into Mathemagic Land. But since I am building a shooter after all, math and me have become pretty good friends. What I was thinking about was something that it turns out wasn't even on the list - the resolution. Not, mind you, resolution like a kind of decision (that would be the second occurrence of the word in the title), but more the resolution like you would find on a TV screen and how it relates to how long Paper Zeppelin will take to finish.
Originally, since I tend to build tests and then move forward once they work, the game was built in giant chunks of 100 pixels each. It works then and it works now. The thing about 100 x 100 tiles is that they look, well, pretty tile-ish. That's a damn big thing. The trick with that is that in everything in Paper Zeppelin uses the same basic map for loading stuff up. Sharing the ground, and enemies and any background elements on that same map really doesn't work any more. Add to that the fact that it looks like giant pixel ass, and you can begin to understand why that needs to go.
After that I went looking for the standard resolution of the average screen. The Paper Engine has this cute little thing where it checks the edge of the screen to load thing, but has a way of figuring out how big the screen is. Actually, C# and the XBox console do, but they are Paper Engine features so I'm claiming them. Aside from that, the system knows where the edge of the screen is at all times, so it loads things correctly at the edge for my scrolling effect. So the width isn't really too much of an issue.
(as a giant aside, I had thought about this too from a Design Standpoint. If the screen is more narrow, it doesn't change the way that the different objects behave. So hypothetically the altered timing of the spawns and the altered area of the play space could, and probably will, effect how the game plays. After doing some more thinking, I decided that this was acceptable and stopped worrying about it.)
Anyway, the height though can vary quite a bit. The current average for most screens according to the XBLIG website is 1280 x 720. Apparently the system will chop the top and bottom a little for SD Tv's and monitors. Consequently, the old way with the 100 pixel blocks let me have 7-1/5 blocks this way, which kind of sucks. Either way, the 720 did give me a starting point for the size of my loots.
The question then became, do we want 64 or 32 pixel boxes? 64 has its merits (like there may have been a very real possibility that I would have cheekily called it Paper Zeppelin 64) but that's still not a lot of stuff I can do. I think that I could make more interesting, and at least more aesthetically pleasing levels with 32 pixel boxes. After doing some tweaking, that's now what Paper Zeppelin runs.
Again though, back to the concept of length. Basically, the higher the resolution of the game is (from a tile standpoint anyway) the larger everything becomes. For example, with 100 pixel tiles, the columns were only 8 blocks high. Pretty easy to work with. With 64 pixel tiles the columns are 11-1/4 blocks high. and with 32 pixel tiles they are 22-1/5 - which is almost 3 times the total amount of information that I originally needed. Worse, the blocks quickly become 32 pixels wide. Meaning that for the same amount of time to pass, assuming that the levels run at the same speed, the system will eat 3 times the length of the original, and a factor of 9 the total data.
So I was trying to figure out how long the average level would be in Paper Zeppelin. Since I have tight control over this (unlike in The Thief's Tale) I was thinking about 10 minutes per level. Let's do the math for that one, shall we?
Assuming that the tiles move 2 pixels per game cycle, and the game runs at a silky smooth 60 frames per second, that means that each cycle, each tile will move 120 pixels. To travel across the screen that is 1200 pixels wide, we know that will take 10 seconds.
Doing the division, that means that for a tile to travel the distance of a single tile (32 pixels wide) it will take 120ps/32s or 3.75 tiles per second.
Moving from that, the number of tiles it would take for 10 minutes looks like this:
600 * 3.75 = 2250 tiles.
Yeah, that's a crapload of tiles to build, for a single level.
So instead I got to thinking about the average length of a shooter level. Unlike a platforming game, there isn't really too much variance in the things you are doing. It's mostly shoot and dodge with the occasional wrinkle thrown in (that's one of the reasons for the bomb mechanics really). A shooter level though, should be pretty succinct, more in the range of 2-3 minutes, tops. Like a good song, long enough to make an impact, play a couple of choruses and get out before the audience get's bored. Very punk rock really. So we should ideally be looking at something in the 450 - 675, with an average on the lower range. Get in, make with the fun, and get the feck out.
Originally, since I tend to build tests and then move forward once they work, the game was built in giant chunks of 100 pixels each. It works then and it works now. The thing about 100 x 100 tiles is that they look, well, pretty tile-ish. That's a damn big thing. The trick with that is that in everything in Paper Zeppelin uses the same basic map for loading stuff up. Sharing the ground, and enemies and any background elements on that same map really doesn't work any more. Add to that the fact that it looks like giant pixel ass, and you can begin to understand why that needs to go.
After that I went looking for the standard resolution of the average screen. The Paper Engine has this cute little thing where it checks the edge of the screen to load thing, but has a way of figuring out how big the screen is. Actually, C# and the XBox console do, but they are Paper Engine features so I'm claiming them. Aside from that, the system knows where the edge of the screen is at all times, so it loads things correctly at the edge for my scrolling effect. So the width isn't really too much of an issue.
(as a giant aside, I had thought about this too from a Design Standpoint. If the screen is more narrow, it doesn't change the way that the different objects behave. So hypothetically the altered timing of the spawns and the altered area of the play space could, and probably will, effect how the game plays. After doing some more thinking, I decided that this was acceptable and stopped worrying about it.)
Anyway, the height though can vary quite a bit. The current average for most screens according to the XBLIG website is 1280 x 720. Apparently the system will chop the top and bottom a little for SD Tv's and monitors. Consequently, the old way with the 100 pixel blocks let me have 7-1/5 blocks this way, which kind of sucks. Either way, the 720 did give me a starting point for the size of my loots.
The question then became, do we want 64 or 32 pixel boxes? 64 has its merits (like there may have been a very real possibility that I would have cheekily called it Paper Zeppelin 64) but that's still not a lot of stuff I can do. I think that I could make more interesting, and at least more aesthetically pleasing levels with 32 pixel boxes. After doing some tweaking, that's now what Paper Zeppelin runs.
Again though, back to the concept of length. Basically, the higher the resolution of the game is (from a tile standpoint anyway) the larger everything becomes. For example, with 100 pixel tiles, the columns were only 8 blocks high. Pretty easy to work with. With 64 pixel tiles the columns are 11-1/4 blocks high. and with 32 pixel tiles they are 22-1/5 - which is almost 3 times the total amount of information that I originally needed. Worse, the blocks quickly become 32 pixels wide. Meaning that for the same amount of time to pass, assuming that the levels run at the same speed, the system will eat 3 times the length of the original, and a factor of 9 the total data.
So I was trying to figure out how long the average level would be in Paper Zeppelin. Since I have tight control over this (unlike in The Thief's Tale) I was thinking about 10 minutes per level. Let's do the math for that one, shall we?
Assuming that the tiles move 2 pixels per game cycle, and the game runs at a silky smooth 60 frames per second, that means that each cycle, each tile will move 120 pixels. To travel across the screen that is 1200 pixels wide, we know that will take 10 seconds.
Doing the division, that means that for a tile to travel the distance of a single tile (32 pixels wide) it will take 120ps/32s or 3.75 tiles per second.
Moving from that, the number of tiles it would take for 10 minutes looks like this:
600 * 3.75 = 2250 tiles.
Yeah, that's a crapload of tiles to build, for a single level.
So instead I got to thinking about the average length of a shooter level. Unlike a platforming game, there isn't really too much variance in the things you are doing. It's mostly shoot and dodge with the occasional wrinkle thrown in (that's one of the reasons for the bomb mechanics really). A shooter level though, should be pretty succinct, more in the range of 2-3 minutes, tops. Like a good song, long enough to make an impact, play a couple of choruses and get out before the audience get's bored. Very punk rock really. So we should ideally be looking at something in the 450 - 675, with an average on the lower range. Get in, make with the fun, and get the feck out.
Subscribe to:
Posts (Atom)
