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!