Unity In Game Level Editor for VXT

I decided to create a level editor for my Senior Production game VXT.  VXT is a side scrolling 2.5D racer where players compete to finish levels with the fastest time by using a polarity shield to attach or repel to objects a navigate the world.  Example video shown below.

Because this game is based off of very short 1 - 2 minute experiences I figured how else to encourage players to really compete against one another the hand the very tools of world creation to them and let them go to work and see if their friends can beat their creations. As one of the creators of VXT I tried to make interesting and action packed levels but as I can see from other games with player level creator tool, there are some really talented people out there that will put in the time to make some really amazing levels.

So I with all of this in mind I set out to accomplish the follow goals:

1. Create a in game level editor to allow player to use a Gamepad to build a world.

2. Make a dynamic menu system to allow world pieces to be easily categorized for streamlined building

3. Allow the ability to save local and test the levels in game at the touch of a button.

4. Give players the ability to push their levels to our server.

5. Make it so other players can pull down levels from out server and play them locally.

6. Save high scores and "Ghost" characters for all custom levels to enhance competitive play. 

Creating a level editor in itself is the easy part, making it usable is the challenge especially when the player is working on a game pad, even things like navigating menus becomes a challenge without access to a mouse and keyboard.

Since our world is basically created in a 2D space, it made this whole navigation to build thing a little easier.  I put the player on rails setting them on a specific axis a set amount back and limiting the player to only be able to move up down left and right using basic translation.  This way the world and the player is always lined up at least in the Z axis.  The pieces for manipulation are set much further back but since the player can't move in the Z axis the pieces are spawns a set distance away and will always be on the correct Z axis.  About halfway between the player and the pieces spawn location I added a transparent plane  as sort of a aiming sight so the player can more easily line up pieces. More so on the movement set I added in the ability to drastically reduce the speed in which the player moves the builder, upon holding down the left shoulder button the player moves at 1/8th speed.  This allows the player to quickly move from section of his or her creation to another section, but then give precises precision when placing the pieces. 

Next logical step would be to worry about how we actually spawn the objects we want to build with, but in my case this goes hand in hand with our dynamic menu system.  In VXT we have many different types of objects we have ramps, pipes, walls, blocks, and any of our intractable objects such as speed bad and colored walls. As such I wanted to created at nested menu system to allow players to know exactly where each piece is located.  Unity has a resources folder inside that folder I created a bunch of prefabs that the player will use to build the world.  These prefabs are named and prefixed with a tag of what they actually are So for example Pipe_Half Pipe.  The pipe prefix causes the pipe object to be placed in a sub grid. To create these grids I used Unity's GUI_SelectionGrid.  The grid takes in the parameters height and width of the buttons, the number of rows and columns for the grid, the current selected item and an array of the names of the items in grid.  These work out so well for my implementation, the selected variable allows me to use the grid with the xbox controller, I increment the variable based on the direction of the left joy stick, I also add in a delay timer so that it I only move up or down 1 ever so often.  Even better when the player selects an object I can use the display name to directly look up the object they want from the resource folder and instantiate it.

    Once it is instantiated I place it on the spawn point and it is now attached to the builders movement.  Upon hitting A the builder will let go of the object and set it in place.  This is where a lot of design and quality of life decision come into play.  In order to make this world truly customizable I granted the player the ability to scale and rotate the objects they are holding.  If they hold the left trigger they can change the scale of the object with the right joystick, the X scale left and right, and the Y scale with up and down.  We simply change the Euler angles directly in the object.  The rotation is similar, If the player hold the right trigger the right stick changes the rotation in the same way as scale.  More importantly I needed to add a slow effect to it much like the movement. If they player holds the left bumper it slows down the rate of change that way the player can scale and rotate things perfectly.  These are the basic building blocks of the level editor with everything I mentioned above they are able to fully create a world to play in, next comes the real challenges, testing these world, and sharing them.

    Testing the world quickly is actually quite an easy task, when the player selects save from the start menu (being implemented the same way as the menu system) I save out all relative data to the world, so item names, their position, rotation, scale, and any special properties if they have them to a xml file. I also prompt the user for a name of the level which I then name the xml file accordingly.  I then remove the builder object add in the player.  At this point the level is fully playable.  Once the player reaches the end of the level or quits, I remove the player object add in the builder and then they are ready to continue creation. It's quick easy and allows for fast iteration and testing of sections.

    With the level file already saved out in an XML format sharing the level is easy as pie.  When the player saves and uploads the object. I make a call out to our php server, in there I have a script to add files onto our server, I call the script and hand it the xml file.  The server takes the file and prefixes it with the players username from the game, this allows people to name their levels whatever they want and not worry about them being overwritten as the account name keeps them unique.

    Once they are up there having a someone else pull them down and play them is super easy.  I have another php script that will pull down all levels on our server. I make an empty scene that the player can view the list of player made levels in.  I pull down the names of all the levels and display them in a selection grid. When the player selects one, I use another php script to get the xml file from our server based on the name. I download the file and then build out the level line by line add in a player and just like that they get the ability to play the level.  Furthermore a ghost file is brought down as well which shows the exact movements of whatever person has the best time on a given level, so you can directly compete with your friends play.   

