Capstone 6 A ray of hope

As I spoke briefly about in my last blog post we decided to make a radical change to the direction of our game in a last ditch effort to get something more presentable, fun, innovative, and simple to even have a chance to move forward.  We liked the idea of opposing forces attracting and repelling, we didn't like how bogged down and sluggish the game felt to not only watch but play.  We decided to make this game much, much faster.  And drop 85% of the mechanics/controls.  You are still a generator wheel...thing  the story behind which is still being worked on but now there are only 3 main controls.  left in right on the right control stick moves the character while the right control stick aims a polarized semi circle shield and right trigger changes that polarity.  The idea is similar, you have to navigate the space to the end of the level while avoid obstacles and using the environment to your advantage.  At a much higher speed and with more fluid interactions.  You can now climb on walls and ceilings if the walls are polarized and you aim your shield of opposite polarized towards it. There are speed boost that if you hit with the same polarity will send you flying in a specific direction to help you get places faster or over objects.  There will be projectiles that hone in on you that you can reflect by using your polarity shield of same color.

Overall the game is much more simple, fast paced, fluid and fun. Which is exactly what we were hoping for from the beginning.  We can only hope we figured this out with enough time to spare in order to continue to move forward. Only time can tell.  Wish us luck.

Capstone Innovation

We were recently assigned a group project to choose a game that we found innovative and write about how it accomplished these tasks.  Our group chose the game Journey on the PlayStation 3.  While I myself has never played it (who has time to play games now a-days)  I did a little research on it and it did some pretty amazing things for being a small project. Which I can say without a doubt inspired my team.  Journey had one goal, to tell a story.  It accomplished this feat without using any words/dialog and having players who do not know each other work together to accomplish tasks with the same constraints in place.  Journey fed of the psychological aspect of humans to create a powerful and lasting game, which immerses the player and captivates them to continue forward.  The world of Journey is a desert wasteland. While beautiful very lonely.  Journey uses a seamless player drop in/our system where after playing alone for hours you might run into another player online somewhere.  You don't know that person and you cant communicate with them  and unlock other massively Multiplayer games. Instead of trying to avoid this other player due to the emptiness of the world you feel drawn to them.  The game itself is also very simple.  It's like 3 buttons at most.  The game delivers a fun, captivating, and simple product.  This allows the game to reach a much larger audience.  This is exactly what our game is missing and is why after completing this assignment we took a 180° turn when it comes to the direction of our game.

Our game was way too complicated.  We had more controls then we knew what to do with.  It was artificially difficult due to the interactions with the world and controls.  The learning curve was through the roof and if we even wanted a chance to move forward we needed radical change.  Which is exactly what we did and what I will go over in my next blog post. See you there.

Capstone 5

Well, we challenged this week. I felt like it went horribly.  The prototype was messy. Our pretension ran too long.  Our mechanics are super over complicated and as Gilly and Evan attempted to demonstrate our prototype it became painfully obvious.  After attempting to sell our train wreck of a game we had a large meeting about how we were all on different pages. Chris pictured this game as a fast pace racer. Our designers looked at it more as a puzzler and I just wanted it to work better.  We decided to have a meeting at Chris's house for him to show us some games he thought we should be more like.  After watching them play a large variety of games that I can't remember the names of we stated that we were all on the same page and went back to work.  We somehow pasted stage one and started working on market research for stage two. Which for me meant just try to make the game work better while they worry about target demographic and so on.  Even with this "new" understanding our game was still very clunky people were very focused on story and there was still no fun game play to be had. We have a meeting about new innovation next week hopefully that will put us back on the right track because it's looking to be too late at this point.

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.

