MyI@FarNiche

Building an XNA Game Studio XBox360 Indie Game.

[page 0040] ~ TrailBlazer Optimization:

Tough Month.

This months free time has been eaten up with the 17th Annual Camping Excursion and all its preparation, leaving little to no time for One Game A Month.  Sad but true, actually great and amazing.  The 23 year old van, camping gear acquired over the past 17 years and myself needed a little morale boost and many repairs to do it again this year.  And this trip has given me much food for thought about the game I’m building.  But first . . .

Continuing the game build.

This game continues the previous builds.  But in this version, the objective will be to optimize the games runtime efficiency.  The meaning here is that, while building up to this point the game has had features added to where the avatars direction buttons no longer function with the speed expected.  The button is clicked but the games reaction time is slowed to the point where multiple mouse clicks cannot be registered within the game fast enough to provide a smooth gaming experience.

A slight backtrack.

While reading last months blog to get an idea of what this game has come to be, I’ve noticed some typos that need correcting.  Done.  And now to go about starting the next version of Wanderer 2 to become TrailBlazer.  Open the web page and select “View source” from the dropdown menu.  I have Notepad++ installed and set as my default web page viewer so the code from the page opens in Notepad++.  Then open Processing.  Back in Notepad++ select all the code from inside the canvas script and paste it into Processing.  All that needs to be done now is to open the data folder from the last games version, Wanderer2, select all the art asset files and drag them into the TrailBlazer page.  Processing prints out that 31 files have been added to the sketch.  In Processing, save the file and click “Start server”.  And nothing happens.  Ah yes #213 through #219 need to be switched, from those commented to uncommented and vice versa, because while running the game in Processing in comparison to running this game from the web the names given to access the art assets have different directives that point to where the files are located.  The files are located in the sketches data folder on the computer while constructing the game and in the web directory of the site when running the game through a web browser.  Another thing that I had forgotten was that a precompile directive /* @pjs preload=”. . .”; */ needs to be deleted, not just commented out, and replaced so the splash screen pictures are recognized when run from the web, or the computer file folder.  More intricacies to remember, hmm.

So anyway it’s up and running again.

It still works, as the last build, and now I can start to dig through the code to make this game run more smoothly.  1794 lines of code to get this game to run.  It comes out to be 60 KB as the .pde file with the art assets weighing in at 0.98 MB.  It’s a small game but the logic and accompanying algorithms eat up way too many CPU cycles.  I think the real problem here is that the draw routines are the true culprit.  Each time the screen is redrawn the entire switch/case loop, which calls the draw functions in succession from an array for each terrain feature in the 23×23 grid, 529 terrain grid draw calls per cycle, slows the game to the point where the mouseover() functions for the avatars directed movement grind to, pretty much nearly, a halt.  And this is my inefficiency, the draw loop.  And this is what this months version will address.

The game face, On and Off.

To get an idea if this is the true culprit I’ll need to turn off all the terrain draw calls to the screen for the grid map.  Eeek gad!  I’m lost again, in my own code, and my comments seem to lie to me at times.  This system, Processing using JavaScript for the web, although similar to the C# and XNA programming system for the XBox, is starting to become overly familiar and makes me think, when I jump back into XBox programming, I’ll need to restudy and re-research a lot of protocols and concepts, more hmm.  Now how do I comment out the terrain grid draw calls for this game without breaking the build.  #436 #508  Block commented that switch/case out and the terrain no longer draws to the screen and the avatar direction button clicks are as fast as can be expected.  But does the game run in its entirety and complete as desired.  My questions here and throughout this blog are perpetually invoked rhetorical consternations because of the state of the game build not actual directed questions per se.  So instead of burying this blog with question marks they will all be finished with periods unless an extreme need for questioning is to be exemplified.

Testing the blank grid.

The terrain grid is blank.  The only features on the map are the grid lines and the avatar.  The grid squares are 25×25 pixels.  Moving the avatar is now more reliant on the mini-map because that is where the terrain icons are seen.  The newly introduced problem here is that, although the springs coordinates are seen in the list, the complete route from spring to spring cannot be planned in advance.  Every grid space is and remains blank with each avatar movement.  To simplify the avatars trail blazing capacity I’ll first see if it is possible to place the springs on the map.  #627 to #646 is the randomization of the springs on the already populated terrain grid.  I added an if/else to the for/loop and the springs are visible at the start of the game.  Ok, that works well enough.

Blazing the Trail.

The games avatar direction movement clicks are up to speed, the map shows where the springs are located again and the mini-map has become a more useful feature.  Now to work on what has given this game its name, TrailBlazer.  What is lacking is the trail that has just been blazed by the avatar.  All that I can think of for this would be an array of booleans that will retain truth or falsity in concern to the passage of the avatar as this hero steps into a grid space on the map.  This would keep the draw calls to a minimum because, for all practical purposes, a player wouldn’t step into every grid space on the map while trying to get to each spring.  The most livable trail is the most viable route and therefore would not cover the entirety of the map.  The load on the CPU would be lowered and the game speed would be kept up.  This is the best line of optimization that I can come up with as this months game submission draws near.

Building the Trail.