All six of my goals were completed and it was quite an interesting experiences that I feel good about taking the time to complete. 

Physics : Attempted Mass Aggregate Physics

Above is my attempt at creating a Mass Aggregate Physics system.  A Mass Aggregate Physics system is one in which objects are made up of many little masses which based on forces applied to them cause the whole structure to move and rotate.  For example instead of a box being one single entity it is made up of 8 nodes all interconnected via rods. When we want the box to rotate since there is no central mass to grab and do so we apply force to a few of the 8 nodes causing it to move and rotate in a corresponding direction.

In my take on this physics system I have the follow physics types.  Basic balls which can be used on their own as a single object or points in larger objects.

Springs which much be at least two connected nodes or a node and a fixed point in space.  Springs have a have a certain amount of elasticity to them causing them to apply force outwards if they are compressed too close together or apply force inwards if stretched too far apart.

Bungees are another type which while much similar to springs have a minimum length before the elasticity kicks in, anything below the minimum allows the bungee to stay at rest.  This can also be anchored or  interconnected like the springs.

Cables which have a maximum length of which then can stretch too but apply no force inwards upon reaching that.  As well no no minimum length so they can compress as much as they would like.  Consider cables like a piece of rope.

And finally Rods which connect two points and keep them a set distance apart from each other.

Making the basic building blocks of the physics system wasn't too challenging, on their own I got springs bungees and cables working, however the eventual combination of the three and rods in of itself caused me many problems.

Rods being one of the building blocks and my main problem seems like the perfect place to start with what went wrong. Rods seem like a fairly simple task, keep to points no matter how they move equal distance away from each other, simple right? Not so much, my first few iterations of the Rod objects caused some quite hilarious outcomes.  Upon instantiation my rods would try to resolve the collision they were having between each other because due to gravity and basic settling they either got to close to far or both.  Upon resolving the collision they would fly off into the distance (staying the correct distance from each out might i mind you).  While funny and a good attempt at creating perpetual energy it did not create the desired results. I then got rods to actually work when standing straight up or laying down , but upon interaction with any force being applied to them they would practically rip a whole in space and time trying to get away from each other.  It seems that the algorithm that I was using to attempt to resolve the contacts had a double negative and applied forces in the same direction, however a little late in figuring this out and not knowing exactly where to change this means it stayed as a bug.

Attempting to connect multiple rods was even a worse idea. making even a simple square as stated above was way out of my reach,  the structure while only needing 4 nodes needed about 24 rods to hold it together each outer wall of the cube and cross braces to make sure the cube didn't collapse in on itself. However once the rods were in place the nodes would move ever so slightly, they would all have to compensate and the cube would literally rip itself apart, and I was never sure why,  which is exactly why this iteration of my physics system contains no rods.

Beyond creating the basic system with the above building blocks, the task at hand was to create a player made of these objects who could navigate through a world obstacle course created via a level editor all while collecting something and interacting with some sort of artificial intelligence.

Creating the level editor was an interesting task, due to the crunch time that this is, I took the easy route and created a text based level editor.  Basically all this does is allow you to feed in objects via a text file and It will create the world around it.  This was very using in setting up multiple levels  like I did. because when you you completed one, all I had to do was clean up and open the next file and load them in.  Another cool feature of this level editor is because when I reset the world and change levels it re reads the file, you are able to create  and change levels while the game is running, which was great for debugging and creations, all you had to do was hit the reset button.  An  example of  what one of the objects in the levels in the video looks like is below. I just read in the values line by line and create them as it goes. The labels of each item makes it quite simple to understand what each of the values do.

Bungee
x
50
y
10
z
0
radius
10
mass
5
Ball2
x
0
y
10
z
0
radius
10
mass
5
Anchored
false
spring constant
0.01
rest
100
spring constant
0.01
rest
100


Adding in collectibles was by far the easiest task,  I already had basic orb collision in my engine so It was really just making a new object of a different color that when the player collided with it would disappear. In my game when the player collects all of the collectibles this is when the level is over and the next one loads in.

The final portion was the AI which I very much enjoyed creating.  If you look in the video on the top of the screen is a ball that seems to be flying back and forth.  What I decided to do for this part of the project is attempt to recreate the little cloud guy from original Mario games. What he does is takes a look at where you were last frame and where you are now.  Calculate your velocity and then move in front of you.  Upon reaching that the AI has a chance to drop a ball causing more objects for you to collide with and thus ruining your day.  As you can see he kind of just picks a side when you start and hovers around there, in order to avoid edge cases when you are not moving at all and him not just dropping bombs on your head constantly. I added a little margin of error to allow the AI to always hover around one side of you.

