Paper Zeppelin continues making progress. I spent some time over the weekend getting the rest of the level loading system to work and learning about how to both look and and update table information in C#. It’s an interesting thing really. The idea is to have each “row” in the table represent a “row” of objects in the level. That way I’ll be able to calculate out starting positions based on what row in the table the information is in. So, say there is a plane icon on the first row of the table. When the system gets to reading it, it’ll see that there’s a plane on the first row, so it’ll spawn the little beastie right at the top of the screen. I think it’s adorable, and will allow me to make very fast level changes when I need them.
I’ll keep at it, since the next step after this is gameplay testing. Then I’ll be able to see if my carefully crafted design holds up, or folds like an origami crane. Excitement abounds.
– In other random crap, I’ve figured out a solution to the problem from the last post. The issue was, given that both the levels will modify themselves on the fly (given clever use of the characters) based on the number of players and I want to branch levels based on performance, how do I allow drop in and out gameplay without somehow screwing the progress that the players had made? I mean, if 1 player played a level and did well and another player jumped in at the end, the 2 players would have success equal to 1 player’s worth of skill – which would be a failure.
The solution, has to do with the total number of spawned versus destroyed enemies. So when an enemy is spawned the game will add up a counter for the Total Number enemies. When an enemy leaves the screen the system will euthanise it (so it doesn’t take up memory while being lost in space). When it gives the off screen enemy the final mercy, it’ll add to a different counter for Escaped enemies. At the end of the level it will calculate the ratio of spawned enemies to escaped enemies, which will indirectly tell me how many enemies were destroyed by the player/s. I could even stick this ratio in the corner to let players know in real time that they’re doing well.
The clever bit (I think) is that if players join the game, the level will dynamically update the number of enemies spawned. If they leave, it’ll also dynamically adjust. Further, if 1 player is to the end of the level and another player joins, it has zero affect on the progress made. So the players would then be able to continue to the more difficult branch of levels.
– Speaking of dynamic levels, the design document mentions it, but doesn’t go into how it works. I’ll fix that for those of you at home. Basically, different characters in my level data will load the same enemies. Take this example:
The periods are there to represent empty air. I could use spaces, but that’s a lot harder to read and line up than you would think. In any event, if only 1 player is active, the game will only spawn the enemies for the 1 characters. If there are 2 players, then the 2’s will activate too. So if 4 players are playing, then it’ll activate all of them. The enemies that come up will all be the same, but I’ll have fine control over them. The best thing I like about it is that it allows me to do stuff with the single player. So in the doc it says that having the Bomb affects your shooting and speed. So if I have fast dive bombers come in, that’s kind of cheap. So I can set the single player to not have those right after the bomb is picked up.
In multiplayer, I very likely would want those enemies to require the players to work together to protect the bomb carrier.
In either case, I could probably use the same thing to create difficulty settings, but I think that’s missing the point. I plan the use the extra settings not to make the game harder, but to make it different on a fundamental level.