#116 boolean[][] TrailGrid = new boolean[25][25]; will be my starting array for the avatars path.  Initialize the array in a double for/loop at #283, TrailGrid[i][j] = false;.  And where will I put this variable so that it is updated when the avatar moves into a space on the grid and sets the flag to allow that grids terrain icon to draw on the map?  It seems that I should move backwards from the draw function where all the terrain icons calls are made and set that boolean flag there.  Once I figure that out, how and where to place that variable should become more apparent.  So what happens, #436?  Nope, #447 is where the springs are allowed to pass the flag as if(grid == 9) for the switch/case.  So if that boolean is changed to if(TrailGrid[i][j] == true) then I’ll need to go back and assure that that is initialized to true to show the springs at the beginning of the game.  And of course the answer is where or how or both.  And that also means I can get rid of the else{} part of the if() statement.  Ok.  #309 place it in the Spring Hamlet Visited initialization loop in the setup function at the beginning of the game.  Now the scary part, does it still work?  Oh yea, that’s cool.  But what happens next so the trail that has been blazed remains on the map.  #1593 TerrainGrid[HX][HY] = true; should do it.  Nope, not even close, back to #447.  TerrainGrid isn’t TrailGrid, simple wrong variable name, and now it works correctly, kinda.  Why does the grid on space (0, 0) always draw?  Nothing else draws because of the boolean flagging, hmm.  I don’t get it.  The for/loops are set to zero when initialized and the for/loops that are used to call the draw functions for the switch/case is also set to zero so I don’t understand how or where the upper left hand corner of the grid map is getting the “ok” to get that icon drawn to the screen.  That one is a total mystery to me.  So what you do is hard code TrailGrid[0][0] = false; in both the setup initialization and the reset functions and what do you get.  To get mean about it, how about #1786 text(” ICON  (” + TrailGrid[0][0] + “)”, 600, 165); // label. And the answer is “true”.  But how is it changed to true after the explicit declaration as false?  Why, where and or how is it reinitialized?  Now to get dastardly about this and #1544 put the initialization in a loop that is continuously called.  And the result is, it looks like it is drawn at the start of the game and then undrawn as it gets to that function.  Something is overwriting that and I don’t like it.  Ok, that works.  Both the avatar and that unruly terrain icon are drawn in the upper left hand corner for an instant when the game starts.  But the avatar moves to the center of the playing field and now after moving that TrailGrid[HX][HY] = true; // set the grid that the avatar is in to true. setting to the end of the draw() function #675 it is working properly.  Comment out #1788 and all is well.

The Mini-Map.

#1543 void Hero_Progression()

#1589 void Hero_Surroundings(int grid, int row, int col)

These are the two functions that need some work if they are to have the mini-map viewable at all times during game play.  The idea here is to take the position of the avatar on the map in pixels, convert that value to a grid location in the 23×23 grid map, which in the array is 0 through 22, take those numbers and find it in the array, where that terrain type is then placed in the 3×3 mini-map.  As noted, when the avatar is on a border of the playing field the algorithm tries to access a value that is not available in the array which holds these values.  The result is an access violation which causes the game to crash.  Having some type of validation or error checking is where this is going towards.  The initial problem is that negative numbers are introduced when deriving the result and although it is easy to manipulate this is really not a best practice and produces this very problematic error.  As it stands, for this nested for/loop, the conditional has been placed inside the innermost loop.  It was simple and moved the game to completion.  What is needed now are a series of conditionals where dedicated nested for/loops are placed inside these conditionals.  It may seem a little more clunky but it should provide the desired results, that being the capacity to view the mini-map from all locations of the avatar on the grid map.  There are eight problem positions of the avatar.  The corners where rows and columns are unviewable, the top and bottom sides where rows are unviewable and the left and right sides where the columns are unviewable.  Again, the numbering is from 0 to 22 of this 23×23 square of 25×25 pixel grids.  The top left is coordinate (0, 0) and the bottom right coordinate is (22, 22).  In the mini-map the top left is (0, 0) and the bottom right (3, 3).  Added #1577 to 1712, which are the afore mentioned nested loops inside conditionals to make the mini-map work properly while the avatar is on the playing field boarders.  Added also, so this will work is #1444 void OutDoors_Blank(int X, int Y).

Back to the Upper Left Corner.

TrailGrid[HX][HY] = true; // set the grid that the avatar is in to true.  This is still causing problems but I think I can guess what is happening.  HX and HY are initialized to 0 in the setup function.  The game begins to run and although TrailGrid[0][0] is set to false, never mind, like it always is in programming and mathematics, order takes precedence.  All I needed to do was switch two function calls which were one atop the other so that the Heroes position was set the first time through before the call that requested the use of the variables from that call, duh.  So why are things always in the last place that you look?  Because once you find what your looking for you stop looking for what you’ve found.

And That is That.

The game code for this month is finished.  The game speed has been optimized by clearing the terrain map and then having only the terrain icons appear when the avatar has moved into that grid space affording the game name TrailBlazer to be held true.  The functionality of the mini-map has been enhanced by having all positions of the avatar on the grid capable of reflecting the surrounding terrain from all locations.  The mini-map no longer fails to be visible while the avatar is on the playing field boarders.  No errors have been introduced while advancing these improvements and the game in its entirety has lost no integrity.  This has become another successful versioning expedition in coding practices.  I’m satisfied with this months outcome.

Play the Game.

Trail Blazer

G’day.

Advertisements

July 1, 2013 - Posted by | 2013 [0019] to [00??], The Process

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s