With the task at hand "completed" I decided to take this last bit to explain where and why I think things went wrong, because as you can see in the video  the world doesn't really act as well as it should, and it's in a 2 and a half D setting. Somewhere a long the line while creating these features I lost the ability for my object to draw in the Z direction. I'm not sure why but it does happen.  If I try to move objects in the Z direction while they do not look like they are moving, the lines drawn between them do move, and collision between objects behave appropriately.  For example, an object at Z 10 and Z 10 will collide but objects at Z 10 and Z 50 will not.  I have no rhyme or reason why the objects cannot drive in the Z direction.

Another problem I ran into was way back when I first created my springs and bungees I had a weird bug where they would always gravitate around the origin of my world (0,0,0) I never really questioned it and moved on because I had bigger fish to fry, but now that I tried to make a world full of these objects I ran into some obvious problems. Upon placing spring objects anywhere in the world too far away from 0,0,0 via my level editor when the game runs they will fly back at max speed toward 0,0,0 destroying and knocking away everything in their wake.  I have narrowed this down to a bug in my spring force code which somewhere some how chose a fixed point of 0,0,0 to be bound to.

These bugs made a full world quite impossible to create which is why I made a few sets of levels which allowed to show off each part working on its own and still giving the player a decent feel of progression and what type of interactions they would expect to encounter in a Mass Aggregate world.

Capstone: Trying to polish

This week we finally came to the realization how much more work our levels need. There are too many, a lot of them are very clunky and break the flow that VXT players crave. And they art order is too much for our artists to fill.  So this week I played not the role I am but the role the team needed. Most of my work was on the design and QA front.

We realized that only Brian actually knew how to make a VXT level that captured that sense of speed, and he did it fairly well 4 times in a row. So as a novice player with many ideas about our game I've been working along side him, to run through our levels find the hard breaking points like the 90 degree angles, or poor choice of phase wall useage, and remove, edit, and remake them.  We've decided to cut down from 16 level to about 8 which means a lot has to go and a lot has to change.

I wrote up a detailed list of all things in all levels that I thought were good and bad, this way we can start grabbing the good parts our designers made and start to string them together to hopefully make 8 refreshing and smooth levels very quickly and with input from all 4 main designers and myself .

 I was able to help debug some object that weren't working correctly due to programming issues but mostly I was there to brainstorm and I feel like this is really helping the game as a whole. We needed this hands on feedback and tweaking from the beginning, there is a rough 10 days ahead of us and we're going to give it all we got to make it right.

It's taco time to the max.

Capstone more

The weeks just seem to be melding together.  We're making progress but not as much are we need to, at least in the art department.  We apparently have 100+ assets but we have yet to see about a half dozen in game.  Things really need to start coming together or I fear the worst.

But that isn't fully my worry, I'm busy with programming.  And while on the art department we did end up getting in a few animations for the character which start to make the game feel more alive.  We have an animation as the games starts, an animation for going between 100-200 speed and an animation for going anything above that.  We ran into a lot of trouble scripting the animations together.  Things like scaling the animation correctly from maya to unity,  fixing rotations on parts of the wheel that shouldn't be moving while we are rolling, and actually getting part of the model to shrink and re appear.  This all had to do with parent child interaction issues in unities hierarchy.  But luckily they are worked out and made it into the game.  The mid speed animation does need some work, testers had a very hard time noticing it, but this brings up the question can we afford to make a second pass on them when we still have so much art demand as it is? This weeks friday meeting was suppose to solve that for us but neither of our artists could make it.

Our menu system got another large change giving our level select a carousel effect to allow pictures to visually represent the levels so people can see what they are getting themselves into, we are hoping to get that carousel animated however at the moment we aren't sure if the art pipeline can handle another request like this.  We might just have to deal with static changes for now and hope it's good enough.

Other than that we had miscellaneous bug fixes with ghosts working correctly with our new 3 2 1 start system and some collision issues with our new wheel type objects but other then that theses were the main accomplishments on the programming side this week. Hopefully this next week gets a lot of art in, we definitely need it, as time is running out.

Capstone Alpha

This week was all about getting our game ready for the alpha stage. On the programming front this was filled with many backlog bugs and some last minute features based on QA feedback. Some example of what we accomplished this week are as followed.

Slipstreams are finally getting fully tested, which means many, many bugs are emerging. As such we had problems with players losing gravity when prematurely exiting the slipstream. Players flying out of the slipstream at wrong angles. And just overall stability of staying in the slip. All of these bugs have been “fixed” for now; we’ll see what happens next round of testing.

We decided to add a Slow Motion effect to the gameplay. One of our biggest concerns is giving the player enough time to react to the sudden puzzle elements they encounter after going so fast leading up to them. We added a new way to spend energy to enter a slow motion mode where the world and timer slows down so the player has more time to react the thing around him as long as his energy holds out. We made this effect much smoother and hopefully is another answer to our feedback problem.

