Space war Clone Jam With Melissa Gill

Upon walking into Networking class last Tuesday (9/24) I found what I would normally not expect instead of the normal present homework and listen to a lecture about bit packing or packet loss, we were split up into teams of two and ordered to create a 2-4 player version of an old 1984 game called Spacewars fully networked of course.  I teamed up with my lovely girlfriend Melissa Gill and we started on our assignment.  We initially only had until the end of class (3 hour) to complete this task but anything we did not finish in the allotted time we could finish at home during the week.

Our first major decision was to decided whose code base to start with,  after a "short" and heated debate both of us trying to find whole in the other code we settled with using Melissa because she had a more "fun" menu system.  Working in a largely different code base from my own took a little bit to get used to and  looking back I wish I spent less time arguing on which code base to use and more time learning the code and coding we wasted a good 30-45 mins of class working on this part. However once we were settled the game started to come together.  Melissa the more math oriented one worked on gravity and acceleration movement and the such.  Meanwhile I worked on our projectiles and ready system.

One of the largest road blocks Melissa and I ran into was over packing our packets.  We filled them way past capacity and was giving us reading errors on the other side.  We of course did not know this for a very long time and it took a while to hunt down the error.

Our biggest accomplishment although I did not actually assist in this part much would be our menu system/ color selection.  Players in the lobby fly into a color selection lane and unless there is only one player in a lane and game will not start.  Once the game is started they inherit the color they were standing on.

Below are links two my lovely partners blog as well as my professors who came up with this great experiece and a nice break from normal everyday class.

@ John Pile I don't have fraps so ill try to add a video later

http://prof.johnpile.com
http://mlssagll.blogspot.com/2013/09/networking-for-games-game-jam-space-jam.html

Capstone 4

Revitalizing events took place this week. I was getting really worried about how excited everyone was with big hands little objects while I was extremely nervous and worried about it on both a programming side of things and actual fun game play as well as scope!

Chris came to out meeting the other night with a new out look on magnets which all of us absolutely loved. I always envisioned magnets as a co-op platform puzzler.  Chris felt we were backing ourselves into a over-saturated genres making us compete against some really big name titles i.e Portal.  So he noticed how fun it was for people to just go really fast fly across the screen and take advantage of perfect timing to switch polarity.  With this in mind he pitched magnets to us as a racer with some fancy models to go along with it.  A racer puzzle seemed to have a lot of promise and Evan got really excited. With the tools I provided last week Evan jumped into unity and within the hour we had a rather interesting climbing speed puzzle that the player had to try to navigate to the top with.  Speed was key and after messing with it for another hour we all realized we were having a lot of fun with this.  We looked at big hands, my worries and decided to send it to the back burner and focus all of our effort into getting this to go forward and iterating on this as quickly as possible.  Evan gave me a list of new mechanics he wanted added to the game before testing and I went to work.  Giving the player the ability to increase and reduce the power of his charge field using a scroll wheel,   a mini map so our player can view the power field around him as he is hurdling towards them at high speed before it's too late,  and a very sonic esk charge up ability where you spam on key and when you stop you got to max charge for and then slowly decay over time.  I busted these out within a few hours and handed them back to Evan.  He made more levels and my next list of tasks which i hope to finish before we attempt to challenge this week.

Wish us luck!

Capstone #3

This week was quick, dirty, and messy prototyping.  We as a team met and briefly spoke about the what and whys on creating our different games Big hands little things and Magnets.  This conversation was not one I really got involved with.  I'm a programmer, designers can worry about the what and whys while I go out and do it.
       As for prototyping goes I started with week with Big hands little things our attempted phone game.  I created two "prototypes" one in Havok  and another in Unity.  At first things looked really promising, I was able to recognize the pinch gesture on the phone, compare against the rate at which the player moved their fingers and how close they were together.  Which is good because for a careful picking up game this is exactly what we would need to test against objects we are grabbing.  Further more I was able to actually pick up an object using a technique I'm proud of figuring out.  Once two fingers are on the phone I "draw" a line between the two.  Once they are "connected" (not visibly so) I find the mid point between the two and ray cast a down. If i hit a object and my fingers are close enough together then I know I am pinching above something and it should move.  This was all exciting advancing, but this is when the wall hit.  When trying to move the object I successfully pinched movement went haywire.  Here is the fundamental problem with a "3d" game being controlled on a 2d screen.  When the fingers are touching the screen the phone registers them at screen cords based on the resolution of the phone.  When trying to move them in game we have to take 300x750 for example and turn it into units of measurements in not only the the 4 main cardinal  direction (up down left right)  but forward and back as well.  Moving my pinched object around became incredibly difficult in the 4 basic directions, I had no clue how to tackle forward and back as well.  This is the wall I hit and this for the moment is where I remain.

     Moving onto Magnets, I actually really enjoyed working on this.  In a very short amount of time I had
really interesting interactions taking place. I made what I called a field object and attached to to every object in my world. I field object has the following parameters, Polarity (positive or negative)  Force (how strong the Polarity it)  When a field intersects another field they both go "Hey what polarity are you?"  and then apply their force onto one another. So If they are opposites they will both pull the other one towards it.  Or if they are both the same they will both push each other away.  With high forces in not time I found myself flying around the screen gaining large amounts of speed and enjoying myself.

