Skip to content

The Final Crawl

July 3, 2010

So, my game Starlight is pretty close to being done. Here’s what I have left to do:

  1. Lower the file size
  2. Fix the game-breaking saving glitch
  3. 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.

Introduction to Starlight

There are 88 more just like this one

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!

Weekend Update: T-Minus 4 Weeks

April 25, 2010

This is a quick weekend update following the progress of my upcoming XBox Indie game, Starlight.


Well, the largest amount of development time this past week has been dedicated to the menu system. Building it wasn’t the easiest task, but this far into the project I’m not as worried about efficiency. Ideally, I would have created a better system for creating the menus early on, but I’ll just have to save that for next time. I still need to create the content for the menus, but the shell is completed.

XBox 360

One pretty significant step I made this week was porting the game from my PC to the XBox. Before now, it’s been a PC game using an XBox controller, but because it’s a release for the Indie game service, I had to bring it over. Here’s how it looks so far:



Only the very basics are done, and there are still a lot of display issues to solve. The menus, for instance, take a pretty big hit:



As you can see, the entire bottom is cut off. I’ll need to take a pretty in-depth look at how the sizes and proportions are initialized to fix this issue. Once that’s done, I can start thinking about working on other XBox specific functions, such as memory unit/hard drive access and saving.

Weekend Update: T-Minus 5 Weeks

April 17, 2010

So, I thought I would keep everybody up to speed on exactly what it is I’ve been, and will be, doing up until the release of the game. I’ll go ahead and sum everything up at the end of the week. So, here’s the first update.

Ditched Some Stuff

I got rid of fans and one of the levels. I elaborate quite a bit here.

Walls, Walls and more Walls

All of the walls in the game were causing some pretty annoying glitches regarding the enemies. These glitches caused the enemies to walk straight through locked doors, and walk through brick walls if they were stacked on top of each other. My locked door collision code was just pretty shoddy, so I tightened it up enormously. The other glitch was also caused by my collision code, but in a less obvious method; the way I programmed the collisions, I made sure that if the enemy was walking on the top of a wall, it was impossible for him to be stopped by the right or left side of the wall. As it turns out, this was a pretty stupid thing to do. I programmed it in because I knew that as long as the enemy was on top of the wall, they couldn’t possibly walk into the base of it. Well, when I stacked walls on top of each other, the engine was letting enemies walk on top of one wall, while passing directly through another wall stacked on top. I simply deleted this code, as it was completely and utterly unnecessary in the first place. Lesson learned.

No Turning Back Now

This problem related more to the design than the programming. My problem was that while designing the levels, I never really considered the fact that players might want to turn around and backtrack. So, in my designs, it was impossible in some places for the player to go too far backwards, usually because of a wall that was too high to pass. I thought about deleting obstacles as you tread far enough away from them, but ruled out that plan for two reasons:

  1. If the player wanted to go backwards immediately after passing a high wall, they would first have to walk forwards a bit to erase the obstacle. This is blatantly terrible design.
  2. It would seem off to the player if, all of the sudden, solid objects just started vanishing off-screen. It would create an environment of uncertainty that I wanted to steer far away from.

So, my next thought was to put a warp at the end of the level, so you could continue from the start if you missed anything. The problem with this was obvious: If the player only wanted to backtrack behind an impassible obstacle that was close by, they would have to continue all the way to the end of the level just to move back a few yards. Yuck. My answer was more of a brute-force solution. I simply went back into the designs, and added platforms and springs to help go past the high walls. What can I say, it worked out alright.

Spawn Timer

The next thing I wanted to do wasn’t necessarily solving a huge issue, but adding a small element to the enemy’s spawn points. The spawn points of the enemies are these small teleporters placed around the levels. The warped in enemies after a short time, and only if the player wasn’t standing on it (because nobody wants an enemy spawned directly into their face). My only concern was that players would be standing close to spawn points, but not on them, so that when enemies warped in, it would catch the player by surprise and kill them.

So, what I did was add a small red rectangle to the base of all the teleporters. The rectangle started out invisible, but heated up red as the enemy was about to appear. It wasn’t something stupidly obvious, like a number timer, but got the point across. No red bar = safety. Glowing red bar = MOVE IT!