On the same front as the Slow Motion effect we added a Early Warning system, this little pop up is to notify players when colored walls were approaching so they knew to prepare themselves for quick reactions, this was once again to help give the players more feedback of the quickly approaching changes in level.

Our game also got a new starting sequence. Up until this point when a player selected a level, it just went. We now added a 3 2 1 start system to allow the player to get ready for the game to start so they can be as prepared as possible for the level to help shave off a few seconds of time.

Air control has been always been a battle while making VXT. We don't want to give too much otherwise they will feel too floaty and lose the sense of a being a heavy metal machine. However it's a big request from testing feedback, we had slight control but we added more to it. It allows more control up to specific speeds we’ll see how testing goes and change accordingly.

Outside of gameplay things,Our menu system got another work over making it more dynamic allowing us to nest levels in groups instead of just having them all in a very long list. Which is just nice for further expansion.

Besides this our actual alpha presentation left much to be desired, we got hammered simple as that, it was a painful experiences as each and everything we presented was wrong, especially the feedback on the design of our levels and on the fundamentals of VXT. There was a lot of criticism some good some bad, but at this point we don't know if it's too late. Grim days seem to be ahead but we shall try our best to make up for it.




Things don't look good,

-Ian 

Capstone: Towards Alpha

After a very "restful" spring break we returned to work with a lot on our plate and not very much time to complete it.  Alpha is exactly Five days from the date of this blog post and we have a few missing holes that will need filling.  First and foremost we really needed to do some fixing on how quickly our player is exposed to challenges and changes in the level. When moving as fast as we were, when a sudden colored wall appeared or some other obstacles players very often did not have time to react.  We have been making small changes to the camera to help increase vision, and moving the camera to the side to give more of the screen for up coming obstacles, and while this helped testers still wanted more.

One thing they we implemented this week was making a speed cap for the player. While our game is all about speed, everything should be done in moderation, there is point when going too fast is detrimental.  This helps us regulate how fast contact will actually reach the player screen.  Hopefully this helps players feel like they have more control at "top speeds" and have more time to react to the incoming terrain.

Next we have two more advanced solutions to the upcoming walls problem, first is another way to spend our collectibles, currently when you pick up orbs you can activate a short speed boost which drains energy to help make up for mistakes or reach greater speed quickly.  This is almost the exact opposite of that, instead of using the boost to move faster, click the bumper button will enter the player into a matrix slow mode time scenario , where time literally slows down around them. This way a player can give themselves more time to react to upcoming obstacles while not taking a time hit.  This will allow for an extra level of advance game play and another choice for the player of how to spend that energy they are collecting.

Our other solution which we will be taking with slow-mo mode to an AB testing session is a sort of heads up alert.  This will have glowing edges on the screen to represent when a active wall is coming up, this way players can prepare if there is a wall above below them or right in front of them shortly.  It gives the player the warning without having to pull back the camera any more and from as far back or as close as we would like it to be.

Hopefully these changes will make VXT even more accessible to players, testing this weekend will tell.


Time to sprint towards alpha!

-Ian

Capstone Midterm Review

This week was all about midterm and preparing for break. Not much additional programming was done due to the fact that we just finished our sprint towards midterm and GMGF.

 We did have two substantial contributions to moving our game forward outside of bug fixes. The new player model has finally been finished and as such we had to implement the new player into the existing levels and swap out the old one.   The layout of the player changed drastically so the way our scripts communicated between the shield and the actual player had to be modified to compensate.  We also had to re hook up all the visual effects and scale colliders so that this new player felt exactly like the old, just looking much cooler.

 Other than that, VXT being a game all about high scores we made changes to our high score screen online allowing for more attractively viewable content. The highscores from green mountain games fest has been immortalized on our website in a much nicer and more dynamic layout then before.

We also planned on moving forward.  The following week is our "spring break" which is code word for time you get to work on all of your projects while not having to go to class.  We have a lot of levels that need to be made and the plan is to bust out a 5 more over the course of our break. This will inevitably come with bug fixes, polish and graphics programming to make these levels really pop.

More the the programming front, after seeing what happened during Green Mountain Games Fest, and knowing that those computer will be what we are programming on, we will need to make heavy advances to optimizing our game so that it can run at top efficiency for the senior show.

Capstone Green Mountain Game Fest

Green Mountain Game Festival is an event created by students are located with in Champlain college to show off independent game development in the Northeast many games will be on display with a handful of developers from outside of the Vermont area attending as well.  This event goes down this Saturday which is why this last week as all about getting ourselves ready to present VXT at this event.

    To do so we need to make our first draft level much better,  after a few rounds of testing we had a list of changes to our major mechanics to make them much more user friendly and enjoyable.  Some examples for thing that changed are as followed

Boost Mechanic - We changed the controls around so that the left trigger is now what activates the boost, we change it so it requires more collectibles to gain speed, and most importantly made it so you can aim the direction of the boost instead of just increasing your current velocity by a magnitude.  You can aim the direction by now pointing your shield in the direction you are going.