Overall I think this week was a step in the right direction however will still have a lot to worry about in terms of challenging.  We'll see how the next week goes.

Capstone Blog #2 Prototyping away!

Well it's week two, school is back into full swing, I've started working at MWG again, and the homework is starting to pile up.  They days just seem to be getting shorter and shorter each day, however this is no time to complain because innovation and iteration must be completed! As the programmer I had 3 main goals for this weeks activities 1. get familiar with UDK just in case we actually go down that road, 2. Start our light game prototype in Unity 3. Mobile development research.

UDK install and set up was really straight forward I started messing with it a little bit however I quickly re evaluated my time and decided while this was useful to work on it should not be my main focus at this time.  UDK is a powerful tool but actually being able to prototype ideas in any engine at all is much more beneficial for stage one.

I quickly moved onto out light game creation of which I spend most of this sprints time working on.  It took me a little while to get back into the swing of coding with unity and playing with Unitys lights is always a pain. However within a few hours I had a first person cylinder holding a flashlight that was able to explore a darken scene.  Off in the distance an "enemy" walked back and forth.  This is where the "hard" part came, I've used ray-casting in the past.  Which is a form of hit detection, basically the computer shoots out a line from an origin point outwards until it collides with something, it then returns information on when,where ,what, and how it hit.  While this is a great but slightly complicated tool to use it didn't fully accomplish what I wanted which was to know if my flashlight was shinning on our enemy.  A flashlight is obviously not just a straight line, it's more of a cone and as such i could not use a basic ray-cast.  There were a few options I looked into which consisted on semi advance math using dot product and distance equations to calculate if the enemy is actually in front of me in a cone range and then ray casting towards it to make sure it's actually in light of sight and not blocked by a while.  However it was more work then I really wanted to commit to for a prototype and could quickly get messy.  Doing a little poking around I found what is know as a sphere-cast. Basically it's a "thick" ray-cast.  Instead of shooting a line from an origin toward a direction. It shoot out a sphere of a specific radius and return any information back to me.  Which works perfectly for what I was trying to do. As my sphere-cast travels I increase the radius of the sphere to compensate for the wide cone of the flashlight. If/when it hits my enemy I use a get component function to slow down and bring the enemy to a stop in a matter of seconds.  The exact type of reaction we were looking for.

At this point we hand our next team meeting.  I went over what I accomplished, we once again worked on trying to come up with a team name, and we had a rather long dialog about working on a mobile platform and all of the limitations that we could run into.  Scree size, real estate , engine, 3d or 2d.  A lot of ifs ands or buts all of which I am starting to uncover.

Senior Team Capstone #1 False Start

Senior year has just started and it's already in full swing, especially capstone.    Capstone for those in Champlain Colleges game majors consists of splitting up the programmers,artists, designers, and producers into teams of 4 (ideally each team has one of each).  The teams then "compete" with one another iterating on game ideas to create a final project.  There are stages along the way they each group must pass in order to move forward ultimately giving them the chance to present their idea at the senior show, avoid the team cut, and have your project be one of the few to continue onto second semester.

With that stated it is easy to see that stakes are high when it comes to getting work done.  The first capstone class period explained this who ordeal in much more detail and the task to start working on phase 1.  Phase one consists of coming up with and iterating on two different game ideas/mechanics.  My team who I have worked closely with for the past two years in both production 1 & 2, excited and ambitious as always met the very next day to start planning out ideas. Each of us pitched the few ideas we had mulling around in our heads from the summer. Evan and Gilly had been working on a survival, payload game, loosly based on the Angles from Dr. Who.  In this game there would be two teams the humans who try to carry some object from point A to point B armed with only a flash light.  The other team the angles would be trying to stop them by any means necessary.  In Dr. Who the angles could move in darkness however when light is shined upon them they start to turn to stone.  To aid them in getting around this disability some have the ability to temporarily disable lights.  At first it was a 4 player game with AI, but i brought up the programming concern that AI takes a long time to tune correctly and still wont look as polished as actual people play the game which is where the idea to make it networked multi-player came up.  Another large road block would be animation. In a game such as this animations play a very large role and Chris our artiest isn't very comfortable with animations so for the time being this is placed on the back burner.  

Our next idea that seems to have some decent amount of support behind it, is a tablet/phone based game tag line,  Big hands, little things.  You play as some sort of superhero who is just trying to survive everyday life with his super strength and freakishly large hands.  Basic things like pouring a glass of water.  Picking up paper clips all become challenges that the player using the pinch gesture on touch pads would try to overcome.  Grabbing things precisely and very carefully in order to not break/destroy the object.

With these ideas under our belt we looked like we were ready to move forward however for a few days we seemed to get sidetracked arguing on what engine to use UDK, Unity, XNA, etc. With myself being much more comfortable in  Unity having working with it and C# for a few years now as well has having a decent toolbox built up with it push for unity. Meanwhile Chris being an artist spending most of his time in UDK pushed for that.  We spent time going back and forth arguing pros and cons of both when in all honesty we don't need to worry about the final engine for quite a long time. At this stage it is all about prototype prototype prototype in which if i really want to could use Flash to do so because all of this code is going to be thrown away anyway.  It's just quick iterations to see what sticks.  If i could go back 5 day I would of spent my time differently then getting worked up over something that will not matter for weeks and weeks to come.  Either way week one is now under our belt, no time to regret only time to push forward.