tag:blogger.com,1999:blog-25676926166621168302024-02-19T00:48:09.122-08:00Ian Percoco - Programming Towards The FutureIan Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-2567692616662116830.post-21463442425945807522014-04-22T20:48:00.001-07:002014-04-22T20:48:41.503-07:00Unity In Game Level Editor for VXTI 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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dwOtR0GeHZvu4-V9B7l90a0CZZxTW2RKcEAVM3vmBCgg1JUekrBpofRlR91BuReQGDqpqX-WT6WLQEQ5S5E7A' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div>
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. <br />
<div>
<br /></div>
<div>
So I with all of this in mind I set out to accomplish the follow goals:</div>
<div>
<br /></div>
<div>
1. Create a in game level editor to allow player to use a Gamepad to build a world.</div>
<div>
2. Make a dynamic menu system to allow world pieces to be easily categorized for streamlined building</div>
<div>
3. Allow the ability to save local and test the levels in game at the touch of a button.</div>
<div>
4. Give players the ability to push their levels to our server.</div>
<div>
5. Make it so other players can pull down levels from out server and play them locally.</div>
<div>
6. Save high scores and "Ghost" characters for all custom levels to enhance competitive play. </div>
<div>
<br /></div>
<div>
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.<br />
<br />
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. </div>
<div>
<br /></div>
<div>
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. </div>
<div>
<br /></div>
<div>
All six of my goals were completed and it was quite an interesting experiences that I feel good about taking the time to complete. </div>
Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com1tag:blogger.com,1999:blog-2567692616662116830.post-32902261672185346212014-04-08T10:44:00.000-07:002014-04-08T10:54:57.593-07:00Physics : Attempted Mass Aggregate Physics<div class="separator" style="clear: both; text-align: center;">
<iframe height="385" src="https://docs.google.com/file/d/0B-VmcSUU1sZbeXZJUGlqT19YMmc/preview" width="640"></iframe>
</div>
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
And finally Rods which connect two points and keep them a set distance apart from each other.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
Bungee<br />
x<br />
50<br />
y<br />
10<br />
z<br />
0<br />
radius<br />
10<br />
mass<br />
5<br />
Ball2<br />
x<br />
0<br />
y<br />
10<br />
z<br />
0<br />
radius<br />
10<br />
mass<br />
5<br />
Anchored<br />
false<br />
spring constant<br />
0.01<br />
rest<br />
100<br />
spring constant<br />
0.01<br />
rest<br />
100<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br /><br />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.<br />
<br />
<br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-8440383591607993012014-04-04T20:43:00.001-07:002014-04-04T20:43:05.667-07:00Capstone: 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. <br />
<br />
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. <br />
<br />
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 .<br />
<br />
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.<br />
<br />
It's taco time to the max.<br />
<br />
<br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-9568664774427809852014-03-28T18:42:00.001-07:002014-03-28T18:42:10.814-07:00Capstone moreThe 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. <br />
<br />
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. <br /><br />
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. <br />
<br />
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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-38465519343496951032014-03-21T20:04:00.001-07:002014-03-21T20:06:55.101-07:00Capstone Alpha<div style="border: 0px; margin-bottom: 5px; outline: 0px; padding: 0px; vertical-align: baseline;">
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
<br />
<br />
<br />
Things don't look good,<br />
<br />
<span style="background-color: black;"><span style="color: white;">-Ian </span></span></div>
Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-88315468832661250752014-03-14T12:22:00.001-07:002014-03-14T12:22:07.702-07:00Capstone: Towards AlphaAfter 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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br /><br />Hopefully these changes will make VXT even more accessible to players, testing this weekend will tell.<br />
<br />
<br />
Time to sprint towards alpha!<br />
<br />
-IanIan Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-44962825111428269462014-02-28T11:39:00.000-08:002014-02-28T11:40:42.807-08:00Capstone 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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-83136128739684907822014-02-21T15:36:00.000-08:002014-02-21T15:36:01.305-08:00Capstone Green Mountain Game FestGreen 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.<br />
<br />
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<br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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<br />
<br />
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.<br />
<br />
Until next time!<br />
<br />
-Ian <br />
<br />
<br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-55681466657705026962014-02-16T13:28:00.000-08:002014-02-16T13:28:17.886-08:00REST 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 <a href="https://play.google.com/store/apps/details?id=com.hearthstone.secretsnomore&hl=en">here</a>. 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. <br />
<br />
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. <br />
<br />
new Thread(){<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>public void run()<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>{<br />
//I'll make a rest call from here so I lock up my UI!<br />
}<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span><br />
}.start();<br />
<br />
<br />
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.<br />
<br />
Thread restThread = new Thread()<br />
{<br />
public void run()<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>{<br />
//I'll make a rest call from here so I lock up my UI!<br />
}<br />
}<br />
<br />
void main()<br />
{<br />
restThread.start(); // this will start the thread whenever whereever as many times as you want<br />
}<br />
<br />
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.<br />
<br />
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" /><br />
<br />
InputStream input = null;<br />
<br />
try{<br />
URL url = new URL(www.databaseWeWannaCall.com);<br />
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection();<br />
<br />
if(!(httpConnection instanceof HttpURLConnection))<br />
{<br />
throw new IOException ("this url is not a http url");<br />
}<br />
<br />
httpConnection.connect();<br />
int responseCode == httpConnection.getResponseCode();<br />
<br />
if(responseCode == HttpURLConnection.HTTP_OK)<br />
{<br />
input = httpConnection.getInputStream();<br />
}<br />
}<br />
catch(MalformedURLException e)<br />
{<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>e.printStackTrace();<br />
}<br />
catch (IOException e) {<br />
e.printStackTrace();<br />
}<br />
<br />
try<br />
{<br />
InputStreamReader inputReader = new InputStreamRead(input);<br />
<br />
int charRead;<br />
String ResponseText = "";<br />
<br />
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. <br />
<br />
while((charRead = inputReader.read(inputBuffer))>0)<br />
{<br />
String readString = String.copyValueOf(inputBuffer,0,charRead);<br />
<br />
ResponseText += readString;<br />
inputBuffer = new char [Size of data pulling down];<br />
}<br />
input.close();<br />
}<br />
<br />
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. <br />
<br />
private Handler myHandler = new Handler() {<br />
<br />
public void handleMessage(Message msg) {<br />
super.handleMessage(msg);<br />
//do stuff with our data<br />
}<br />
};<br />
<br />
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? <br />
<br />
Message msg = Message.obtain();<br />
<br />
Bundle responseBundle = new Bundle();<br />
responseBundle.putString("Response", ResponseText);<br />
msg.setData(responseBundle);<br />
myHandler.sendMessage(msg);<br />
<br />
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.<br />
<br />
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. <br />
<br />
msg.getData().getString("Response"));<br />
<br />
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. <br />
<br />
I check the time by using javas built in Calendar class.<br />
<br />
Calendar myCalnder = Calendar.getInstance();<br />
<br />
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. <br />
<br />
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. <br />
<br />
You can check to see if the user is connected to wifi by doing the following call<br />
<br />
if ( NetworkConnected()) <br />
{<br />
//make the rest call<br />
}<br />
else<br />
{<br />
InputStream input = openFileInput(My_Cache_File);<br />
}<br />
<br />
you also must have the following permissions in your manifest file<br />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/><br />
<br />
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.<br /><br />I wish you all luck, and until next time, thanks for reading.<br />
<br />
-Ian Percoco<br />
<br />
<br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-35107790572194638692014-02-14T13:09:00.006-08:002014-02-14T13:20:24.123-08:00Capstone: 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. <br />
<br />
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.<br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"> 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.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"> 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. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">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. </span><br />
<span style="font-family: inherit;"><br /></span>
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.<br />
<br />
<br />
It's going to be an interesting ride,<br />
<div>
<br /></div>
Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-40277229960506589272014-02-07T15:46:00.001-08:002014-02-07T15:46:29.521-08:00Capstone: Always MoreThis 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.<br /><br />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. <br /><br />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. <br /><br />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.<br /><br />That's all for this week,<br />
<br />
-Ian Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-84068714633617382302014-02-04T08:40:00.001-08:002014-02-04T08:40:10.087-08:00Game Physics: To Scale Solar System in Open-Gl<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
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. <br /><br /> 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. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
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)</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dyImCJRu6zc1jxlmDRMvQsBUW7kI61xJz_hFtHW4PDykWthzM52FId_fBhm4mTdzB_dzHUEMpMYNaCHOhPSLQ' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
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. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
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.<br /><br /> 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. </div>
<br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-65653337287201756392014-01-31T08:15:00.001-08:002014-01-31T08:15:12.021-08:00Capstone: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>Boost Mechanic</b>- 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. <br /><br /> <b>Break Mechanic</b>- 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.<br /><br /> <b>SlipStreams</b>- 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.<br />
<br />
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.<br />
<br />
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. <br /><br /> Overall it was a good week, we've been Green lit and production can officially begin!<br /><br />Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-62948911801915744242014-01-24T15:57:00.000-08:002014-01-24T15:57:00.102-08:00Capstone: Another Week Another PostThis 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. <br /><br />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.<br />
<br />
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.<br />
<br />
-IanIan Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-4099402717053158862014-01-17T16:51:00.002-08:002014-01-17T16:51:52.911-08:00Senior 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. <br /><br />Till next time<br /><br />-Ian Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-42536502857669684532014-01-10T18:06:00.001-08:002014-01-10T18:06:26.700-08:00Senior Production-A new team joinsThis 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!Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-1147974145850276392013-10-22T07:31:00.000-07:002013-10-22T07:31:02.609-07:00Capstone 6 A ray of hopeAs 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. <br /><br />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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-19992960038507841972013-10-22T07:16:00.001-07:002013-10-22T07:16:39.042-07:00Capstone InnovationWe 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.<br />
<br />
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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-5172337656785858932013-10-18T12:44:00.001-07:002013-10-18T12:44:46.817-07:00Capstone 5Well, 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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-25106320985371208382013-09-30T21:52:00.002-07:002013-09-30T21:54:53.561-07:00Space war Clone Jam With Melissa GillUpon 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. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://scontent-a-iad.xx.fbcdn.net/hphotos-prn2/1379684_10201650020108152_1335810793_n.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://scontent-a-iad.xx.fbcdn.net/hphotos-prn2/1379684_10201650020108152_1335810793_n.jpg" width="304" /></a></div>
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
@ John Pile I don't have fraps so ill try to add a video later<br />
<br />
<span style="background-color: white; color: #333333; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 13px; line-height: 20px;">http://prof.johnpile.com</span><br />
<a href="http://mlssagll.blogspot.com/2013/09/networking-for-games-game-jam-space-jam.html">http://mlssagll.blogspot.com/2013/09/networking-for-games-game-jam-space-jam.html</a><span style="background-color: white; color: #333333; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 13px; line-height: 20px;"><br /></span>
<span style="background-color: white; color: #333333; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 13px; line-height: 20px;"><br /></span>Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-56397944199569921072013-09-23T10:16:00.003-07:002013-10-18T12:33:53.617-07:00Capstone 4Revitalizing 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! <br />
<br />
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.<br />
<br />
Wish us luck! Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-47546106533021706812013-09-23T09:46:00.000-07:002013-09-23T09:46:18.815-07:00Capstone #3This 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.<br />
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. <br /><br /> Moving onto Magnets, I actually really enjoyed working on this. In a very short amount of time I had<br />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.<br /><br />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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-91554800330645077742013-09-10T18:40:00.003-07:002013-09-10T18:40:55.577-07:00Capstone 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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-48187308600808814942013-09-04T11:11:00.001-07:002013-09-04T11:11:04.701-07:00Senior Team Capstone #1 False StartSenior 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. <br /><br />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 <a href="http://en.wikipedia.org/wiki/Weeping_Angel">Angles</a> 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. <br /><br />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.<br /><br />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. Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0tag:blogger.com,1999:blog-2567692616662116830.post-8915831917784898662013-08-29T15:41:00.003-07:002013-08-29T15:41:36.886-07:00TCP 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.<div>
<br /></div>
<div>
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. </div>
Ian Percocohttp://www.blogger.com/profile/03616503248482224259noreply@blogger.com0