Slip Stream - We fixed a lot of the preform bugs due to physic being applied to every spawned particle. We changed how the player moved from setting position to applying forces to our player to make much smoother movement. Finally we allow the player to keep the massive velocity they gain while going through the slipstream allowing them to be propelled out of the end of it reaching amazing speeds, making it so satisfying to use.

Moving Platforms- Moving platforms allow players to have more dynamic obstacles however getting the timing right so that the platform was where it needed to be when the player arrived wasn't working out.  So to fix that problem as well as putting more emphasis into the use of our shield, we made it so the platforms lay dormant and carry a color then when a player touches the moving platform it will active starting the movement, this way the platform only moves if the player is there.

Besides tweaks to these mechanics in order to prepare for Green Mountain Games we needed to make sure our game could play as if inside a kiosk.  We revamped our  menu system allowing quick and easy additions of levels to make expansion easier.  We fixed pausing and restarting of levels so that player quickly swapping out wont have a problems starting and new. And most importantly in the spirit of competition (which our game thrives on) we made out global online high scores dynamic per level name and this way anyone who plays our game on Saturday and preforms well will be immortalized forever on the online high scores of the VXT Green Mountain Games levels high scores at themidnightacos.com

This Friday we are jamming out to get the most we can get done before the event. Wish us luck as midterms are right around the corner.

Until next time!

-Ian

REST Calls, caching, and threading on Android

Recently I was granted access to Riot Games API allowing me to finally create a League of Legends app.  I've had a decent amount of experience of making basic applications Android applications such as my most recent release for Blizzards new game Hearthstone found here.  However this app would require much more advance skills then I have done in a java android environment.  For this project I needed to figure out how to accomplish what I stated in the title Rest calls,  caching, and threading! So after doing the leg work I present to you how to effectively  thread your app, make a rest call, and cache that call for later use.

The first step in this process is making and using a thread.  Threading in java and android is actually quite trivial but very important, if you don't use threads on asynchronous task such as making REST calls to a database then your app will lock up while it waits for an answer to your request. This way the user call still interact with the phone, use the UI or cancel the request, all without having to wait or thinking the app has gone unresponsive and force closing.   Threads are their own virtual class, so all you need to do is create a new thread and implement the run method as show below.

new Thread(){
    public void run()
    {
                       //I'll make a rest call from here so I lock up my UI!
                }
   
}.start();


The .start(); at the end of the new Thread creation is telling android to start doing what is in the run method once you reach this line of code.  Alternatively if you don't want to run the thread from within a method or would like to set it up, call it later or call it multiple times you could do the following.

Thread restThread = new Thread()
{
                public void run()
     {
                       //I'll make a rest call from here so I lock up my UI!
                }
}

void main()
{
      restThread.start();  // this will start the thread whenever whereever as many times as you want
}

Once our thread is started we can safely make our REST call without locking down the program. Making a rest call from java is also just a matter of a few steps.  We need to create an inputstream for our program to get return data from once the connection is made. We then try to open up a HttpURLConnection and set our request method in this case this is a GET method,  and any other header information we may need. We check the response code to make sure the connection worked. Then we make a character array large enough to hold all the data we get back from our server and start to read the data from the input string into our char array.  Just like that we made a set up a connection, requested data, and took data into our program.

IMPORTANT:  You must have the follow permission in your manifest file in order to have access to the internet and make these calls.  <uses-permission android:name="android.permission.INTERNET" />

InputStream  input = null;

try{
     URL url = new URL(www.databaseWeWannaCall.com);
     HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection();

     if(!(httpConnection instanceof HttpURLConnection))
      {
           throw new IOException ("this url is not a http url");
      }

       httpConnection.connect();
       int responseCode == httpConnection.getResponseCode();

       if(responseCode == HttpURLConnection.HTTP_OK)
      {
          input = httpConnection.getInputStream();
       }
}
catch(MalformedURLException e)
{
e.printStackTrace();
}
catch (IOException e) {
       e.printStackTrace();
}

try
{
    InputStreamReader inputReader = new InputStreamRead(input);

    int charRead;
    String ResponseText = "";
 
    char[] inputBuffer = new char[Size of data pulling down]  //if you dont know the size just make it a very                                                                    //large number it isn't efficient but it will get the job done for now.

    while((charRead = inputReader.read(inputBuffer))>0)
    {
           String readString = String.copyValueOf(inputBuffer,0,charRead);

            ResponseText += readString;
            inputBuffer = new char [Size of data pulling down];
     }
      input.close();
}

Just like that we now have a string called ResponseText filled with all the data we queried from the server.  Now that we have this data we still have a slight problem because the data is in our new thread we created, our next challenge is getting the data out of the thread and back to the main activity.  We do this by using a message system.   To do this we first set up our message handler, this is where when we send the message the data will be accessed inside our main activity.

 private Handler myHandler = new Handler() {
       
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
                 //do stuff with our data
          }
    };