TCP or UDP with networked games!

     With the goal of making a networked game over the coming semester the of the first major options to look at and consider is what type of protocol to use when making connections between clients.  After a little research looking specifically at the fast paced action title for the Xbox, Halo. Halo as well as most if not all other high paced shooters use UDP in order to set packets to their clients. This way the clients can listen on specific ports or any/all information that comes its way, while UDP can keep spitting out packets of information to the users which will receive them hopefully in order but not guaranteed. TCP on the other hand needs a secure connection and demands order, high paced games would lag as they waited and waited for all of the necessary packets to get to their destination.  So while data might be lost it's a much better trade off then having an unplayable game. UDP seem to be the answers,  at least for fast pace action games such as Halo.

      However  TCP still has its place world of Networked games.  It can be used in turn based games which can take the time to make sure the connection is there and all packets arrive safely.  As well as for other services in the online game itself.  League of Legends for example while using UDP for actual game play uses TCP for things like statistics, rankings, analytics, and their lobby/store client.  But when it boils down to actually game play the clear answer seems to be the UDP way or the highway.  

OpenGl Transition Effects with the Stencil Buffer

Swapping between objects or even entire 3D scenes is something that graphics programmers will always have to deal with.  Deciding exactly how to accomplish such a task leaves room for innovation from not only a visual standpoint but a technical one as well.  Screen fades, wipes, and dissolve effects are all common forms of transitions used in graphical programming.  For this project I chose to recreate a dissolve effect and wipe transition in C++ OpenGL using the Stencil Buffer to control it.

                

The Stencil Buffer is an interesting tool that most modern graphics hardware takes advantage of, it opens the door to a wide variety of effects like the ones I chose to create as well as much more. The Stencil buffer acts very similarly like an actual stencil in real world would.  OpenGL allows us to directly interact with the Stencil Buffer manipulating how each pixel show within the effect area will be affected by it.  What this means for us is we can literally draw out a patter to be displayed through the Stencil Buffer. But how do we accomplish such a task? It is not as hard as you might think, but there are definitely a few things to make sure are turned on before you start to battle with the Stencil Buffer.

By default the Stencil Buffer is not being used so in order to start manipulating it need to enable it, by simply calling glEnable(GL_STENCIL_TEST);  now that we are using the Stencil Buffer we need to make sure to clear it out each frame otherwise it will overwrite itself.  By calling glClear(GL_STENCIL_BUFFER_BIT); we also want to turn off depth and color mask otherwise the Stencil buffer will interfere with those values when and in this case we don’t want that to happen so similarly disable them by passing in GL_FALSE to both. 

Now this is where the fun starts, We want to set up the pattern we want to be seen through the stencil buffer, so if we were doing a transition the first frame would basically be empty, but as the transition progressed more and more of the screens design would be drawn until the other object is fully visible and the first one is gone.  We do this by setting the stencil buffer to always fail everywhere we draw a pixel.  We then draw whatever pattern we want displayed through the stencil buffer.  An example would be in a shooter, when a bullet it’s a wall they don’t replace the entire texture on the building or even the model with one that has a bullet hole, no they use the stencil buffer and choose a few pixels on the wall to reveal the bullet hole texture through it.  We can also use this to draw interesting shapes and patters like spirals or zig zags.  Once we are satisfied with the pattern we drawn either by pixel using something like glDrawPixels() or possibly a whole object (to make a star shape or something drawing as you would with any other model) we then turn off writing to the stencil buffer.  We now set the stencil buffer to pass wherever it did not previously fail as well as turning back on our depth and color masks so our display objects are drawn correctly.  We now draw our first object, the one we want to be displayed everywhere the stencil pattern isn’t.  Once that image has been drawn we set the stencil buffer to only draw where the it previously failed meaning the second object will only appear where the stencil pattern was drawn.

 The image below is a perfect example of what we are trying to do.  The 1’s are where the stencil buffer was set to fail and the blank spaces is where it passed.  When we draw the objects over one another we can see based on the value different parts of the red and green rectangles are revealed. 

Congratulations you are now using the stencil buffer from here, each frame you can change the stencil buffer pattern to allow more and more of the second object to be seen or hidden based on what you are trying to accomplish. Those are the basics of how to use the stencil buffer to switch between, see through, and draw over objects in specific locations.  When creating my two effects (wipe and dissolve) I used the same basic technique but handled drawing to my stencil buffer differently.

