Short Circuit was an XBox 360 puzzle games based on the popular handheld game produced by Tiger Electronics. In Short Circuit, you would be faced with a grid of lights ranging from 3×3 to 10×10. The objective was to turn all the lights off by clicking on a light one at a time. Each time you clicked on a light, it would toggle the lights above, below, left, and right of it. Short Circuit introduced a new type of light called the three-stage light that operated similar to a stop light.
Get Short Circuit on XBox360 here.
Get Short Circuit for Android here.
Short Circuit went through the second round of developer testing and got absolutely no reponses. Operating on the idea that for every one person who posts at least 5 others played the game, and upon the concept that most people will only post if they find something wrong, I then sent the game for peer review. It sat in peer review for a week until it finally got a response. A single minor bug was discovered that forces the player to use the first controller when selecting the hard-drive. Since I don’t want to be known for releasing a bugged game, I pulled it back from peer review. I was trying to avoid having a “press start” screen that you see in so many other games, because I feel they are rather tacky in a one player game. I’ve been trying to build the game to work with any controller, by polling for input from any controller. In places where I have to specify what controller to use, I simply specify the last controller from which I recieved input. The problem is quite simple really. When it comes time to select a hard drive, the player may or may not have actually pressed any buttons on the controller. If the player hasn’t pressed any buttons, then I have no way of knowing what controller to pass to the hard drive selection process. I had the thought of not calling on the hard drive selection process until after I’ve recieved some sort of input, but this presents another set of problems in that the player’s volume settings won’t be loaded for the main menu. It’s very important that the player’s preferences be observed, so this isn’t really a viable option either. The only option left that I can think of is to have some sort of “press start” screen like all those other games present. I’m going to make mine a bit different though. To avoid the volume preferences, it won’t have any music or sound effects, instead it should just be a visual thing. The title of the game will be in the center of the screen. Behind the title, the screen should be filled with a random playing grid. This grid should cover the whole screen and be functional. Every second or two a button on the screen should be selected, and it should be “pressed” simulating the actual game. Whenever the player presses ANY button on ANY controller, the game should then trigger the hard drive selection screen, then put the player at the main menu. This actually has an added benefit of showing the player how the buttons interact with each other, kind of a reinforcement of the tutorial.
Ok, well Short Circuit has been submitted for developer play testing again. In the previous round of play testing they found a few things that needed some attention. Of course, in keeping with my promise to keep you guys up to date, this post will tell you what they were. This time there was only one major bug reported. If you selected the “Purchase” menu option it required you to use the first controller instead of whatever controller you were using. I fixed this by adding a variable to my input manager that would track what controller was used in the last registered controller activity. When I say registered, I’m meaning controller activity that the game actually responded to in some way. Using this new variable I was then able to open the market place using the controller index that actually selected the menu option. The question was raised in the review of why I don’t just use a “Press start” screen to detect what controller the player is using then just use that controller for the rest of the game. Had this been a multiplayer game, I probably would have, but because it’s a one player only game, I wanted the player to be able to play using any connected controller. This way, if the batteries in the controller die, the player can simply grab another controller and keep solving the puzzles. The reviewers also mentioned that if you select a menu option on the main menu and did not release the button, it would cause the next screen to also select something. This was my fault as in my input manager I provide foure functions for detecting button presses; ButtonPressed, ButtonReleased, ButtonHeld, and ButtonPressedOrHeld. On many of the sub-screens I had been using ButtonPressedOrHeld which was still catching the held button from the previous screen. Obviously, I changed all button presses to use ButtonPressed, and left the directional keys to using ButtonPressedOrHeld. One reviewer noted that if you enter certain sub-screens, like the options screen, then return to the main menu that the music would get louder. This was because I was setting the volume on the options screen, but not on the main menu. I’ve since gone back through all screens to set the volume when music begins. One reviewer noted that if you selected the “purchase” option from the main menu and you were using a controller that was not able to make purchases that the game just wouldn’t do anything. I’ve added checks to determine if the current controller has access to purchase, and if not it’ll show a nice little message at the top of the screen to let the player know. The last thing that was noted by the reviewers is that some of the text on the credits screen overlapped each other. Obviously this isn’t a show-stopping bug, but it’s a bug none-the-less and needed to be fixed. I’d have to say this was probably the easiest of the bugs to fix this round, as all I had to do was lower the font size for the credits screen. One reviewer did remark that the instructions that I provided in the game are very well written and make it very clear how to play the game. Another reviewer said that I should provide some graphics on the instructions screen to break it up a little bit. I took another look at the screen and have been unable to figure out how to make it better, so I’ve left it as it was. There was one last change, but this wasn’t prompted by a reviewer. The error handling code that I initially wrote for the game would display the last 43 error messages on the screen. When it was first built it was for the PC and pressing F12 would clear the message queue. When I translated to the Xbox I did not change this code so the end result was that error message would be displayed on the screen and would never leave for as long as you played the game. It’s a very good thing that the reviewers didn’t say anything about this, because that means they never got any error messages. Even though no error messages are being displayed, that could still be a major problem later if a player ever does get an error message, so it had to change. Now, there are no limits on how many messages can be displayed. Instead, messages are added to the queue then start to fade out until they are invisible. Once invisible, messages are deleted from the queue. So far, this is the best solution I’ve come up with, and I rather like the effects of it too. That’s all the changes that were made for this play-test release. It’ll be in play testing for one week, and once again, if nothing major is reported it’ll probably be sent for peer review so it can be published to the Xbox marketplace.
What can I say? I’m dedicated, or something like that. I know I previously posted that I was going into Holiday Silence and would not be working on this, or any of my projects. Well, I just couldn’t help myself. As I mentioned when I started, this project has been whispering to me for years, and has been getting louder the whole time. I finally started this project when the whispering became a steady screaming. As soon as I actually started working on the project, it quieted down. Now, as I attempted to stick to the Holiday Silence, the project started yelling at me again, so I had to get back to it sooner than I had planned. Now for what’s been changed. The game now has an official demo mode that was built for the Xbox indie market place. Yes, that’s right, once it’s published on the Xbox marketplace, you will be able to download a demo version of the game. The demo version is the same game, but it only has 6 levels in each of the game modes, and has a menu option for purchasing the full game. On reviewer suggest I’ve also added an instruction screen. It’s not much, but I think it should provide enough details to let players know how to play the game. Incidentally, the reviewer commented that they didn’t know what to do in the game when it first started, which is why the instruction screen has been added. On the Xbox, there is something called the Title Safe Area. That’s a section of the screen that is safe to use because any screen area outside it may be cut off by some televisions. When I built Short Circuit, I had built it for a targeted resolution of 640 by 480 pixels and hadn’t know anything about title safe areas. While I’m still targeting the 640 by 480 resolution, which is supported by the Xbox natively, I am now also using the title safe area in placing all text or graphics that include text. Finally, one of the last additions was the inclusion of error catching in virtually every function of the game. One of the reviewers pointed out a condition that would cause the game to crash. I’m hoping that the added error catches will prevent this from occurring. Since all these changes are completed, I’ve submitted the game for play testing in the Xbox developer forums. It will remain in play testing for one week, during which I hope to get some good feedback. If it manages to make it through the play testing without any major complaints then I’ll resubmit it for peer review and release.
I recieved my first set of reviews for Short Circuit recently, and have since pulled the game back out of the review process in order to fix the issues. Here’s a small list of what was found:
- Title Safe Region – Games built for the XBox and virtually any other console essentially have two different display sizes. There’s the full screen dimensions, then there’s something called the Title Safe Region. The title safe region is slightly smaller than the actual size of the displayed screen because some televisions have curved sides that would cause anything outside the title safe region to fall off the edge of the screen. It was brought to my attention that some of the text in the game falls out of this region. As such, I will have to go through all the code changing all visual positionings to be within the title safe region.
- Trial Mode – In order for the game to sell, I have to add a means by which to make the player want to purchase the game. Obviously if they have access to playing every level in the trial version, the player isn’t likely to pay for the full version that offers the same thing. Thankfully, the XBox developer community has pointed me in the right direction to make it possible to limit the levels that are available in the trial version. Aside from writing the code, my next biggest hurdle will be selecting what levels to allow in the trial version.
- Instructions – Some of the reviewers complained that they didn’t understand what to do when they first started playing. For some reason, I thought the first few levels made that obvious, but I was wrong. So I’ll have to add in some sort of tutorial or instruction page to teach the player how to play.
- Hints – This one’s a doosie, and I’m not even sure if I’ll be able to figure it out. Essentially the reviewer asked for me to add some means of obtaining hints about the next move. While I like this idea myself, the problem is figuring out the algorithm that would be needed to determine what the next move should be. Once I’ve figured out that part the next question is, how many hints should the player be allowed? At this point, I’m thinking that if I am able to get the hint system working, that I should give the player 2 hints to start with and let them earn an additional hint for every three levels completed under par.
- Crash Cases – Aparently on the XBox there are certain conditions under which a game will invariably crash and I’m supposed to be handling it. In this case the reviewer pressed on the guide button on thier controller when the game was asking them to select a hard-drive for saving and loading. I’m under the impression that this can be fixed easilly by adding some error handling code in those affected areas, but just to be sure I’m going to add error handling code everywhere in the game.
That’s all the feedback I’ve gotten from the reviews, but that isn’t the end of my todo list. I’ve actually noted an issue myself that I plan to fix. When I initially built the custom error handler, I was developing the game for Windows. I had it coded so that you could clear the list of errors by pressing F12 on the keyboard. Obviously the XBox doesn’t have that button, so I have to provide a different method. Since I’m going to be adding error handling in virtually every piece of code in the game, I can be fairly assured that the game won’t crash, meaning the player can still navigate around the game even after a fatal error. This is good, because I plan actually doing two things with error messages. First, I’m going to display a short message on screen that essentially says an error has occurred. This message will fade out over time. Secondly, I’m going to add a new screen to the game that is designed explicitely for displaying all the error messages that have occured. This screen will not be accesible unless an error has occurred, and will then be accessible from the main menu. This screen will be a scrollable screen allowing the user to scroll through all the error messages regardless of how many there were. This screen will also provide functionality for exiting the screen and clearing the error list.
As of this moment, Short Circuit is awaiting peer review in the XBox Developers portal. If it is approved through peer review then it will then be available for purchase from the XBox Game Marketplace. It’s my understanding that once it’s approved I will be given several codes that I can give out so that some of you can get the game for free. Unlike other publishers I won’t be tweeting the codes out. Instead, I will be emailing them to the first people who email me asking for it. To make it easier, you can simply use the “Contact Me” section of this site, but make sure you include your email in the message so I know who to send the codes to.
I’m very excited to say that Short Circuit will be submitted for developer review soon. That means with any luck, you should be able to purchase it for your Xbox console very soon. In the mean time, I’m working very hard to make it the best game it can be, and to make sure it passes the developer review. Last night I finished creating and testing the rest of the advanced levels. I also added some instructional graphics and text at various locations in the game and improved the UI in a few places as well. Overall, the game has a much more finished and polished feel to it, which I like. I’ve also gone back through the controller input code and modified it to accept input from any connected controller. Since this is completely a one-player game, I don’t have to worry about tracking separate inputs from different players. Doing this also solves the problem that would normally be caused by the player changing controllers. A good deal of time was spent last night on the saving and loading code as well. In my play testing yesterday I realized that scores were not saving, even though it was loading existing scores. After analyzing the code and reorganizing how it was intended to work, I’m happy to announce that the data is now saving and loading 100% correctly now. At this point, I am planning on submitting the game for developer review tonight unless I notice any other major issues that need to be addressed.
First change to take note of is updated graphics. I noticed that the buttons looked kind of chunky when they were scaled up for the smaller puzzles, and I felt that just made the game look like raw crap. So I’ve redesigned all the buttons to use just two very large custom button images. I decided to draw the image much larger than they’ll ever need to be so that they will look nice and smooth at any size and resolution. Kind of makes the game a bit more High Definition. One thing that I really like about the new buttons is it’s much easier to tell the difference between a button that it turned on, and one that is turned off. With that done, my next step is to port the game to the Xbox, which is exactly what I’ve started to do. Last night I ported the game over and started testing it on my Xbox 360. Almost immediately I hit a major stumbling block that caused me to grumble and cuss for a good long while before I finally figured it out. Shortly after loading the game on the Xbox console, the Frames per Second (FPS in the top right) dropped drastically all the way down to 2. Yes, that means my game was outputting a mere 2 frames per second. Anyone who’s been exposed to gaming more than a novice gamer would be able to tell you that FPS is a very important number when it comes to games and it should always be at or above 60 for the game to run smoothly. The sheer fact that my FPS dropped all the way down to 2 was staggering to say the least. I did manage to find the problem and get it fixed. Every few milliseconds the game calls an update method. In that update method I was checking to see if there was any music playing, and if not I would start the music. Based upon the game’s behavior I can only guess at what went wrong here, but here’s my guess: On the first call to update, the music is not playing so it starts the music. On the next few calls to update the music hasn’t had time to start playing yet so it sees it as the music not playing and tries to start it again. The end result is that by the time the music actually starts playing there are several copies of it that are playing all at the same time and the game couldn’t handle it. I fixed this by moving all the associated code out of the update method and into the LoadAssets method for each screen. I also added a call to end the music to the Unload method for each screen. This way every screen handles its own music and it only tries to play it once. After fixing the music, the game ran at its normal 62 FPS on every screen I tested. I found it kind of odd that the Xbox would have problems with this when the PC didn’t have any, but it is what it is. I did notice a few other things while testing last night that I intend to address tonight. First, for some reason the classic levels 4 and 7 were the exact same levels. Obviously that will have to be changed, and will be my first change tonight. Secondly there are a few levels that I can’t remember how to beat. I know they can be beaten, I just don’t remember how. I find that to be a problem because if I can’t figure out how to beat them, how do I expect any players to do it? I’ve decided to go through every puzzle and write down the steps it takes to beat them, and replace any puzzles I can’t figure out with new ones. I figure that writing down the steps to beat each level may come in handy later, especially after I add the last two game play modes. Finally, the last thing I noticed that needs fixing is that after you beat each level, it asks you what hard drive to use. Obviously, the game should only ask you this once, and that’s when the game first starts up. I plan on fixing this tonight. As for the last two game play modes, I’m kind of thinking of holding them back for a second version. I figure that with the two game play modes that I’ve included the game can sell on Xbox for about 80 Microsoft Points, which is equivalent to roughly $1 U.S. Dollar. The pricing has taken some careful consideration as like most people I want to earn as much as possible for my creation. Selfish desires aside however, I realize that many gamers don’t have a whole lot of money to spend on downloadable games, so the 80 MSP price tag makes my game a bit more attractive to them. Besides, at $1 per game, I’d earn about $0.50 per game that sold. If a million people buy my game, I’d stand to earn half a million dollars. That’s way more than enough to take care of my family and sponsor my next game, which I’ve already gotten fairly well planned out. I’d imagine that with half a million dollars I could easily have my next game professionally produced by a company like 4J Studios or Bethesda.
Moved a large portion of the code into a separate code library and created a basic game editor. This may not sound like a lot, but it really as a lot of work as I had to ensure that only universal methods were included in the library. This also means that I had to essentially recreate all existing functionality for the editor and make it use reverse logic from the actual game. In the game, the three phase lights go Green – Yellow – Red – Green, but in the editor they need to go Green – Red – Yellow – Green. It’s a simple distinction, but to make it actually happen meant writing that core functionality separately for the game and the editor. During this process, I also decided that I want to handle scoring similar to golf. Each level will have a par that will be calculated based upon the number of moves used in the editor to create the level. I ran a few models before finally settling on par being calculated by multiplying the number of moves by 1.2 and rounding up. Essentially, this means that if it took 4 moves to create the level then: par = roundup(4 * 1.2 ) par = roundup(4.8) par = 5 Likewise, if it takes 6 moves to create the level, then Par = roundup(6 * 1.2) Par = roundup(7.2) Par = 8 This formula may change later when I add the other expected features, but for now I feel it’s a fair calculation. The idea is to allow the player a means by which they can deduct points from their total score. This raised another question to me. In golf, if you go 10 strokes over par, they count your score for that hole at +10 and leave it at that. The question then becomes, how far past par should I allow the player to go? For now I’m not going to implement this option, opting instead to just let the player keep going until they either give up or succeed. With the editor complete, the next concept that I want to implement is what you might call level paths. In some games this might be called campaigns. But it’s really just a list of levels in the order they will appear. I want this so I can provide multiple game options such as a classic level list, and advanced level list, an expert level list, and a tutorial level list. As with many other games, these lists should lead into each other, for instance, the tutorial list should pass you into the classic level list which passes you to the advanced level list followed by the expert level list. Of course once you finish the last level list, it should take you to the credits screen. Anyways, here’s a screenshot of the editor as it is now:
———-EDIT———- I should point out that while I’m providing a screenshot of the editor, I currently have no intentions of releasing the editor with the final game. This is because I’m building the game such that the levels are hard-coded into it. The editor is used for designing the level, and writes the appropriate C# code for the level for me. The end result is that each level is written as a class that predominately consists of several two-dimensional arrays of integers that keep track of each button and their status. I can’t say at this time if there will be an editor in the final version. That will most likely be determined by the amount of interest in the project and the inclusion of an editor.
While discussing this project with my wife last night, I posed the question to her about how many levels should be contained in the game. During our short and informative conversation about this topic, it was brought to my attention that unless a player could somehow resume their previous game, they’d soon tire of having to redo levels just so they can beat them all. This made me ask myself how I could effectively allow the player to continue a previous game and the answer wasn’t all that surprising. I’ve noted that in a lot of puzzle type games, once you select the game type, you are often presented with a level selection screen. The screenshot of the new level select screen follows, but there’s a little bit more to it than what you see in the screenshot. I’ve been pondering over the idea of a global scoring system, and with the creation of the level select screen, I’ve decided to pretty much scrap that idea. The game’s built for golf style scoring, but it’s not really the total score that matters, but whether or not you can beat the level at or under par. Instead of tracking the lowest scores, I’m just going to track par. On the level selection screen, if you have previously beaten a level at or under par it’s button will appear green. If you’ve played the level before and beaten it over par, the button will be yellow. Finally, if you’ve never beaten the level before at all, the button will be red. This way, the player’s goal should be to turn all the buttons green. You’ll also notice that in the following screenshot there are 35 levels. That is not a mistake, those levels have actually been created and play-tested. There are 35 levels in the classic game mode. I’ve also built in 5 classic demo levels and 5 advanced demo levels in case I decide to publish a demo version of the game.
So much done in such little time. Actually, the updates for today have actually been in the works for a few days but just weren’t finished when I posted last. The project is looking a lot more like a real game every day, but without further ado, let’s get on with the changes. One of the largest changes completed today doesn’t really involve a lot of graphical changes, but dealt directly with game input. The game is intended to target the XBox 360 platform but until now it relied heavily upon a mouse because of developmental testing. In today’s update I’ve completely removed all mouse support. Instead of mouse support, I’ve recoded every existing screen to track the player’s current location visually. For instance, on the main menu, the current menu option is highlighted in a brighter color. On the game grid screen, it displays a small cursor to show the player which button they are currently working with. The next major change was the addition of an options screen. With yesterday’s addition of music and sound, I realized the player would need a way to change the volume aside from using their Television remote. As you’ll note from today’s screenshots I’ve provided means for adjusting the volumes for music and sound effects seperately. Also on the options screen, you will notice an Auto-Repeat Delay. I added this option in so the player can hold down a button or direction and have it repeated. If you are on the menu, and you hold down, you will step slowly down the menu continuously. This new option will allow the player to speed up or slow down the rate that it repeats at. A small thing I know, but I thought it was an important detail to cover. On the grid screen I’ve added a few more textual cues on the right side to let you know how many lights there are left to turn on or off. This is a minor thing, but that part of the screen was looking a bit empty with only Par and Moves being displayed. Finally, the last thing you’ll notice from today’s screenshots is some updated graphics. It’s not much, but it does make it look a lot better. I’ve changed all the fonts to royalty-free fonts, and added a custom background image to all the screens. Currently there’s only one background image, but I do plan on adding more later so there’ll be some variety in the scenery.