Background and Floor Editing

I made some adjustments to the floors in the game, which took a lot longer than it probably should have. My first problem is that the floors didn’t scroll across the screen, so I had to go in and completely gut-out the old floor code and redo it, which was a pain. After that was finished, I changed the texture for the second and third worlds to be more fitting (sidewalks for the city, etc). I also enlarged some of the backdrops so that they would cover the entire level.

Starting to Flesh-Out the Menu

This is most likely my biggest obstacle ahead of me, but I’m beginning to chip away at it. Essentially, I have three main menu options: Story, Extras, and Options. This week, I finished the menu for “Story”. There isn’t a ton to say about it, but it was certainly my biggest task. In place of some explanatory text, I offer a screenshot.

menu screen shot


Alright, that’s about all of the major changes for this past week. I may have done some other changes, but I think this covers the basic features of the new build. Thanks for keeping up, and stay in touch for next week’s edits.

Learning Curve

April 16, 2010

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.

QuickgraphSo, 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:

SlowprogressionAlright, 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.

balancedprogressionOkay, 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.

Video: Starlight Preview

April 15, 2010

Here’s a quick look at my XBOX Indie game, Starlight.

GUI Thoughts

April 13, 2010

I’ve been thinking a lot about the GUI (Graphical User Interface) lately, which is a lot less complicated than it sounds. It basically means the menu. Most people just kind of dismiss this, thinking that the main gameplay design is far more important. Well, it is far more important. That’s as true as it gets. But that doesn’t mean that the GUI should be ignored. Many people who play games (myself included) don’t ever think about the GUI at all, unless it becomes an obstacle between them and the game. Most PSN, Wiiware, or XBOX Arcade games have a very simple menu system, because they usually don’t have as many parts as a retail game (with many exceptions). The menus don’t add much to the game, or take much away. When the GUI is poorly designed, or unintuitive, it makes itself known. Ever had an experience of wrestling with a menu? Perfect Dark Zero comes to mind, but there are many games with bad interfaces. Non-RPG players may have been lost in the Oblivion or Borderlands menus, for example. Maybe not everybody, but the main issue here is when the GUI stops the player from being able to play the game.

Lode Runner main menu

Most XBOX Arcade and PSN games have very simple interfaces. You never really have to think about them.

Braid manages to bypass this problem entirely by starting the player smack dab in the middle of the game. This is a great approach, because again, the menu shouldn’t come between the player and the experience, but it doesn’t work for every game. Halo, for example, has more than one main mode (multiplayer and singleplayer), so this approach would not be ideal. Tons of games fall into that category, and I’m sure you can think of ten right here on the spot. I mean, essentially anything with multiplayer or more than one main mode will require the user to make some kind of choice before they start playing the game. The difference between a good GUI and a poor one is the usability, intuitiveness,  and speed at which the user can access whatever feature they want. If the player needs to press the A button 17 times to get from the boot-up screen to the game, you have an issue. Is it possible to get rid of the GUI all together? Sure. Atari games, for one, but there are many times when it might be appropriate.

fallout menus

Uh.... what?

So, this was only brought to my attention because I’m working on the GUI for my game, Starlight, and I thought I might explore it. It’s difficult to really dive in deep with the topic, considering it really is just a menu. Is there a way to make GUIs more interesting, both visually and design wise? It’s a cool idea to explore. My goals for the Starlight interface is to provide a way for users to get into the game very quickly if they wish, to find any options very easily, to have the menu be visually unique, and to match the style of the game.

So there you have it. Menus. Pretty exciting stuff, right? It’s not very hard to make sure that a menu works well and preserves flow, but because it isn’t as importaint as gameplay or something, it’s easy to brush it off and end up with something that confuses the user terribly. Just like any other aspect of game design, you should probably put some thought into it.

It’s Hard to Say Goodbye

April 12, 2010

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.

Level 103

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.

  1. The way the fan blew you into the air was unpredictable. It often lead to danger because of it’s random nature.
  2. 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.

Fan Sprite-sheet

RIP fans, you wont be missed

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.