For the wipe effect I picked a starting location in this specific example I used bottom left and slowly drew a larger and larger square expanding outwards until the stencil pattern completely covered the screen revealing the second object underneath.  I could then reverse the process to re reveal the first object.

The dissolve effect was a little bit more difficult, I had to gain access to different parts of the screen and randomly draw pixels into the stencil buffer thus causing random bits of the object to change until finally the entire screen was covered in stencil buffer pixels and the second object is revealed.  This gives the impression that the object is dissolving into the second object as you saw chunks of it slowly switch over until the new object is visible. 

Overall this process allowed me to gain a much better understanding of how the stencil buffer is used and what types of effects can be accomplished with them like I mentioned above.  It allows us to represent other objects, color, or patterns without changing textures or swapping out whole models and makes for great for screen transitions.  The Stencil Buffer is a powerful tool which I will definitely be using more of, and I hope you will too.

References:
1.       Advanced Graphics Programming Using OpenGL By Tom McRynolds, David Blyth (Pages 196-199)

Used for basic tutorial of how to use a Stencil Buffer.

2.       http://www.opengl.org/sdk/docs/man2/xhtml/glDrawPixels.xml

How to use glDrawPixels.

3.       http://www.opengl.org/sdk/docs/man2/xhtml/glRasterPos.xml

How to use glRasterPos

4.       http://psysal.livejournal.com/67933.html

More Stencil Buffer How To.

Back to School and hit the ground running!

Ahh it feels great to not only be back at school but to be back to work!  Classes this semester look like a challenge that I can't wait to challenge.  This is my first blog post of the semester and my Intentions from this point forward I hope to do a quick overview of each class and show off what I have accomplished.  But for now since things are just starting I'll give a little overview of each class and what I have on my plate for the first week of classes!

Production II:

This will be the most creative, fun, hard, and time consuming class by far.  I've been teamed up with with 2 designers, an artist and a half with the only goal of the semester is to create a game.  We will be working in an agile production cycle most likely scrum to keep us organized and on task.  Each week  we will present to the class our current iteration and be critiqued on it so there is a lot on the line.   Our team has settled on using Unity for our project (being one of my first real attempt at making a 3D game)  and we have more ideas buzzing around in our heads then we can handle.  No spoilers yet but I'm really excited about our first project, there are a lot of seemingly hard challenges that I already have tons of Ideas on how to crack.  The most exciting part is I'll be using the techniques from AI last semester to simulate crowd behaviors, flee behaviors and chase behaviors.  It's one of the best feelings in the world to see things I learned being put to use! Expect to see a rough prototype next week!

Graphics II:

Math, math, math, and more math.  This class is going to be a struggle but one of the most beneficial ones I'm taking.  For the first half of the year I'll be working in OpenGL to create 3D graphics in C++.  My first attempt at such a thing.  The second half we will change gears and start working on DirectX  that way we will be able to experience both major ways of coding 3D graphics.  Our first assignment is to create compact disk and one other complex shape. Shouldn't be too bad just a few math equations and the computer will do the rest for me. A snapshot will be present next week. Come on Geometry don't fail me now!  

System Software Analysis and Design:  

Architecture!  Our first assignment gives the impression of a blow over class, especially since we are working in C#  however I have a hunch that this class will escalate quickly.  Our first project is to make a contact book really simple, however this class is all about following standards, good architecture,  efficient methods, and design patterns.  So this fairly simple program becomes a little more time consuming as I make sure to cross my T's and dot my I's.  Each week we will present our assignment and then the following week we will re factor them to make it better. A lot of work but by the end of the semester I'm sure my code will be looking better then ever!

Our of class Projects:

Besides class the other good news I bring is after Emailing the correct Legal Teams I've been given the green light to start on my Application!  I'm not going to share what it is just yet but I'll keep posted on any updates.  For now I'll be prototyping in Titanium, a java script based shell which promotes multi-platform production so i can hit both Android and Apple.  However if all goes well I'll end up switching from Titanium once I figure everything out!

That's all for now I gotta get to work!

See you next week!

-Ian