Making a new Handler() requires us to implement the method void handelMessage(Message)  this method is called when a Message is broadcasted to the program.  But how do we send a message, as well as data with it?

Message msg = Message.obtain();

Bundle responseBundle = new Bundle();
responseBundle.putString("Response", ResponseText);
msg.setData(responseBundle);
myHandler.sendMessage(msg);

First we create our message object using the .obtain method. We then need to change our data from a string to a format that a message can send.  Java has a Bundle class which will do just that for us.  a bundle is basically just as it's called a bundle of information, it holds data along with a key to be accessed later much like a dictionary.  We take the bundle put our string into it and send the message to myHandler.

Taking the data back out of the bundle is trivial just add this one line of code into the myHandler. This takes the data from the message in the bundle with the key "Response which we set up earlier when packaging the message.

msg.getData().getString("Response"));

We that we have a full rest call system set up with threading we can worry about caching the responses we get.  Caching is a very important to do especially on the android environment we don't want to make our user make extra calls to the database especially when not on wifi.  There is a built in caching solution in the URL class which is very hands off, it supposedly takes care of everything for you and gives you very little access.  Because of this i chose to run with my own implementation of caching which is actually quite simple. All you need to do is write the data to a file and before you make a call to the database check to see if you  have data in that file and when's the last time you made that call and saved the data.  If the data is constantly changing  you want to make sure that they data will be refreshed periodically so that your first cache doesn't stay around forever.

I check the time by using javas built in Calendar class.

Calendar myCalnder = Calendar.getInstance();

gets a object that holds year month day hour minute seconds in a clean way.  I just update the calendar each time I'm about to make a call and compare it to the caches calendar. If more than the time i've wanted the cache to last has passed I make my REST call otherwise I use the cache file.

Another good thing to do is add a way for the player to clear our the cache and force a updated REST call.   One thing I did in my implementation and would also recommend in a mobile environment would be to make sure, if you have cache and it's supposed to be updated, if the user is not connected to wifi don't update the cache wait until they have wifi and then let it happen.  This way the user is angry that your app is using up all of their data plan.

You can check to see if the user is connected to wifi by doing the following call

 if ( NetworkConnected())
{
    //make the rest call
}
else
{
    InputStream input =  openFileInput(My_Cache_File);
}

you also must have the following permissions in your manifest file
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

That's pretty much all you need to know in order to get your own REST calls threading and caching working within and android environment, it's a very powerful tool and will open up endless possibilities for your app development.

I wish you all luck, and until next time, thanks for reading.

-Ian Percoco

Capstone: Midterms in sight.

This past week was quite a busy one for our Senior Production team. We were a little worried about our current progress and we really need to get down due some work and get it tested. We had a large work meeting last Sunday where we started creating four levels and the mechanics they each would introduce.  We ended the day with four white boxed levels and four iterations of mechanics.

The mechanics that we got working were the shatter mechanic in which when the player collides with this objects with the correct shield out they will shatter the object and continuing moving.  If they don't use the right shield it will slow them down.  We're taking this to testing to hopes to find out if the speed reduction is too much and if we actually want the player to use any shield color or match the correct color.

 Falling platforms were the next basic mechanic that we finished right now we are trying to find out if it is too punishing because they start to fall very fast, and if how they just kinda disappeared is acceptable or if they want them to still be intractable when they fall.

  Boost mechanic was also worked on which gives a reason for players to grab collectables.  With the collectables they will be able to use quickly boost to max speed to in which ever direction they are currently moving.  We want to know if players would rather have to send you in the direction of your shield or not.  

Finally we took our second stab at the slipstream.  Slipstream has brought us many problems in the past whether it be due to frame rate,  ability for the player to stay in the slip, ability for the player to come out of the slip cleanly.  I do believe we have fixed all three problems but we need players using them without knowing what used to happen to see if they can break it or if it works good enough.  

In other interesting news via our twitter @TMTgames we were contacted by Infinite Respawn  a game blogging site that has their own podcast, has ask to interview us about our development process our plans and what the game is going turn into.  Which was quite exciting for us and we will most likely pursue.  Time is moving quickly and we have to pick up the pace to match it.  With green mountain gaming and mid terms right around the corner we have a lot of iterations to do.


It's going to be an interesting ride,

Capstone: Always More

This week as not as productive on my end as I hoped, and this morning I felt the consequences of my actions.  The past 7 days have been filled with physics, operating system, ASP.net , Android programming, as well as trying to meet a deadline at my job.  Something had to take a hit and sadly this week it was capstone.  I only got to put in a few hours,  most of which I will be making up for Sunday at our weekly work till you drop meeting.  However few it was, it was rather productive.

One of the major requests from my designers is to make what they are calling the slipstream.  The slipstream is a series of nodes that once places will generate particles between them.  The player when making contact with this particles with the correct color shield will be dragging allow in the direction of the facing shield.  This will allow our players to take a break from the action while still traveling at high speed.  It's also perfect for making controlled direction choices.

