Category: Engine

Posted on

Anomalies

Category Icons

Another problem that I noticed during the playtest session was that there was not a clear correlation to the player between what they were doing in the level and the rank grades after the level was completed.  Therefore, I added three icons to the lower right portion of the screen, and numbers signifying the values for those categories which update in real time.  I thought that adding this would make the screen have “too much going on”, but I will leave it in for now.  I also put those icons next to the textual descriptions on the level complete screen, so that there is a direction connection between the icons on the game level screen and the categories on the level complete screen.

I also tried coloring the icons in real time based on the current rank value for each category.  However, this was confusing because pieces and time would start out yellow (S-rank) and luminosity would start out red (C-rank).  This is because the player raises their luminosity rank over time, and the player can only lower their  piece and time rank over time.  Plus, the colors would sometimes change and flicker too quickly between grade colors at times.  Therefore, I left all of the icons and numeric values white.

“The Level 2-6 Problem”

There is a visual connection problem that only occurs when placing a resistor next to two objects, where one of the objects in another resistor.  This is apparent on level 2-6, where you have to put a 1 resistor next to both a wire and a level 2 resistor to get the maximum luminosity of 2, as shown in the screenshot below.  Notice the connection between the 2 and 1 resistors, which really doesn’t exist when looking at the flow values, but it is incorrectly drawn.

 

Displaying the flow values shows that the resistor’s value is automatically deducted from the flow value.

 

I rewrote most of the code in the  method which returns the wire image used for a specified cell.  This code is used for both the wire and the resistors, since the resistor is overlayed on top of a wire image.  First I load four variables containing references to each of the four adjacent pieces (or null if one doesn’t exist).  Then I start assigning null to those variables if a connection to that adjacent cell should not be made.  Finally, I have an if/then statement which looks at those values and then returns an integer ID representing the wire image to use to make the appropriate connections.

I started seeing the one frame flicker problem again, when a new piece was placed  next to more than one adjacent pieces.  I found that the line of code that placed a new piece on the board was located after the code which updated all of the pieces.  Therefore, the first frame of a new piece was always incorrect.  I moved the line of code which adds the new piece above the piece array update check, and now the flicker problem is no more.

For each piece, if it is not filled or filling, then it should make all possible connections because there is no way to tell which direction the flow will be coming from.  If there is an adjacent cell, it should make a connection to that cell if the flow direction (stored as an instance variable of the GamePiece) is coming from that direction.  Conversely, a connection should be made to any adjacent cells which have flow coming from the current cell.  Otherwise, a connection should not be made to the adjacent cell, because it could possibly have a different flow value.  One continuous wire should not have two different flow values, which I explained in an earlier post.

Below is what the corrected display looks like now.  A lot of work to fix a small graphical anomaly which nobody would have probably ever noticed anyway.

 

Additionally, I updated the code so that the luminosity icon value only increments after the LED fills (not as it starts filling).

Posted on

Playtesting at KGD Meeting

Attended the Knoxville Game Design meeting at The Technology Cooperative and received a lot of good feedback from fellow developers.  The guys at Chaosoft were particularly helpful with their suggestions to improve controls and gameplay.  It was my first time seeing other people play the game, and served as a good informal cognitive walkthrough.

A couple of gamers tried out my game, and it was quickly obvious that the game wasn’t clear about which buttons perform which actions.  In the old days we had instruction manuals that told us the controls, but it was usually faster to figure out the controls than looking it up in the manual.  With digital distribution, we no longer have the luxury of providing the player with a hard copy manual, so all of the control explanations have to be built into the game.  Also, back in the NES days we only had 4 buttons and a D-pad, so figuring out the controls was a lot simpler back then.

One helpful suggestion was to put the wire on its own button.  This was an obvious control improvement, and I couldn’t believe I hadn’t implemented that earlier.  The wire is used much more often than the resistors, so it clearly warrants having its own button.  Separating this functionality took a little bit of time, but it was worth it.

A graphical “A” button has been added below the wire selector, and a graphical “X” button has been added below the currently selected resistor.  The animated arrow which previously pointed to the selected component has been removed.  This makes it clear which buttons perform which actions.  I also added “LB” and “RB” labels next to the “X” graphic.  “LB” only displays if the selected resistor is greater than one, and “RB” only displays if the selected resistor is less than the maximum (however you can still press those buttons to make the selection loop around).

There was still some confusion about hooking up a resistor with a lower flow value than the LED, so I may have to add some more explanation about the rankings, especially the “luminosity” ranking.

Another suggestion was to display a timer on the game level screen, so there was an indication of how well you are doing  in respect to the time rank.  I’ll see if I can work that in, but I think it may make it appear as “too much stuff going on” in the game screen.

The screenshots below show the new button displays, as well as the new blue color if the LED wasn’t connected with it’s maximum flow value.  I chose blue because it is a cold color, and it was different than the default “off” gray color of the LED.

 

Posted on

Peer Review Preparation

Evil Checklist

I started reading about what needs to be done to publish a game, and I noticed a thread on the App Hub site referencing the Evil Checklist.  I’m not sure if my game needs to pass everything in the list to submit it to the contest, but it’s probably better if it does.  For instance all games must have a trial mode to be approved to be published to the XBox Marketplace, but I’m not sure if that is necessarily required for the contest.  Since I still have two weeks until submission, I will try to make sure that my game passes everything on that checklist.

Right out of the gate, I know my game would fail peer review because it doesn’t allow the game to be played on any controller port.  It only registers input from the controller on the first port.  That may not be a quick fix, but it should be relatively simple.

The checklist also provides various tests for the device selector.  I know I had a problem the other night when the game transitioned to the game win screen (and saved) while the Guide was open.  My game may also not function properly if no storage device is selected, since it always reads from the storage device when the level select screen is displayed to show the ranks.  According to the Not So Evil Checklist, I can force the player to select a storage device.  Therefore, I should be able to just modify the code (if needed) to gracefully handle the state when no storage device is selected, such as returning the player to the title screen.  The real kicker is that my primary XBox (slim) doesn’t even have a port for an MU (Memory Unit) for testing multiple storage devices, so I’ll have to try to get the developer tools running on my old XBox (ugh!).

More Rank Updates

Updated the rank values for the last 30 levels, 7-1 through 9-10.  Played each level twice to get the piece, luminosity, and rank values.  If I got a better score the second time, then I usually played it again a third time.  Basically, I kept playing the levels over until I didn’t get a better score, and then I used the best scores for the S ranks.  I think the game should now be functionally complete, but I might go back and update the graphics for the selected cell (currently just a blue square).