Please visit my site at http://levidsmith.com
Be sure to check out the new Resistor review by XBLA & XBLIG Ratings Top 50 Reviewer joebal.
Also, Resistor has been submitted to the IndieCade International Festival for Independent Games to be held in Los Angeles from October 3 through 6.
The objective of Resistor is to build connections to carry electrical flow to activate LEDs (light emitting diodes). To avoid damaging these components, the flow level must be reduced using resistors. Each level is graded upon number of pieces used, the luminosity of the LEDs, and the time required to complete the level. This game teaches the basics of resistor color code values.
Each level has a power source with an electric flow level. Use wires (A button) to connect this power source to all of the LEDs on the level. Be careful to not connect a wire that has a higher electrical flow value than the number displayed on the LED, otherwise the LED will be destroyed and the game will end. To lower the electrical flow, use a resistor (X button) to lower the electrical flow of the wire. The target is to use a resistor that will lower the electrical flow just enough to activate the LED. Lowering the electrical flow too much will still activate the LED, but the luminosity grade for the stage will be penalized. After every ten levels, a new higher level resistor will be awarded. The currently selected resistor can be changed using the bumper buttons (LB and RB). Complete the levels as quickly as possible with the fewest number of pieces to get the best grade rankings.
Resistor is now on sale in the XBox Live Indie Game Marketplace. Try the trail version for free, and if you like it all 90 levels can be unlocked for $1 (80 Microsoft Points).
From the XBox dashboard, go to Games > Browse Games > Indie > A-Z > R > Resistor
You can also find Resistor in the Puzzle & Trivia Genre section
Thanks to everyone for following the development of Resistor!
I haven’t done any development for Resistor since I submitted it to the Dream Build Play competition on May 30th. Therefore, I went ahead and submitted for Playtest on the AppHub website. I guess this is what it feels like to send your first child to school. However, I’m sure that any feedback that I do get will be helpful, which will make the game better.
There must be some tough critics out there, because the Resistor trailer video instantly received a negative vote after it was posted on the DBP website. Therefore, I went ahead and disabled voting on the video until the competition is over. On the other hand, the video has been getting a lot of traffic, and it is now over 125 views just for being posted for a little over a week. I went ahead and made the video public, because it was previously unlisted where a link was required to view the video. I also made a YouTube playlist containing the complete series of development videos.
After taking a break from looking at the game, I did play it again for a few minutes and noticed new ways to complete some of the levels. I probably wouldn’t have noticed this if I had not stepped away from the game for a while. These new ways allow some of the levels to be completed with fewer pieces, so I may need to tweak the requirement for the S-rank on those levels.
Not that I’m trying to overly promote the game, but I went ahead and made pages on Facebook and Twitter for the game. I did this more as a precaution to keep someone from taking the “resistorgame” brand name on those social media outlets.
I also created new box art for the game, and got rid of the image that I rendered in Blender. I didn’t want to give anyone the impression that the game uses 3D graphics. The background is an interconnected mesh of battery, LED, and resistor objects. I also used some of the trailer quotes on the box image, but I changed “fun for the entire family” to “fun for all ages”. The former wording could possibly sound like it is a multiplayer game, which it isn’t.
Hopefully, the playtesting goes well and it will be out on the XBox Marketplace soon. There are some changes I may want to make before putting out the final version, such as fade-in/fade-out transitions between screens. I also have to jump through a few other hoops before I can actually sell the software.
So sure enough, the first time I tried running the game with two controllers plugged in (first one signed out, second one signed in as my developer account) I get the Code 4 error from the XBox. Even turning off the first controller will generate this error, so currently the first controller must be the one with the developer’s account.
The game will play fine with two controllers having the first one signed in as the developer’s account and the second one not signed in. However, if the first controller signs out from the Guide it will immediately throw a Code 7 error.
I also needed to test to ensure that my game will run on older televisions. It’s a good thing that I paid to have my old Elite XBox fixed about a year ago. Originally, the only reason why I had it fixed was so I could get my game saves off of it to transfer over to the XBox Slim. I think I had to buy a special $20 adapter just to do that as well. Fortunately, now it is going to come in handy, since it is the only working XBox that I have that can read an MU (Memory Unit), which is required for testing the device selector. I also had an old Sharp CRT television sitting around collecting dust, so I can use it to test the lower resolution and 4:3 screen ratio.
After downloading the XNA Game Studio Connect to this XBox and recovering my developer profile, I was able to connect my PC development environment to this system. Unfortunately, when I tried to deploy the game, it just sat on a black screen. This completely froze the XBox system, because pressing the Stop button in Visual Studio and pressing the Guide button on the controller had no effect. I tried changing the resolution constants in my main game class to 1080×720 to see if that would help resolve the issue, but I still got the black screen. Therefore, I had to manually hold the power button to shut down the XBox.
Next, I tried just deploying a default project, and I did get the Cornflower blue screen on the television, which at least gave me a starting point for finding the problem.
I removed the MU from the XBox and tried deploying again, and this time I got a runtime error (which is better than the black screen). It was complaining about my save file not existing. This file must have gotten created on my other XBox during my testing, but I never added the code to create the file in my final game code. The OpenFile was crashing if that file didn’t already exist. To resolve this problem, I just added a check to see if the file exists before it is read. If it doesn’t exist, then it just creates an empty file, which should prevent the error.
After fixing this, I got another error about the file being used by another process. This is (unfortunately) one of those problems that appears to happen only once. I tried deploying it again, and the game runs fine. I believe this was because the CreateFile method opens the file for reading, but it wasn’t closed, so when the OpenFile method tried reading the file, it saw that something already had a handle to that file. However, the next time the game was run, the file was not created, so nothing had a handle to the file when the OpenFile method was called. I went ahead and added a Close method immediately after the CreateFile call. This probably isn’t the optimal solution, but I just want to get it working for now.
It’s a good thing I tested this before submitting my game, otherwise it would have probably crashed the first time someone tried to play it. Unfortunately, there is no easy way (that I know) to entirely remove the game and the files it creates in the process, to simulate a new person playing the game. It is possible to set the XBox back to factory settings, but then I would have to install all the updates, download my profile, and download the XBox Studio Connect again.
I went ahead and added a check around the file reading and writing functions, so it doesn’t try to read or save if the Guide is open. Therefore, it won’t save the player’s data, but the game won’t crash. Theoretically, this should never happen since I’ve added a check to the game level screen, which will transition to the PAUSEGAME state if the guide is active. I also noticed that there is an “OpenOrCreate” property on the FileMode object used with OpenFile, so I was able to remove the inefficient Create/Close code I just added. Using the OpenOrCreate property solved one problem that I’ve noticed, where it wouldn’t always add the achieved ranks to the level select screen, making it impossible to get back to the last level completed.
After all these changes, my game still didn’t use the device selector, which is a requirement to pass the peer review in the Evil Checklist. Spent some time (IO always seems to take the longest) to rework all of the file save code. I quickly realized that the method that I used to save games in an earlier post did the job, but wouldn’t pass the peer review process. The thing that gave me the biggest headache is the asynchronous method it uses to select a storage device. While the player is selecting a device, your game is still running in the background. This made it very difficult to do the load from the level select or game level screens, because the game would be started (or level select displayed) before the storage device is selected. Therefore, I created another screen just for selecting the storage device (LoadScreen) which subclasses my default screen class. This screen will wait (unless the cancel button is pressed) until the storage device is selected and the file is loaded. The next problem was which state should the load screen transitions to after it is complete, because the load screen can come before either the game loop screen or the level select screen. I added a variable to the load screen called iFollowingState, which is set before the screen is shown to track the state that follows. If the user doesn’t select a device, it remains on the load screen displaying a message to the user stating that a storage device must be selected. If the user presses confirm or start, then it will give the user a chance to select the storage device again. If the user presses cancel after not selecting a storage device, then the user is sent back to the title screen. On an XBox with only one storage device, the player should never see this screen at all.
After a little more searching, I was able to find where the XBox keeps the save data for the deployed Creator’s Club games. Under the System menu, select the XNA Game Studio Connect under games, and then there’s another menu under that which contains all of the game data. This will be very helpful for wiping the save game data, to test the game as a entirely new player.
Started reading about the title safe area, which is another requirement on the Evil Checklist. I think my game should be okay, since I was having a hard time filling up the entire screen anyway. I may need to go back and double check some things like the “Replay” and “Next” selectors on the GameWinScreen.
So after I got the game running on the CRT television, I immediately noticed that the year value was being cut off on the title screen. There is also a black letterbox effect around the top and bottom, but I think that is expected in the 4:3 resolution, so I don’t think it would fail peer review for the letterbox effect. The arrows on the level select screen are slightly cutoff, as well as the word “LEVEL” on the game level screen. Everything else is looking good.
Discovered that even though this looks okay on my CRT, it may still not technically be in the Title Safe area, which is determined by the Rectangle returned from graphics.GraphicsDevice.Viewport.TitleSafeArea. I updated the draw method on the main Screen class to take one additional parameter, which is the title safe rectangle. Therefore, I had to update all the screens that subclass Screen, to accept this new parameter. However, it will be beneficial in the long run, since all draw methods will now have a reference to the TitleSafe area.
After adding the new TitleSafe Rectangle as a parameter to the abstract Draw method for screen and implementing it in all the subclasses, I drew a transparent red rectangle cover the title safe area. This is really helpful in determining if anything is outside of that area. I added a variable in the main game class, which can be used for turning this red tile safe box on and off. I updated all of the screens appropriately, so vital information does not display outside of this area. I left the scrolling arrows on the level select screen and parts of the S-rank circling stars immediately outside of the of the title safe rectangle. The stars are just for show, and the user doesn’t need the arrows for navigating the level select screen. As seen in the screenshots below, I had to move the selectable resistor icons slightly down, the “LEVEL X-Y” label to the right, and “Replay” and “Next” buttons up. I had to move all of the text on the Game Win screen slightly up for everything to fit in the title safe rectangle.
Updated the Level Select screen, so that if the selector is over a level that can not be played at this time, it will have a darker color. This was accomplished using the isLevelUnlocked method that I previously created.
Noticed that when pressing right on the D-Pad, the cursor will keep moving after the button is released. When I checked the main game loop, I was actually calling rightPressed instead of rightReleased on the current screen when right was pressed on the D-Pad. It’s hard for me to believe I didn’t catch this earlier, but I always play the game with the thumb stick.
Also noticed while testing the multiple device selector, the device selection menu would popup every time the Cancel/B button was pressed. This was a really old test when I was first implementing the save feature, but I guess I never took that line of code out. I never realized it was still doing that on my main XBox, because it doesn’t show the device selector when there is only one storage device. It was really noticeable on the XBox with the MU installed. Taking the load game call out of the “B” button detection check fixed this problem.
After almost two months of development, I’m back to doing what I started on the first days of development which is updating the sprite graphics. Updated all of the wire graphics, so now those are filled with light gray (#e0e0e0) with white (#ffffff) and black (#000000) around the edges. It seems to make the wires stand out a lot better. Unfortunately, since the shading is on specific sides of the sprites, I can’t do the quick flip/rotate trick that I used when first creating these sprites. However, Gimp provides the ability to zoom to make the pixels really large, which makes adding the outlines rather easy. Just tedious. It should just display as a slightly darker shade of yellow, since Yellow is used as the color parameter of the draw method. Thought about adding an option to allow the player to select their flow color, but it’s too late to add that now. Maybe a new flow color will be the reward for completing all of the stages.
While I was making graphics, I went ahead and replaced the GameThumbnail.png and Game.ico graphics. I modified the resistor image with four connections, and replaced the number with just the letter R. The size for the GameThumbnail was 64×64 pixels, which I believe is used for the dashboard. The graphic I created is simple, but it does the job. The Game.ico I believe is only used for when it is running under Windows, and maybe under the XBox system menu.
Made a trail screen in the game, which subclasses the basic Screen class. It was a little frustrating to test this, since the game is not in trial mode as I am developing it. There is a Guide.SimulateTrialMode value that can be set to make the game run in trial mode for testing. Or I can run the game as trial mode from My Game list, but the game has to be deployed from Xbox Studio Connect first.
Copied a lot of code from the Pause screen to implement two selections, “Buy” and “Back to Title”. Choosing “Buy” will call the Guide.ShowMarketplace method. This doesn’t actually purchase the game, but instead takes the player to a standard XBox screen where they can purchase the game.
Added a check in the update method of the trial screen to see if the game has been purchased. If it has been purchased, then it displays the “Thank you” message and removes the buy option from the screen (leaving only the “Return to Title” option). From there, the player will have to use level select to pick up at the last level they were playing, because it’s too late now to rework the code for an event that will just happen once for each player. Ideally, I would have a “Continue” option from the main menu, but I wanted to keep the main menu simple. Having to find the last level played in the level select screen is the “price” the user has to pay in time for having the simple menu.
Added my cheesy Indie game “song” into the trial screen. I had to work it in somewhere.
Had to add a special case to fix the level 10 LED (piece ID 30), just as I had to do with the level 10 battery. Made comments in the code that these should be optimized later.
Added code to center the numeric text of the batteries and LEDs, since the “10” value was displaying near the edge of the battery and LED.
Maybe it’s just me, but the scrolling background for the game level screen on the XBox seems choppy. It doesn’t do this for the PC version. Not sure if that is fixable, or if it’s just my eyes playing tricks on me from looking at monitors too long. The scrolling background for the title screen doesn’t look this way either. I may have to re-evaluate some of the code that I used for the slow scroll method. Alternatively, I could just set the level select background to scroll one pixel per update, just like the title screen does.
Noticed a problem when the level ends and tries to save. If the Guide is already open, then the game will crash, because the file save operation uses the BeginShowSelector method which conflicts with the Gudie. To fix this rare scenario, I think I can just pause the game when Game.IsActive is false which is suggested by this article. This only happens if the player draws the connections to complete the level, and then presses the Guide button before the level is complete, which will cause the level to complete while the Guide is open.