So, my game Starlight is pretty close to being done. Here’s what I have left to do:
- Lower the file size
- Fix the game-breaking saving glitch
- That’s it!
Adventures in File Size
So, I’ll be submitting Starlight to the XBox Indie games marketplace. That means a lot of things, but in this context it means that my game can’t be any larger than 150 megabytes. This was an especially harsh realization considering that my game was about 270 megs. Whoops! There were two big areas I could improve on: The intro, and backgrounds. The intro to the game is a 89 frame long animation. The animation is comprised of 1200 X 700 .png images. All together, the images added up to about 62 megs. It looked gorgeous, but was absurdly large. The answer to my woes, I hoped, would be converting my flip-book-style animation into a video. After downloading some freeware that could convert images into a video file, I discovered that an .avi version of the intro was about 300 megabytes. Awesome. I did make an interesting discovery, however. After creating a .wmv (windows movie file), the file was only 2 megabytes. Awesome! Also, .wmvs are the preferred file type for XNA game studio projects, which is what I’m using to create Starlight. XNA 3.1 supports video format, which is surprisingly easy to use. You can load up a video in a very similar way that you would load a texture, and the video player has it’s own set of easy to use methods. In short, it works very well to cut down the file size, and the only downside is the reduced quality.
I’m also going to be lowering the size of many of the background textures and other large images. The smaller quality should be more than enough to get me bellow 150 megs. The estimate so far is about 80 megabytes, but it might end up being slightly larger.
I hope you don’t plan on saving that game
Because you can’t. Currently, there is a glitch in Starlight that erases every game save file as soon as you quit. It’s a problem. Originally, I had an issue with the save files, where the game would crash every time you tried to do a qicksave. After a series of headaches, I was able to figure out that the problem stemmed from trying to serialize booleans, of all things. The problem was resolved when I simply changed all booleans to integers, and read the variables as 0 and 1 instead of true and false. Simple solution. However, after adding some more arrays of integers to the save data structure, the problem reemerged in full force. I have yet to figure out what is causing it this time, but to get around the issue temporarily, I added try & catch blocks, which simply put “catch” the error and erase all the data to prevent a crash. Seeing as how people may want to save their games, I’ll get to work debugging this issue.
There are still a few roadblocks, but the game is very near completion. I’ll keep working on it, and try to release more information about the game (trailers, website, etc.) when I’m able. Thanks!
Okay, so today I thought I might talk a bit about learning curves. First of all, what is a learning curve? Well, essentially, it is a generalization of the skill progression of the player through the game. The quicker the graph rises, the quicker player skill increases. What developers are going for typically, is a perfectly straight, even line. In practice, it doesn’t usually work out like that, but for many games (not all) it is a good baseline. Here is an example of three curves and what they mean.
So, you can see in the graph above how quickly player skill rises. Near the beginning of the game, their skill increases very rapidly, and as they near the peak, learning slows. This kind of curve means that the game is probably very easy, and as a result the player gets very bored. This is because they have stopped learning, and when a player stops learning, they are no longer stimulated. This progression is usually associated with very simple games, or kids games. Also, those numbers aren’t really any kind of unit of measurement. You don’t really measure skill on a 1-100 point scale; the numbers are just figurative. Here’s another graph type:
Alright, so this graph is a counter-point to the first one. It’s a very slow skill progression. Check out how slowly the player gets better at the game. Now, this can be a good thing, sometimes. As long as the player is being challenged (very greatly in this case), they will be interested, right? Well, there is a very nasty side-effect: frustration. This doesn’t mean that hard games are bad; quite the opposite! Hard games are stimulating, but if the challenge is too great, they become frustrating. If a player is frustrated too much by a game, they quit. What it comes down to is this: Is the gain from progressing worth the effort the player is exerting. If the answer is yes, they keep playing and slowly get better. If the answer is no, they throw the controller at the TV and stop forever, IE: Me playing most FPSs. This is why most non-gamers (and unskilled-me) can’t play many modern multiplayer shooters. The other players can be far better, making the skill curve look like the one above, and causing frustration. And if the player feels like it isn’t worth the trouble of getting better, I quit. Err, I mean, they quit. I’m not a quitter.
Okay, here’s the ideal graph. The player is constantly getting better, but facing a fair challenge as they go along. Games like Portal stick quite closely to the curve, always teaching the player about new game elements (momentum, blocks and buttons, turrets) that will challenge them, but they have the tool set to conquer the game. This is why Portal, and other games that stick around the curve are so great; they have mastered player progression. This might not be ideal for every game (casual games like peggle, or challenge-based games like mega-man), but games that stick to the curve are nearly guaranteed to keep the player interested. So when people (myself included) talk about Portal as being near-perfection, this could very well be why.
So, that’s my schpeel, I hope the graphs didn’t make you fall asleep. Next time you play a game and are getting bored, or frustrated, think about the difficulty progression! It’s interesting to think about the advantages and disadvantages to an easy game, or a hard one. Because while the straight-curve is often the best, different games might use different methods, and there aint’ nothin’ wrong with that.
Here’s a quick look at my XBOX Indie game, Starlight.
Sometimes, you just have to let it go. What am I talking about? Well, I’ve had an interesting experience working with Starlight today, and I thought I’d share. Often in game development, certain features planned in early versions of the game fail to make it into the final version, due sometimes to time constraints, or maybe because the concept just didn’t pan out like the developer had hoped. I was “lucky” enough to experience this with my game, Starlight. Twice, actually.
No, there are not over a hundred levels in Starlight. There’s twelve. But one unfortunate level was cast aside during play testing. Here’s the story: I created three levels during the first stages of the game. Level 1 was based off of the prototype level that proved the concept, level 2 implemented some of the new features I had thought up during programming the engine, and level 3 was impossibly difficult. One of these things does not belong. Most people who played level 3 couldn’t get past the first puzzle, which was a problem considering how early it was in the game. So, not knowing how many levels I would put into the game at that point, I dubbed it “Level 103” and thought about putting it in a later level, where the difficulty would make sense. Well, the way things worked out (mainly the way the gameplay mechanics changed with each passing world), it didn’t make much sense to include the level in the final game. It’s in the programming, sure, but it wont be accessible in the final build. It hurt watching this level fade away; I put hours and hours into it. Pushed my brain to the very limits to conceive those puzzles. I was very fond of it, actually. But there comes a time when you, as the developer, have to take a step back and ask yourself if it really fits in the final product. As it turns out, it didn’t fit. You will be missed, level 103.
Blowin’ in the Wind
Level 103 wasn’t the only thing to be kicked from Starlight. When I was first programming all of the objects into the game (enemies, razors, platforms, springs, etc.) I thought it would be cool to include a “Fan” object, which, when stood over, blew the character high into the air. I thought it was pretty neat. In fact, I was a pretty big fan of it. You could say that this feature blew me away. Alright, I’m done. I promise. So, like I was saying, I thought up some cool puzzles that used the fan, and began implementing it as early as level 2. The problem was… well there were a couple problems.
- The way the fan blew you into the air was unpredictable. It often lead to danger because of it’s random nature.
- I hardly used it. Seriously, I only actually used the thing three times in the whole game.
The Latter reason ended up being the deciding factor in pitching it. It was more trouble than it was worth to try to polish and fine-tune it. Also, I thought that it was pretty useless to teach the player about these new and strange objects, that, after they maybe understood, never had to use again. It was a waste of the players time and effort, and mine as well. Do the spinning blades hurt you? Is there a limit to how hight they blow you? These are questions that would have been a pain to answer through design, so I took out the fans and the game is better for it.
No More Puns. I’m Serious, guys
All in all, it was a very smart decision to cut these elements from the game. A large developments studio might not have any issues with this, considering they are on a tight schedule, and “higher-upps” make most of these choices in the end. However, for the indie developer, it might be hard to understand that something needs to be cut, especially if they’ve spent so much time into creating these elements. Really, all it takes is a step away from the game, to view it in it’s entirety. Does the element fit, and more importantly, what does it add to the experience. If your answer is “nothing”, then that specific section of the game really has no business being there. It’s hard to do, but can drastically improve the quality of the game, as seen with level 103. it’s kind of weird to do an entire post about taking things away from the game, and not adding anything, but cutting bad features can often open up the door for better ones, so come on, developers; make the right choice.