The funny thing about this feature is while I stated above that it was planned to make you move in the direction of the facing shield, that only happened due to accidental functionality emergence in the way I created the feature.  The slipstream works by when the player collides with one of the particles with their shield out and on they hook onto it and the player changes his position to the particle he is colliding with.  However due to how close together the particles are the player does not ride along with a particle but keeps jumping to the next one.  This means that depending on the way the player faced their shield they could control the way in which they went.  This let itself to some really interesting gameplay due to the fact that we can now set up choice gates where the player can decided to get off early, follow, another path, or go back the way they came all from within the slipstream.  It makes it a decision based rest section rather than a free ride.

The currently implementation still has some bugs and smoothing to be fully functional and ready to be given to the designers but it is definitely a step in the right direction and quite an interesting discovery that only adds to the possibilities of slip streams which I could quickly see becoming a testers favorite in the upcoming weeks. Slip streams should hopefully be hitting the QA labs this Tuesday so if you wanna try them yourself  come on down , testing starts at 6:30.

That's all for this week,

-Ian

Game Physics: To Scale Solar System in Open-Gl

    Space,  the final frontier,  these are the voyages of programmer Ian Percoco. In this blog I will cover the adventures, methods, successes, and failure while creating a life sized scale version of our Solar System. This was not an easy task and put a lot of my programming and math knowledge to the challenge.

    When I stated life sized, I really meant life sized,  the first part of this process was to find a unit of measurement that my solar system to live in.  I needed to figure out what to use for distance, mass, and radius.  Seems simple right? Just use like the metric standard or something, I mean we get to do all of our massive calculations on a computer, it should be no problem!  Wrong!  Using a type of unit that is too small or too large literally makes the significant digits used in the math, too many for floats or even doubles to hold.  So after a lot of calculations and making a small spread sheet I came to the conclusion I would use Megameters (1000000 meters) and Yottagrams (1.0x10^24 grams) This way the computer can actually preform the calculations needed to make our solar system move.   

    After deciding on units the challenge of making the planets actually move begins.  I set up what is known as a force registry system.  The force registry system takes the job of applying forces out of the hands of my planets and into the Registry.  Basically I make a force registry system that holds a list of forces.  The planets get linked up to the forces and then added to the registry.  When update physics is called the registry loops through and applies force upon the planets based on in this main case the gravitational pull of one planet onto another and the amount of time that has passed since the last call.  The planet takes this updated force and applies it to its velocity and then updates the position, clears out the force and waits for the next force update. This way the planets don't have to keep track of one another or calculate distance or even the total gravitational force (gravitationalConstant * mM/distance^2)

    And just like that I had movement,  I kept adding planets setting up forces and they just started to move around as expected. The hardest part was getting earths moon to keep up with earth but all that really needed to happen was have the moon be affected by both the earth and the sun as well as changing the moons initial velocity to match that of the earths + it's own.  It doesn't make the most stable orbit for long but it does work.   

  Now that I could see individually this planets moving, there was no way I would be able to get objects so far apart and at such varying sizes to appear on the screen.  So I needed to implement a distance scaling basically saying if a planet such as Neptune is too far away to be drawn,  bump up the scale a little bit to allow us to actually see it. This way we can actually see the orbits as shown above.

  From there the project was a lot of camera fixing, adding debug text, free form camera rotation and such all on this massive scale which surprisingly was one of the hardest parts (excluding finding the right units). My debug text still doesn't work right due to the changing angle of the camera but It suits me just fine right now as a proof of concept.   

Capstone: Green Light and Beyond

    This week consisted of our Green light presentation.  This presentation was to make sure we have all of our priorities in order, a well thought out and documented plan of how to complete this project, and a solid foundation to build a upon.

    VXT has had an overarching problem of being too much the famous Sonic the Hedgehog, the main point of the game is to go right, very very quickly.  So we really need to work on defining how different we are from  the blue blur himself.  We came to the conclusion we had to encourage and put much more  emphasis on our shield interactions.  Our shield and it's interactions with the world we put it in is what really can help define our game as its own.

    Our designers have come up with quite a few new interactions that me and Mike will be working on over the coming weeks.  Below I have listed the feature and what exactly it aims to do.

    Boost Mechanic- We have collectibles in our game that do nothing aside from add points and help you complete challenge modes. They feel very empty and artificial just being used like this, there's no real purpose besides arbitrary numbers.  So we decided to add a game play goal onto them, as you collect them, a bar fills up,  upon pressing a button you will gain a speed boost that rapidly depletes the bar, this will allow our players who are skillful at collecting these orbs to be rewarded by allowing them to use this speed boost to either recover from a mistake and achieve a better time.

    Break Mechanic- Our players have no real hazards to avoid, the real challenge comes from ones own reaction time to the quickly passing environment.  Our idea is to add objects that block the players path, these objects it collided with will shatter into pieces making a really cool looking particle effect to make the player feel good about smashing through things with great speed.  Game play wise if the player is either not going fast enough, or does not have his shield facing towards this object, upon breaking it they will have a loss of speed.  On the contrary if they are about a speed threshold and have the right shield facing towards it they will satisfyingly smash through it and continue on as planned.

    SlipStreams-  VXT is a very fast and intense game, there is very little time when playing through a level for the player to relax and catch their breath.  Our idea is to add a way from the players to keep up the speed, still have really cool traversal of the level but get a breather.  We decided to create a node based system in which energy will flow from one to the next,  If the player collides with this energy using the correct shield color they will be sucked into the flow and follow along it at high speeds.  This allows the player to continue working towards the goal of reaching the end but allowing them a second to rest before having to make split second decisions again.

   From a technical standpoint I am most excited about this feature has our way of implementing this dynamic flowing energy source will come from the use of our own custom made particle system, which will not only allow for this to look, move, and feel amazing, but open up other avenues where it could be used to really enhance the overall game.

    For now these are the 3 main mechanics being added to the game to go through testing, there are a few others still in the concept stage but after seeing how these 3 play our with our tester we will make a decision if we should attempt others or refine these.

 Overall it was a good week, we've been Green lit and production can officially begin!

