Let's start this off properly, although "properly" precludes any kind of irony laced drama regarding the last post. I won. It doesn't surprise me given the record of my brain versus, well, most things, but I feel good about it anyway. Yes yes, I am fully aware that talking about the intellectual machismo that my gray matter has in spades borders on the wanky, and is well into the zone of self congratulatory, but I'm going to go ahead and give this one to myself. So here goes:
The issue, like I said previously, was that once anything touched the player they would quickly die thereafter, kind of like they'd seen that video with the creepy well girl in it. For almost 3 days I fought with this, and was firmly convinced that it was a systemic error.
Now, the thing with systemic errors is that they are an issue with the core logic of the system. Somewhere in the code something isn't going in the correct order. I hate these so hard it hurts sometimes, but thankfully they are rare...like unicorns...with syphilis.
So, in an effort to make the program a little easier to navigate (and find the bug) I got to moving pieces of the code into its own functions. I call this type of coding "Modular" although I'm sure that real programmers would call it something different (possibly just "Correct"). What that means is, instead of having long sequences of code, everything is built into discrete functions that handle very specific things. So, if something is wrong it becomes very easy to narrow down the source of the issue. At the same time, adding functions becomes are easy as adding Functions (see what I did there? I used "function" as a synonym for "ability" and Function like a computer code chunk {damn this post is getting wanky}). It's probably best code practice for either reason, but it does take a little extra effort when you're just trying to make something work.
So I did that for all of the player interactions. So now there is a function that accepts a player and checks to see if that player is touching anything. Instead, it was still broken. Also, the smoke and fire for the player still didn't work.
For shits, and the possibility of a giggle, I did the same thing for enemies. But they still worked just like they had before.
The thing is, the new player function that I had built didn't give a damn about where in the program it was. It was perfectly content to accept player variables and do its thing wherever I felt like putting it. If my bug was indeed a systemic error, then the function should work if I put it someplace else. Remember that a systemic error (fuggin' things) are issues with the logic and the order of things. So if that is the problem, the non-working bit of code should work correctly provided it is in a different place.
But it didn't. I would still get hit by a bullet that seemed to poison me, and cause a lingering death. Yet, I realized that the problem wasn't systemic then, it was just a regular bug that I couldn't figure out. On the one hand, those should be easy to find. On the other, I had missed this one. So I started comparing the enemy and player collision functions, since they are on a basic level, almost identical. The "almost" bit will be important in a minute.
What I had continued to miss though, is that somehow the addition of bullet collision for players had also broken the smoke and the fire that the player sprite summons up when they are damaged. For some reason, it would play for a frame, and then blink out. Play, and then blink out and kill me in the process.
The player collision function though, it was checking for things from something called the spriteList(). It holds sprites, easily enough. Sprites are everything except for players, ground and enemies. Then it hit me - the sprites were damaging me. I didn't specify that I didn't want everything on the damn list to hurt, just a very specific subset of things that might be on that list. Instead, the smoke and fire that was being created by the player sprite were dealing additional damage to the player, causing a quick death.
So I tweaked it...and it worked...then I swore in some kind of furious joy. It was the same kind of outpouring of emotion (positive and chest thumping) that I throw out after beating a tough Ninja Gaiden II boss. So that works now. The current score is 0 to 100,000,001 and counting. I need to learn me some Calculus so I can get a proper workout.
=D
- Speaking of Paper Zeppelin, now that everything that can kill the player, will kill the player, I'm finding that the game is kind of tough. Player HP doesn't regenerate, and things shoot the crap out of you for lots of different angles. I was thinking that I should fix that, but then realized that Paper Zeppelin isn't too terribly long in the first place. If being short are hard worked for Nintendo games back in the day, it'll work just fine here. Getting to the final stage on the Hard Path should be borderline impossible for a first time player. I'm good with that. Now back to building.
Tuesday, June 14, 2011
Thursday, June 9, 2011
Double Tap
Again, so much time and so little things to do. Ah, wait, I got that wrong...and not on purpose. Cripes I'm tired. Reverse that, switching the "time" and "things" parts of the first sentence and...it still doesn't make sense. Let's assume that you know what I'm talking about and move forward from there.
Right then, been spending a lot of time recently considering moving. No, the internet is not a local thing that I can only get to from here, so I can keep right on writing these things. I've just come to the conclusion that, since I get the occasional callbacks regarding things I apply for (that could almost be graphed since my experience increases every day, hence the odds of calls and interviews begins to rapidly approach a highish percentage) I can increase the chances for my present by increasing the number of places I apply to. Hence, widening my search. Having said that I've begun to really look at social and mobile games. Don't get me wrong, given an option, yes I would like a cool million worth of budget to make something awesome. But so many of the things that I really love about all of this is condensed into mobile and social games. I get to build things quick so I'm working on lots of projects, and I'm done before I get bored. Always thinking about the next thing and aiming the full intellectual and creative fury of my gray matter at the game at hand...pretty much like I do now at Star Frog.
So I'll keep on looking, and applying, and discovering that the world of game development is weirder and much more interesting than I had ever thought.
- In regards to Paper Zeppelin (if I keep typing out Paper Zeppelin Google will finally put me at the top instead of the item from WoW.) I've gotten the first level hacked out for single player. It works and is fun to play. The mechanics work, and I was able to have some playtesting done to ensure that the mechanics hold up in the code. Thankfully they seem to, although I did have to change the player bullets to only fire about 60% of the way across the screen for balance reasons. One of these days I'm going to have to write about balance, and what it actually means in regards to fun. Maybe next time (so tune in! {...like anybody reads this}). I find that while making levels, especially the early ones, I have to strike just the right balance between having things to shoot at, and not overwhelming the player. Too much and then the player just gets frustrated and quits - possibly before purchasing the full version for 160 Bill Bucks or whatever they're called. Too little though, and the player just watches the scenery float by. I mean, the scrolling does look really nice, but it's not what I paid my $2.00 for. I paid to shoot at construction paper stuff with my friends. It's an interesting challenge, and I'm finding that I enjoy doing it more than should be legal.
- Alright then, the titles. For playtesting purposes (and general "make the gods damned game work correctly" purposes) I went in and made all the stuff lethal. To that end (trying to start fewer sentences with "So") I turned the damage and collision for bullets on. Fired up the game, took a bullet and promptly died. Now the game is supposed to remove a single HP when a bullet hits a target. It already works for all of the enemies for shit's sake. But for some reason, the player sprite would smoke and go right out. It's the kind of thing that Elton John would write a song about if it wasn't so stupid.
Turns out, after doing some screwing around with it, that the bullets were somehow hitting the player multiple times, in spite of the fact that the bullet no longer existed for all intents and occasional purposes.
After playing with the timing, all I've managed to do thus far is make it worse. Now, for some reason, enemies do the same thing when they worked just fine before. Also, when a player is damaged they no longer show the proper symptoms for being on fire (mostly the smoke and flames).
What I have here I believe, is a Systemic Bug. Gods I fucking hate these. It's not a misplaced line of code, it's not the wrong variable getting passed or anything so dumb. No, instead it's a breakdown of the logic of the system. Somewhere in the structure of the bloody thing, it's doing something, some process, in the wrong order. The fact that it had previously worked was some kind of fluke.
So to fix this, I'm going to gave to fix big chunks of code. I probably should have done this before, but I'm going to break out each of the Lists (Sprite, Enemy, Ground and Player) into their own function that will then check each of the other lists for collision purposes. Right now, I run the lists and then check things when they are convenient. So when I check bullets for example, I first check all the enemies, and since I have the bullets open, I have it check the players too, saves some processor time. But I get the impression it's all those nested loops that are causing the stupidity. I'll smash the thing with my brain until one of them admits defeat, and my money's not on The Problem, which has a record of 0 - 100,000,000.
Right then, been spending a lot of time recently considering moving. No, the internet is not a local thing that I can only get to from here, so I can keep right on writing these things. I've just come to the conclusion that, since I get the occasional callbacks regarding things I apply for (that could almost be graphed since my experience increases every day, hence the odds of calls and interviews begins to rapidly approach a highish percentage) I can increase the chances for my present by increasing the number of places I apply to. Hence, widening my search. Having said that I've begun to really look at social and mobile games. Don't get me wrong, given an option, yes I would like a cool million worth of budget to make something awesome. But so many of the things that I really love about all of this is condensed into mobile and social games. I get to build things quick so I'm working on lots of projects, and I'm done before I get bored. Always thinking about the next thing and aiming the full intellectual and creative fury of my gray matter at the game at hand...pretty much like I do now at Star Frog.
So I'll keep on looking, and applying, and discovering that the world of game development is weirder and much more interesting than I had ever thought.
- In regards to Paper Zeppelin (if I keep typing out Paper Zeppelin Google will finally put me at the top instead of the item from WoW.) I've gotten the first level hacked out for single player. It works and is fun to play. The mechanics work, and I was able to have some playtesting done to ensure that the mechanics hold up in the code. Thankfully they seem to, although I did have to change the player bullets to only fire about 60% of the way across the screen for balance reasons. One of these days I'm going to have to write about balance, and what it actually means in regards to fun. Maybe next time (so tune in! {...like anybody reads this}). I find that while making levels, especially the early ones, I have to strike just the right balance between having things to shoot at, and not overwhelming the player. Too much and then the player just gets frustrated and quits - possibly before purchasing the full version for 160 Bill Bucks or whatever they're called. Too little though, and the player just watches the scenery float by. I mean, the scrolling does look really nice, but it's not what I paid my $2.00 for. I paid to shoot at construction paper stuff with my friends. It's an interesting challenge, and I'm finding that I enjoy doing it more than should be legal.
- Alright then, the titles. For playtesting purposes (and general "make the gods damned game work correctly" purposes) I went in and made all the stuff lethal. To that end (trying to start fewer sentences with "So") I turned the damage and collision for bullets on. Fired up the game, took a bullet and promptly died. Now the game is supposed to remove a single HP when a bullet hits a target. It already works for all of the enemies for shit's sake. But for some reason, the player sprite would smoke and go right out. It's the kind of thing that Elton John would write a song about if it wasn't so stupid.
Turns out, after doing some screwing around with it, that the bullets were somehow hitting the player multiple times, in spite of the fact that the bullet no longer existed for all intents and occasional purposes.
After playing with the timing, all I've managed to do thus far is make it worse. Now, for some reason, enemies do the same thing when they worked just fine before. Also, when a player is damaged they no longer show the proper symptoms for being on fire (mostly the smoke and flames).
What I have here I believe, is a Systemic Bug. Gods I fucking hate these. It's not a misplaced line of code, it's not the wrong variable getting passed or anything so dumb. No, instead it's a breakdown of the logic of the system. Somewhere in the structure of the bloody thing, it's doing something, some process, in the wrong order. The fact that it had previously worked was some kind of fluke.
So to fix this, I'm going to gave to fix big chunks of code. I probably should have done this before, but I'm going to break out each of the Lists (Sprite, Enemy, Ground and Player) into their own function that will then check each of the other lists for collision purposes. Right now, I run the lists and then check things when they are convenient. So when I check bullets for example, I first check all the enemies, and since I have the bullets open, I have it check the players too, saves some processor time. But I get the impression it's all those nested loops that are causing the stupidity. I'll smash the thing with my brain until one of them admits defeat, and my money's not on The Problem, which has a record of 0 - 100,000,000.
Thursday, June 2, 2011
Shiny Little Pieces
Lots of stuff done recently, but no time to write about it. Let's start with the easy stuff. Wrecks work now. So when things crash they explode and create fire and debris particles (from the particle generator!) then create a smoking hulk of a thing that continues to smoke and burn like so many doomed moths. It's actually pretty cool, and creates the chaos and general destruction that I wanted for Paper Zeppelin.
With that out of the way, I went ahead and created a level using Excel (I need to think of something else to call the editor, but really, it's a re-purposed tool. So I'm at a loss really). Discovered a couple of things. 1), the level at 500 tiles wide takes a good amount of time to finish off, but is still short enough to stay interesting. 2) It's easy to make stuff too easy and way too hard. Right now, the first level is too easy and needs additional tweaking and tester, um, testing. 3) The system didn't like loading a level that was shorter than the one before it.
So regarding that last thing, I hated it. No matter what I tried, the issue was that the system would load up the next stage, but simply ignore the bit where I told it to reset the place in the level. Consequently, when I tell a computer to look for something that isn't there (like the 57th letter in the alphabet) it tells me to "Please Reinstall Universe and Re-Start" also, to go straight to hell. So I beat on that until I got it functioning. In the end I told it to skip a cycle. Since each cycle is a 60th of a second, I can get away with it without creating any gaps in the level. So on a step where computer wants a number beyond the scope of the stage, I tell it to reset to 0. Then, if and only fuggin if, the number is currently a gods damned zero, load the new level. So that's good now.
That's it for now I guess. I'm tired and ready for sleeps.
With that out of the way, I went ahead and created a level using Excel (I need to think of something else to call the editor, but really, it's a re-purposed tool. So I'm at a loss really). Discovered a couple of things. 1), the level at 500 tiles wide takes a good amount of time to finish off, but is still short enough to stay interesting. 2) It's easy to make stuff too easy and way too hard. Right now, the first level is too easy and needs additional tweaking and tester, um, testing. 3) The system didn't like loading a level that was shorter than the one before it.
So regarding that last thing, I hated it. No matter what I tried, the issue was that the system would load up the next stage, but simply ignore the bit where I told it to reset the place in the level. Consequently, when I tell a computer to look for something that isn't there (like the 57th letter in the alphabet) it tells me to "Please Reinstall Universe and Re-Start" also, to go straight to hell. So I beat on that until I got it functioning. In the end I told it to skip a cycle. Since each cycle is a 60th of a second, I can get away with it without creating any gaps in the level. So on a step where computer wants a number beyond the scope of the stage, I tell it to reset to 0. Then, if and only fuggin if, the number is currently a gods damned zero, load the new level. So that's good now.
That's it for now I guess. I'm tired and ready for sleeps.
Tuesday, May 24, 2011
Level Up
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.
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.
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)
