I get the impression as I sit down to write this that I'm probably not finishing this the same day I started. I mean, I already wrote a bunch of stuff this morning, and otherwise had a good day developing levels. I got to thinking about an age old game design fact - when developing the game is too damn hard. That's what it is. I find Paper Zeppelin challenging, but I designed the game and have a very thorough understanding of every little bit of it. Frankly though, I'm going to need to figure out how to correctly balance this thing, and hopefully quickly.
First though, although I've mentioned it before, I need to go into what exactly I mean when I say "Balance" in terms of a game mechanic.
First, let's get something out of the way. Balance is not making a game fair. Fundamentally, almost every single player game is built to be unfair. By default, you're almost always against impossible odds. Taken together, you shouldn't be able to win. Think about it for a second. In Super Mario a fat plumber is put up against the legions of Koopa Troopas and must single-handedly liberate the entirety of the Mushroom Kingdom. Master Chief of Halo fame is pitted against the galactic empire that is the Covenant. None of these things are fundamentally fair if you compare them to something like Chess.
On the other hand, as a player you are always a stupendous bad ass. So much so that your bad assery is almost never in doubt. I mean, in Call of Duty Modern Warfare, I'm pretty sure that you are the only regenerating soldier in the world. You know who else has regenerative powers like that? This guy. So in those kinds of situations, a player can usually win by attrition.
So, fairness and balance are not the same thing in a single player game. Note that I keep referring to Single player games. Player vs. Player games derive their fun from their inherit fairness. No, instead when I say "balance" I mean, "balance of meaningful choices." In a game, it is the goal of the designer to offer a player a set of meaningful choices. Using Final Fantasy as an example, there are 6 classes, each of which is good at specific kinds of things. However, none of those choices is wrong, and none of the combinations of specific choices is incorrect either. You can beat the entire thing with 4 White Mages if you feel so inclined. Further, your choice leads to explicit and unique outcomes. Playing without a healer in the party is far different than having one. That is an example of offering meaningful choices.
However, the other kind of choice is worthless choices. These are choices that are offered to the player where the outcome is a forgone conclusion or irrelevant. Again, with Final Fantasy the ability to Defend while in battle (later ones anyway). You're getting hit anyway, only for slightly less damage, but by doing so you've added to the length of a combat situation. That "option" doesn't really offer a meaningful choice to the player.
So the "balance" that game designers toss around in conversation refers to, for the most part, the balance between the different kinds of choices, and whether each option is meaninful, and if any of them is consistently the "best."
The ability to hand out choices goes one step further. You see, when a player has too many choices, they begin to freeze up and wonder if they made the correct choice in a specific circumstance. Then they begin to overthink it. What a designer needs to do is limit the amount of choices that a player has by making them as distinct as possible. Halo did a good job with this by limiting the number of weapons a player has available at any given moment. The core of the Halo gameplay revolves around the triangle of choices that are guns, grenades and melee attacks. If a player could carry more weaponry, then that would add additional weight to the guns part of the triangle, giving implicit encouragement to always go with the guns option. Limiting the redundant choices expanded the player's access to more meaningful options.
The other thing to worry about is the idea of the Optimal Choice. Players, like people, are kind of lazy. Once they have discovered a way to maximize their reward for playing, they will continue to follow those exact same steps every time. Because there is a choice that is better than every other choice most of the time, it renders all of the other choices irrelevant. This, is a terrible breakdown in every sense of the word. Last time, I had brought up a specific game flaw in Paper Zeppelin. Basically, if you were above the enemies at all times, you were reasonably safe. A player could hug the top of the screen and avoid anything that didn't actively shoot at them. This was bad. The reason that is a breakdown in the fabric of a game, is that it makes the game no damn fun. Once a player has defined the Optimal Choice, finishing a game is just a matter of doing that exact same thing for as long as it takes the game to give up the goods. There's another word for that though - work. Work, almost by design, isn't any damn fun. Doing the same thing over and over again as a way of receiving some kind of reward is exactly that.
So, we have defined "Balance" as a way of offering a player a variety of pre-selected choices that are all equally valid. Well, that's almost right again. At one point I said that games, are not Art. I stand by that. However, there is an aspect of Game Development that I consider to be its uniquely artistic endeavor - Level Design. It's not the architecture, or the textures or anything so blase. No, the Art of Level Design is that it is creating play spaces. It is the act of leveraging the mechanics of the game into a usable space and form. I could write and code a dozen games without levels, but all they are until the levels are built are ideas. The Levels are the expression of the idea made into a form that somebody can play with.
So what does that have to do with Balance? In a word - Everything. By design, a level seeks to limit the choices the player has. This forces the player to utilize different bits in the toolbox that the Game Designer has offered them. Stealth levels in otherwise action games are terrible examples of this, but examples nonetheless. However, if the design of a level removes choices that should be valid, then we get into that hard to define area of the world known as "cheap," as in, "that was cheap...and lame." When a player has grown accustomed to certain options that are useful, not having them work in an expected way, especially when they should be available, makes a player unhappy. Again, stealth levels in action games are an example of this. Why, after shooting through hordes of enemies, are you suddenly hiding in the dark from a bare handful? Worse, why do you lose automatically if they see you?
So in a game like Paper Zeppelin, I try not to limit the choices that a player has really at all. Instead I'm trying to design levels that simply encourage certain behavior while not penalizing players for choosing to play a different way. So while I certainly do not encourage player's to fly under enemies, it's their choice. By doing this I am not limiting a player's choices, which is key to making them feel like any mistakes that they made, they did all on their own. They didn't get killed because I limited their options so much are to leave them powerless. Instead the options were their, it was their choice and ability to carry out that choice that led to their downfall. Best part of that though, is that if you die because of that you still want to play.
With all of that out of the way, let's get a little into the idea of a Balanced Mechanic. Like I've said before, a Game is just a series of interacting mechanics. Mechanics are just rules. Complex rules, since they usually are pretty variable based on what is happening within the game at any given moment, but rules just the same. Now, whenever I consider a mechanic to add to a game, I spend quite a bit of time trying to figure out in what ways that new mechanic or modification will affect the other mechanics. Affect how? Well, does it render any of the other choices irrelevant? Say I wanted to add a gun while developing Thief, the ability to shoot would make the whole sword fighting mechanic moot, and most enemies as well. So that get's thrown right out. Consequently, when I think about balance, I always consider "Balance" to be a quality of a mechanic. Does it offer meaningful choices? Does it avoid creating an Optimal Strategy? Along with specific questions like : Does this add to the concept of the game design? Will this fundamentally change the way the game plays?
So that's what I have for today. I'm sure I left a lot out, but this is what I have time for tonight. Now I have to go back and design spaces full of delicious options.
Sunday, June 19, 2011
Falling Up
Did some playtesting recently, or rather, I had some playtesting done and I came to a couple of conclusions. First of all, Paper Zeppelin is kind of difficult. I watched my tester get killed no fewer than 5 times before they got the whole dodging while firing thing down. Second, the Turret Enemies are too small. Their long range shooting crossed with their small size makes them quite difficult to shoot at with anything resembling safety. It get even worse if they happen to get behind the player, or if they are above them.
Thirdly (not sure if that's a word...but Blogger is okay with it) there is a Design Flaw in the game. The thing itself is kind of dumb, but the logic behind how it's a flaw in the game's design takes some doing, besides, I can explain some of the core conceits while I'm at it. Okay then, Paper Zeppelin is a twin stick shooter. That in and of itself narrows down the game's focus. Furthermore, it's a scrolling twin stick shooter (of which there are much fewer). It's designed to support and encourage multiplayer. It's also, and this is the key bit here, focuses on the positioning of game objects.
4 Conceits. Every individual mechanic in the design of Paper Zeppelin can be followed back to supporting one of those conceits. For example, I shortened up the player's firing range because the longer range hampered the fun aspects of conceit #2 - the scrolling bit. Most of the AI is designed to track specific players based on explicit criteria to encourage teamwork. The Bomb mechanic is designed to change the way a player plays in order to alter their positioning to something that is less ideal.
Speaking of the ideal positioning, I had the hypothesis while doing the design that the crashing enemies mechanic would influence players towards the top of the screen. Turns out that is exactly true, and I so love it when I get these things right in advance. However, since turrets usually live outside of the range of the guns, I find that I have to put myself in danger in order to eliminate ground targets, so the game areas become far more open.
Anyway, this doesn't have anything to do with that flaw I was talking about. The thing is, with a couple of exceptions, if you are above an enemy, there isn't too much that most of them can do to you. This came into play when the tester was carrying the bomb, which limited their ability to fire below them. So what they did was simply hug the top of the screen until it was time to drop. The enemies just rolled on by below, harmless and not terribly fun. To remedy this, I'm going to go ahead an modify the Dive Bomber enemies to that they can also dive up. I know, I know, diving up doesn't make sense. But since their whole point is to give you a great big hug anyway, up works. It also makes them more dangerous while you're trying to do anything.
Right then, titles! The next big part of the development of Paper Zeppelin is to go ahead and lovingly craft all the levels. So I went ahead and figured out different "types" of levels that I could have in the game with the minimum amount of effort required for each. Basically, like I learned in the development of The Thief's Tale, the specifics of each level don't really need to jive with the specifics of the mechanics of that level per se. So for example, in PZ there are rolling grass levels (the first level is one of these types) and Deserts. Topographically, they both have long sloping hills in them. However, the Desert level will instead have almost no ground enemies (since it's sand) and the tiles and backgrounds that are spawned up will be different. That's it. No other differences. I could swap the art and they would still work.
Instead, the different kind of levels will force the player to reconsider their positioning again. Island levels are almost completely open, with the "water" being implied off screen. So the majority of the level is all about lots of flying enemies and open movement. Same idea with the Mountain levels; which are more open, but instead of the sloping islands have sharp peaks covered with ground enemies, forcing the player to radically alter their playing on the fly.
In any case, unlike in Thief I'm going to try something a little different for the levels in Paper Zeppelin. I'm going to go through and block the levels out first. All of them. Not build one and keep playing it until it's perfect and works great. Instead I'm going to have all of them working and able to fly through, and then tweak them as I need to. What this will do is A) allow me to understand how the game is working by being able to play all the way through and B) allow me to develop a difficulty curve. If I just go in all willy with the possibility of nilly and build the levels one at a time, there is a very real possibility that the curve will suck. Balance requires that the difficulty curve definitely not suck, it cannot be too steep, and it certainly cannot be flat. Having all the levels available to play with at once will let me adjust the difficulty along the entire game.
To do that though, I need to know the order that the levels will exist in. There are 7 types of levels in Paper Zeppelin, and they look like this:
Rolling Hills
Steep Hills
Desert
Islands
Mountaintops
Caverns
Floating Islands
Each of these, as far as I can tell, will play differently. For kicks, let's see how. Rolling Hills, Steep Hills and Desert are all very similar one could argue. Let's start with the different kinds of hills. They are different in the kind of play spaces that they allow for. Rolling Hills have hills that a long and low. Most of the screen is available for movement at any given moment. Steep Hills by contrast, are steeper and taller. The ability to move around within the screen will vary wildly based on the player's progress within the level. Dealing with turrets that are much closer and having less space to with which to deal with enemies should provide a different experience that the Rolling Hills levels would. Deserts, like I said before will instead provide an abundance of a different enemy types, also providing contrast.
At least, that's the theory. Once I get the levels blocked out I'll know for sure.
Thirdly (not sure if that's a word...but Blogger is okay with it) there is a Design Flaw in the game. The thing itself is kind of dumb, but the logic behind how it's a flaw in the game's design takes some doing, besides, I can explain some of the core conceits while I'm at it. Okay then, Paper Zeppelin is a twin stick shooter. That in and of itself narrows down the game's focus. Furthermore, it's a scrolling twin stick shooter (of which there are much fewer). It's designed to support and encourage multiplayer. It's also, and this is the key bit here, focuses on the positioning of game objects.
4 Conceits. Every individual mechanic in the design of Paper Zeppelin can be followed back to supporting one of those conceits. For example, I shortened up the player's firing range because the longer range hampered the fun aspects of conceit #2 - the scrolling bit. Most of the AI is designed to track specific players based on explicit criteria to encourage teamwork. The Bomb mechanic is designed to change the way a player plays in order to alter their positioning to something that is less ideal.
Speaking of the ideal positioning, I had the hypothesis while doing the design that the crashing enemies mechanic would influence players towards the top of the screen. Turns out that is exactly true, and I so love it when I get these things right in advance. However, since turrets usually live outside of the range of the guns, I find that I have to put myself in danger in order to eliminate ground targets, so the game areas become far more open.
Anyway, this doesn't have anything to do with that flaw I was talking about. The thing is, with a couple of exceptions, if you are above an enemy, there isn't too much that most of them can do to you. This came into play when the tester was carrying the bomb, which limited their ability to fire below them. So what they did was simply hug the top of the screen until it was time to drop. The enemies just rolled on by below, harmless and not terribly fun. To remedy this, I'm going to go ahead an modify the Dive Bomber enemies to that they can also dive up. I know, I know, diving up doesn't make sense. But since their whole point is to give you a great big hug anyway, up works. It also makes them more dangerous while you're trying to do anything.
Right then, titles! The next big part of the development of Paper Zeppelin is to go ahead and lovingly craft all the levels. So I went ahead and figured out different "types" of levels that I could have in the game with the minimum amount of effort required for each. Basically, like I learned in the development of The Thief's Tale, the specifics of each level don't really need to jive with the specifics of the mechanics of that level per se. So for example, in PZ there are rolling grass levels (the first level is one of these types) and Deserts. Topographically, they both have long sloping hills in them. However, the Desert level will instead have almost no ground enemies (since it's sand) and the tiles and backgrounds that are spawned up will be different. That's it. No other differences. I could swap the art and they would still work.
Instead, the different kind of levels will force the player to reconsider their positioning again. Island levels are almost completely open, with the "water" being implied off screen. So the majority of the level is all about lots of flying enemies and open movement. Same idea with the Mountain levels; which are more open, but instead of the sloping islands have sharp peaks covered with ground enemies, forcing the player to radically alter their playing on the fly.
In any case, unlike in Thief I'm going to try something a little different for the levels in Paper Zeppelin. I'm going to go through and block the levels out first. All of them. Not build one and keep playing it until it's perfect and works great. Instead I'm going to have all of them working and able to fly through, and then tweak them as I need to. What this will do is A) allow me to understand how the game is working by being able to play all the way through and B) allow me to develop a difficulty curve. If I just go in all willy with the possibility of nilly and build the levels one at a time, there is a very real possibility that the curve will suck. Balance requires that the difficulty curve definitely not suck, it cannot be too steep, and it certainly cannot be flat. Having all the levels available to play with at once will let me adjust the difficulty along the entire game.
To do that though, I need to know the order that the levels will exist in. There are 7 types of levels in Paper Zeppelin, and they look like this:
Rolling Hills
Steep Hills
Desert
Islands
Mountaintops
Caverns
Floating Islands
Each of these, as far as I can tell, will play differently. For kicks, let's see how. Rolling Hills, Steep Hills and Desert are all very similar one could argue. Let's start with the different kinds of hills. They are different in the kind of play spaces that they allow for. Rolling Hills have hills that a long and low. Most of the screen is available for movement at any given moment. Steep Hills by contrast, are steeper and taller. The ability to move around within the screen will vary wildly based on the player's progress within the level. Dealing with turrets that are much closer and having less space to with which to deal with enemies should provide a different experience that the Rolling Hills levels would. Deserts, like I said before will instead provide an abundance of a different enemy types, also providing contrast.
At least, that's the theory. Once I get the levels blocked out I'll know for sure.
Tuesday, June 14, 2011
Smoke and Mirrors
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.
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.
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.
Subscribe to:
Posts (Atom)