Capstone: Another Week Another Post

This week current progress in continuing ahead as planned. For my part working on the level editor has continued on the side.  The piece you want to build with can be selected from a pop up menu by pressing the Y button.  The piece can then be moved around and placed snapping to a correct location.  You can then pick the object back up, spawn another, or delete it.  After having the player have full 360 degree control I also decided to limit the builders movement and rotation, we are a 2.5D, so there is no need to allow the player to move in the z direction, it just causes confusion.  Camera controls will still need to be work on within the editor but for now it's fine.  I'm much more focused on making sure builders can't play multiple objects on top of one another, and visual feedback for where the piece will be placed.

Outside of the level editor getting or games controls to work on anything but Pc and Xbox have become an inherent problems especially since our professor has a mac leaving him unable to see, play, and get a better feel for our game.  So it made the perfect excuse for me to go ahead and implement a input wrapper for unity. As of a few days ago I have a class that will allow input to be completely separate from out game , this means that as long as we set it up our game can and will run on any platform Mac, Linux, OUYA, Android, you name it and we can make VXT work with it, all without changing any code.

In other news it looks like the designers are starting to come up with other features and task for me to work on.  I was told I would receive a priority and specification list within a day or two, I can't wait to see what they have come up with to make our game even better. Either way it's time to get back to work.

-Ian

Senior Production - Full Steam Ahead!

This marked the first full week of our team working together on VXT.  After cleaning up all the loose ends from last semester and getting out teammates up to speed we were ready to dive in headfirst.  We joined together as a group, sat down within our respective division and worked out what we need to accomplish.  With our core gameplay in our minds very solid, we picture this semester more focused on reach features and polish, our game is fast and simple we'd like to keep it that way.  On the designer front, the have decided to create 4 zones of level each containing 4 levels and introducing a new mechanic in each.  As far as I remember (but this is all subject to change)  The first zone is a factory type setting in which the player will get accustomed to the controls and shields.  The second zone is a city where players will have to navigate through our railgun structures which brings the player to top speeds.  Next the player will go down into the cavern where they will be met with moving platforms and speed pads.  They will then move to mines where they encounter the phase walls surrounded by the unstable energy.  We see this is a nice progression of basic mechanics, scenery, and VERY subtle story for players to interpret in their own ways.  With the main amount of work on this front for the artists to make the environments and the designers to create the levels  with the tools already available to them from last semester.  Mike and I will be able to focus on our reach features. Mike will be progressing on our web presences and account system, while I look into our in game level creator for players.  Knowing how large of a task this is I have already hit the ground running on this task.  After a nice long thursday of programming I have a basic creator controller which allows the player to navigate around the space.  The ability for the creator character to spawn objects, move objects, place objects, delete objects, and re-pick objects that they have places down.  With this base functionality in place hopefully within the next week or so we will have something we can bring to testing.  I've already taken the liberty of speaking with the artists letting them know that all future models will need to be very modular to allow the pieces to line up nicely and allow easy creation for our players.   Overall I'm very happy with the current team progression and overall state of cooperation.  I'm excited in seeing what we will end up making over the next 15 weeks.

Till next time

-Ian  

Senior Production-A new team joins

This is the first week after winter break and we are about to start the final 15 weeks of our senior project.  We made the cut last semester and welcomed 5 new members into our team.  1 programmer 1 artiest and 3 designers.   With this new combined force, and fresh minds on the project I think we can make VXT into an amazing game.  This week started with cleaning up the repository and getting the new team members up to speed with our documentation but that's about it.  Stay tuned to see our progression over the following weeks as I will be required to post once a week by Friday at midnight.  Wish us luck!