tag:blogger.com,1999:blog-87290891564945382652024-03-06T01:34:59.355-06:00Dias - BVU Capstone Game DevelopmentGame Development Blog about Dias, a Capstone game project by Jon Kenkel and Zach Lorenzen, two Buena Vista University computer science students.
Dias is a fully 3D, team-based, competitive multiplayer, arena platformer being developed in the Unity game engine.Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-8729089156494538265.post-59948814605283091092014-04-25T00:00:00.000-05:002014-04-25T00:00:37.698-05:00Week 19 Day 4 - Post Beta 1 Report, Preparations for Scholar's Day, and How Screwed We Are.We are getting really bad about not consistently posting to this blog...<br />
<br />
Anyways, we did make progress since the last blog post. All issues from the problem list have been solved, except for the following:<br />
<br />
<ul>
<li>Disconnecting from an unresponsive server takes too long</li>
<li>Gravity toggle stops the player's momentum from their own movement (but not momentum from pushes and abilities)</li>
<li>HUD will occasionally stutter in it's display.</li>
<ul>
<li>We know where the error is happening for this, but not how to fix it. It's a weird issue with Unity's OnGUI system.</li>
</ul>
</ul>
The player resolution select is not optimal, however it gives them the option of all their possible resolutions and full-screen. The problem comes with how they are displayed, it's just bunch of buttons with the possible resolutions. This is annoying, however Unity lacks any sort of drop-down menu, and other options involved a lot of customization for a feature that the user would only alter once or maybe twice.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjc2QAMFSOZpKgOvSykcVTsJlk8D7y1n-xbD2AHiXpH34Hd3q3hKa4Wz05yAMYojXSfMp0QnggTNOMLGLwS9JbOxD0i8AIw4XYkPfEhrkDVYyFThWUjwO7jF6987RoqWeXvIS7HrDWNByQ/s1600/resolutionselect.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjc2QAMFSOZpKgOvSykcVTsJlk8D7y1n-xbD2AHiXpH34Hd3q3hKa4Wz05yAMYojXSfMp0QnggTNOMLGLwS9JbOxD0i8AIw4XYkPfEhrkDVYyFThWUjwO7jF6987RoqWeXvIS7HrDWNByQ/s1600/resolutionselect.png" height="120" width="640" /></a></div>
<br />
When fixing the grounding issue, we had tried several methods of seeing if the player was on the ground. The first method was simply using the collider to determine if we were colliding with objects below a certain point on the collider. This was effective until we altered the shape of platforms to include a subtle slope. The collider doesn't nicely slide down this slope while moving, and will quickly alter between the touching and not-touching states when moving down. We tried to fix this by introducing a delay after the collider left the object, and if it didn't come back into collision within that time, it would actually be considered off the ground. However doing that caused another issue, the player's jump counter is reset while the player is on the ground, and about 10% of jumps would not register as properly off the ground, essentially giving them another free jump. Extending this to catch this odd case would have gotten even more complicated, so we went back to the drawing board for detecting groundedness. We created a class, called Groundable, whose job it was to determine if the object was on the ground. This class simply fires a raycast a very short distance below it's parent object, checking to see if it hit anything (other than the object itself). This method solved all of the problems described above, and is actually portable enough that we could apply it to other things, such as crates if we needed to check their groundedness.<br />
<h2>
Beta 1</h2>
The Beta 1 test went very well! Our group of users were thorough in testing all the pieces of functionality for any bugs and such issues. We received positive opinions about the game, but nothing really constructive in that regard, probably due to the younger age of the test group this time. However, we did glean some interesting pieces of information from watching them play:<br />
<ul>
<li>Inexperienced users would control the character with the arrow keys, making all the ability controls unreachable</li>
<ul>
<li>We are going to disable the arrow keys, as it only creates bad habits, and there is no way to map all the functionality of the game to keys around the arrow keys on the keyboard</li>
</ul>
<li>Ability keys at QERF was not intuitive</li>
<ul>
<li>We are going to also map the abilities to 1234 as alternatives to the QERF</li>
</ul>
<li>The blink ability made the player virtually unkillable if used correctly</li>
<ul>
<li>It was way too easy to just blink up into the air, back to safety</li>
</ul>
<li>Players could blink out of the map, killing themselves on accident</li>
<li>Aiming the cone ability was difficult for inexperienced users</li>
<li>Users complained about not being able to see the edge of map, where they will die.</li>
<ul>
<li>This could be solved by adding a colored plane to the edge of the map, however we don't know if this will actually be visible and distinguishable due to it effecting all directions. It may be simpler to just leave things the way they are</li>
</ul>
</ul>
<h2>
Scholar's Day</h2>
<div>
We prepared a poster for BVU's Scholar's Day. We will be 'presenting' the poster while other students, faculty members and such look at the work students have been doing for the year. It's some very cool stuff, and a great opportunity for us to tell the world what is going on with this crazy project. Here's a copy of our poster, for those interested:</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgT0Y3S779C_w9lYsLNRs3YjT1ihsSSRnUJHjgh75pLgELKrjokLtexZZhTlErbyCzMmTZ-4iU1BdQEIiufCNgfV6D-5fxwirehkIEXDQpSX7NGnsXm3PxKBksq4m9M5MMlVPbxaywS3nw/s1600/poster.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgT0Y3S779C_w9lYsLNRs3YjT1ihsSSRnUJHjgh75pLgELKrjokLtexZZhTlErbyCzMmTZ-4iU1BdQEIiufCNgfV6D-5fxwirehkIEXDQpSX7NGnsXm3PxKBksq4m9M5MMlVPbxaywS3nw/s1600/poster.jpg" height="584" width="640" /></a></div>
<div>
<br /></div>
<h2>
We're doomed.</h2>
<div>
So we reviewed the original schedule for Dias, that was created way back last semester:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaD1xqLwrAOOFeQdnZudmPbSkR7QoaHJP4Ufow796h13XtOlK9QYL0MBOtGjzbmFClheOhL6NIHToPMqz8Bs-yodokBSgj0pcTomHw8MuqwGlCWOMmkcoqMhXBxxdw9Y6tTR50qt1xOAc/s1600/project+Schedule.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaD1xqLwrAOOFeQdnZudmPbSkR7QoaHJP4Ufow796h13XtOlK9QYL0MBOtGjzbmFClheOhL6NIHToPMqz8Bs-yodokBSgj0pcTomHw8MuqwGlCWOMmkcoqMhXBxxdw9Y6tTR50qt1xOAc/s1600/project+Schedule.PNG" height="636" width="640" /></a></div>
<div>
<br /></div>
<div>
According to this schedule, we should be much further in our project. Namely, we should have all abilities implemented, breaking and moving platforms, a platform generation system, and a respawning system. We can safely say our goals got a bit lofty toward the end of this schedule, and we did a poor job of predicting how long it would take to solve certain issues (not to mention we added animation, which isn't even on this schedule...) and how full our schedules would be.</div>
<div>
<br /></div>
<div>
The first decision we made regarding this schedule, and the end-of-semester deadline that is swiftly approaching is to cancel the Beta 2 Test. We won't be able to implement any sweeping changes to the game and be able to test them by the time that the end of the year arrives, so we simply plan to move ahead with any changes and not have another large test.</div>
<div>
<br /></div>
<div>
We realize that there in insufficient time to complete even a fraction of these items before the semester is over, so we are going to focus on 1 or 2 items and try to complete them by the time the semester ends. The items that are the most appealing are:</div>
<div>
<ul>
<li>Add missing abilities</li>
<li>Complete work on character weight</li>
</ul>
These items are integral to the original design of the game, with players being divided into 'classes' with the ability to pick and choose abilities from other classes. We probably won't be able to complete all planned abilities (as that would nearly double the current amount), but hopefully we can complete several of the interesting ones.<br />
<br />
This has been a very constructive semester, and looking at this schedule really nails home how important it is to take into account problems that are going to occur during development when picking deadlines. We should have added sufficient padding around certain items in the original schedule, and been less eager to squeeze even more features in. The ability implementations is still surprising with how long each of them took. We easily could have spent an entire week on certain abilities, let alone 2 weeks for all 12. This is a really important concept that will definitely be taken away from this project as a whole.</div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-16454910305276078842014-03-31T23:13:00.002-05:002014-03-31T23:13:23.900-05:00Week 16 Day 1 - What we did, and what we didn't - Beta 1We just realized that it's been about 3 weeks since our last update (below the goal of at least 1 post per week). Break was a bit less productive than we had hoped, partly due to other obligations, and partly due to the difficulty of models/animations with the player characters. We were unable to finish any more abilities.<br />
<br />
We've made quite a bit of headway recently, and also uncovered more issues we didn't realize we had. The problems that are solved are crossed out below.<br />
<br />
<b>Issues we knew about:</b><br />
<li style="margin: 0px 0px 0.25em; padding: 0px;">Disconnecting from an unresponsive server takes too long</li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>HUD will occasionally crash while respawning</strike></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>Tab-score menu does not get drawn with consistency every frame</strike></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;">Gravity Toggle stops the player's momentum from their own movement (but not momentum from pushes and other abilities)</li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>Slam ability (called Gravity Increase during alpha 2) does not properly throw surrounding players into the air</strike></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>Blink ability requires that a player be standing completely still to activate</strike></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;">Detecting when a player is grounded is still inaccurate.</li>
<blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="line-height: 1.4;">Players will on rare occasions be granted an extra jump when they leave the ground (because the game thinks they are still on the ground)</span></li>
</blockquote>
<blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="line-height: 1.4;">Players will appear to not be on the ground when going down small inclines</span> </li>
</blockquote>
<li style="margin: 0px 0px 0.25em; padding: 0px;">Players can select resolutions from the Unity Game Menu that do not work with our interface</li>
<blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;">
<li style="margin: 0px 0px 0.25em; padding: 0px;"><span style="line-height: 1.4;">This options should really be moved to the settings menu</span> </li>
</blockquote>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>There is no tooltip for what all of the abilities on the Game Lobby actually do. Players are currently selecting abilities at random based on their names</strike></li>
<li style="margin: 0px 0px 0.25em; padding: 0px;"><strike>Players can't edit their options from the game lobby</strike></li>
<br /><div>
<b>Issues we found out about:</b></div>
<div>
<ul>
<li>When a client gets a kill it doesn't always get counted</li>
<li>Ground Slam will sometimes pop the caster into the air</li>
<li>Area push should really be a sphere, rather than circle around the player</li>
<li>HUD will have similar not-getting-drawn issues as the Tab-score</li>
</ul>
<b>Animations</b></div>
<div>
We were able to get a model and some basic animations in for players over break, however this took longer than expected, slowing progress on other aspects of the game. We have a different walking animation for forward, backward, and strafing left and right. There is also a single animation frame that is active while players are in the air. There are almost no options for free animations, and we had to get some raw motion-capture data off the unity store for free, and make our own animations from the motion capture data. You can see the blend of movement animations below:</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiO0X4w7qOIgp2g4p__5Ot_xKHIKDwdnzkDNTLP4eyOGRk5FVsC1O6Fdnk13iygJ3Pr2WH8z7k2MHRdGdPsYVsQdqQ8Z2Y6wx6EnnISa4qfZPKiqIbYBH9hlgAAHOGxd4O9FOTDmuf5hh4/s1600/animations.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiO0X4w7qOIgp2g4p__5Ot_xKHIKDwdnzkDNTLP4eyOGRk5FVsC1O6Fdnk13iygJ3Pr2WH8z7k2MHRdGdPsYVsQdqQ8Z2Y6wx6EnnISa4qfZPKiqIbYBH9hlgAAHOGxd4O9FOTDmuf5hh4/s1600/animations.png" height="347" width="640" /></a></div>
<div>
<br /></div>
<div>
Along the right side of the screeen, you can see the breakdown of where Unity will blend our animations. Our individual animations can be partially blended together by unity automatically, we simply have to feed in values for the x/y of the 2D blend. I set the red dot for the current mix of values at the top in the matrix, displaying the forward animation in the lower right. In the center of the screen, you can see the entire blend tree with all of the attached animations, and sliders for the variables the blend is based on.</div>
<div>
<br /></div>
<div>
<b>Player Weight</b></div>
<div>
We also added weight to the players. This currently is only effecting the movement speed of the players. We will need to do some serious tweaking to the values to get weight to properly effect abilities in the expected manner.</div>
<div>
<br /></div>
<div>
<b>Effect Handler</b></div>
<div>
We are starting to realize that there are a large number of abilities and other things that are starting to effect certain stats on each player, like their movement speed, and their weight. We are thinking of implementing an Effect Handler for each character, that would handle how long these effects last and ensuring they are properly organized and removed.</div>
<div>
<br /></div>
<div>
<b>Preparations for Beta 1</b></div>
<div>
In the final week before the Beta 1 test, we hope to add another ability or two, see if the weight can effect more than just the movement speed of players, and try to eliminate more items from the bug list from the top of this post.</div>
<div>
<br /></div>
<div>
<a href="http://bit.ly/1mt6h14">Sign up for the Beta 1 test, this Sunday!</a></div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-45153627341117691132014-03-09T22:33:00.000-05:002014-03-09T22:33:01.791-05:00Week 12 Day 7 - Known Issues, and Preparations for Beta 1The test this last weekend was very unhelpful. Mostly in the sense that we didn't get any good information from the test, due to other issues with the game. There were problems with maintaining a proper connection to the server, and the server handling users coming in and out.<br />
<br />
We are aware of a number of bugs with the system currently, and they are as follows:<br />
<ul>
<li>Disconnecting from an unresponsive server takes too long</li>
<li>HUD will occasionally crash while respawning</li>
<li>Tab-score menu does not get drawn with consistency every frame</li>
<li>Gravity Toggle stops the player's momentum from their own movement (but not momentum from pushes and other abilities)</li>
<li>Slam ability (called Gravity Increase during alpha 2) does not properly throw surrounding players into the air</li>
<li>Blink ability requires that a player be standing completely still to activate</li>
<li>Detecting when a player is grounded is still inaccurate.</li>
<ul>
<li>Players will on rare occasions be granted an extra jump when they leave the ground (because the game thinks they are still on the ground)</li>
<li>Players will appear to not be on the ground when going down small inclines</li>
</ul>
<li>Players can select resolutions from the Unity Game Menu that do not work with our interface</li>
<ul>
<li>This options should really be moved to the settings menu</li>
</ul>
<li>There is no tooltip for what all of the abilities on the Game Lobby actually do. Players are currently selecting abilities at random based on their names</li>
<li>Players can't edit their options from the game lobby</li>
</ul>
We've decided to alter the project schedule for the next test. With spring break still going on during the time we intended for Beta 1, we are now pushing it back to the weekend of April 4-6. We also are pushing back the scheduled goal for this week, due to the state of the game, and the issues listed above.<br />
<br />
The schedule for the next several weeks is:<br />
<br />
<ul>
<li>Week 13 - Check as many items out of the above list as possible</li>
<li>Week 14 - Implement more abilities, add player mass to the game</li>
<li>Week 15 (spring break) - finish implementing abilities, add platform movement, possibly add models and clean up more from the checklist above.</li>
<li>Week 16 - Polish for Beta 1, finish any work on models</li>
</ul>
Work on the project has certainly slowed in the previous weeks, in a frustrating fashion. We hope to pick it up in the coming weeks, as we have some cleanup to do.Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-10606159920701382542014-03-01T15:21:00.001-06:002014-03-01T15:21:53.053-06:00Week 11 Day 6 - Alpha 2 TestToday we had our Alpha 2 test. Things didn't go as we had planned. Dias was basically unplayable. The following were all issues that we discovered at the test.<br />
<br />
<ul>
<li>Players' HUDs would sometimes not load properly</li>
<li>Sometimes players wouldn't respawn</li>
<li>Boxes from the "Box Drop ability" were buffered when created, but not buffered when destroyed, resulting in dozens of boxes across some clients staying around.</li>
</ul>
<div>
As a result of these game-breaking bugs we had to end the testing period without getting the kind of feedback we wanted. We may perform a small in-house test later, when we get these bugs fixed.</div>
<div>
<br /></div>
<div>
It is obvious that we have a lot of work yet to be done. We will post again after we have talked about our goals we want to meet before our next test.</div>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-8139295228256240802014-02-17T00:50:00.002-06:002014-02-17T00:50:56.432-06:00Week 9 Day 7 - GitHub Troubles & AbilitiesThis week we hit some problems with GitHub. Zach commited his first change, and we were nearly unable to merge the commit. It appears that Git doesn't do things nearly as simply when it hits conflicts in files. We spent half of Saturday trying to get his changes into the system. They are in there, but we are unsure exactly how we did it. Our continued usage of GitHub is currently in question. If we are going to have this much trouble with solving file conflicts, we may go back to SVN, as it worked quite simply there.<br />
<br />
In less exciting news, the storing of teams was altered, to more easily accommodate grabbing the Team color or name. Some odds and ends bugs were fixed with the display of the Score menu. The side view camera is now implemented and working. There is a known issue of the camera falling through objects when pointed straight up in the air (falling through platforms, we need to test if it still does this for other objects). We'd also like the add the ability to swap the camera to the other side of the player dynamically in the game, now that it is no longer centered (This really shouldn't take more than an hour or two to accomplish).<br />
<br />
We are down to 2 weeks before Alpha 2, and are getting a little bit behind on schedule. We hoped to have 2 columns of abilities implemented by this coming test, however have not focused our efforts directly on those columns. We will need to step it up this next week if we hope to have 2 columns completed in time.<br />
<br />
The current ability chart is as follows:<br />
<br />
<table border="1">
<tbody>
<tr>
<th width="25%"></th>
<th width="25%">Light Role</th>
<th width="25%">Support (Builder) Role</th>
<th width="25%">Heavy Role</th>
</tr>
<tr>
<th>Attack-based Ability</th>
<td>Cone Push* (coned area)</td>
<td>Box Drop* (from sky)</td>
<td>Area Push* (area around player)</td>
</tr>
<tr>
<th>Defensive-based Ability</th>
<td>Blink* (Straight up)</td>
<td>Create Wall*</td>
<td>Steal Weight</td>
</tr>
<tr>
<th>Movement-based Ability</th>
<td>Roll (possibly ignore other abilities while rolling)</td>
<td>Grapple (like a grappling hook)</td>
<td>Ram (run forward and push other players out of the way)</td>
</tr>
<tr>
<th>Ultimate (and probably imbalanced) Ability</th>
<td>***</td>
<td>Destroy Platform</td>
<td>Ground Slam</td>
</tr>
<tr>
<th>Passive Ability</th>
<td>1/2 Dash Cooldown</td>
<td>Aura that lowers cooldowns for nearby players</td>
<td>Weight Gain</td>
</tr>
</tbody></table>
<br />
*These abilities are implemented currently<br />
*** This ability is still in consideration. We are trying out one of the following possibilities:<br />
<ul>
<li>Gravity Toggle - allows the player to not be effected by gravity while activated (Right now they can toggle this on and off, that will probably change)</li>
<li>Rocket (fires a projectile rocket that applies a large force on the player it hits, or maybe an explosive force around the location it hits)</li>
</ul>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-30486347865161727552014-02-08T19:40:00.002-06:002014-02-13T01:13:20.937-06:00Week 8 Day 7 - Individual Scoring and Pre-Alpha 2We spent the other day coming up with a system for individual scoring and awarding points to people who get "kills". Every time a player gets hit by an ability, the caster of that ability is added to a list, along with a time stamp. When a player dies, the last player to hit him is awarded a kill point. Every other player in that list is awarded an assist point. Players in the list with a time-stamp within the last five seconds are only awarded points. We are also keeping track of the amount of times players die, so that any player can review his/her performance after every game.<br />
<div>
<br /></div>
<div>
We have implemented a few abilities but most still haven't been worked on. We are still discussing if we are going to change some of the abilities from the previous table we posted.</div>
<div>
<br /></div>
<div>
We still need to work on changing the camera from a top perspective to a side perspective, along with a follow camera while someone is waiting to respawn.</div>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-59416633306248972252014-01-30T21:10:00.004-06:002014-01-30T21:12:44.726-06:00Week 7 Day 4 - Odds, Ends and AbilitiesToday we nailed down a complete list of abilities. Obviously this will change as we try new abilities out, but we want to get as many of these implemented as possibly by Alpha 2, or at least 2 columns of abilities.<br />
<br />
<table border="1">
<tbody>
<tr>
<th width="25%"></th>
<th width="25%">Light Role</th>
<th width="25%">Support (Builder) Role</th>
<th width="25%">Heavy Role</th>
</tr>
<tr>
<th>Attack-based Ability</th>
<td>Push (coned area)</td>
<td>Box Drop (from sky)</td>
<td>Push/Slam (area around player)</td>
</tr>
<tr>
<th>Defensive-based Ability</th>
<td>Blink (Straight up)</td>
<td>Create Wall</td>
<td>Steal Weight</td>
</tr>
<tr>
<th>Movement-based Ability</th>
<td>Roll (possibly ignore other abilities while rolling)</td>
<td>Grapple (like a grappling hook)</td>
<td>Ram (run forward and push other players out of the way)</td>
</tr>
<tr>
<th>Ultimate (and probably imbalanced) Ability</th>
<td>Rocket (large force on player it hits)</td>
<td>Destroy Platform</td>
<td>Ground Slam</td>
</tr>
<tr>
<th>Passive Ability</th>
<td>1/2 Dash Cooldown</td>
<td>Aura that lowers cooldowns for nearby players</td>
<td>Weight Gain</td>
</tr>
</tbody></table>
<br />
<div>
From the previous list of TODOs, we have completed the following:</div>
<div>
<ul>
<li>Pinging system that disconnects clients when they lose connection with the server</li>
<li>The last player that 'dies' at the end of a game is properly destroyed when the game is over</li>
<li>The mouse is now 'locked' to the window while controlling the character</li>
<ul>
<li>Solves the issue on Linux with the mouse escaping the edge of the window</li>
<li>Solves the issue on Mac with opening the top OS menu when aiming upwards</li>
</ul>
<li>Characters now are instantly 'teleported' to the location they respawn to, rather than being pushed to that location</li>
</ul>
Minus the items that are directly linked to abilities, here are our remaining goals for Alpha 2:</div>
<div>
<ul>
<li>Hit detection</li>
<li>Character-based scoring, rather than just Team-based</li>
<li>Moving the camera to aim from the sides of the characters, rather than from the top.</li>
</ul>
As a final note, work was started on the Box Drop ability under the Support Role, however we are considering doing the Light and Heavy abilities as the 2 columns. The reasoning for this is that those 2 roles are more easily understood to inexperienced testers. It would also give a better idea for what to expect from the choosing of abilities for all other users.</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-26604393253705217362014-01-21T16:30:00.000-06:002014-01-21T16:31:49.263-06:00Week 6 Day 2 - Character Movement, Cone Push and Alpha 2 PrepOn Saturday, we had our first test, Alpha 1. We had 10 players participating (Big thanks to all of you!), and got a lot of great information out of it. Also the post-play questionnaires brought up some good points. A few we already were aware of, in particular:<br />
<div>
<ul>
<li>Players couldn't be pushed if they moved</li>
<li>Over the head viewpoint tends to cause pushes to be down into the platforms, and not be as useful</li>
<li>Jump counter could be reset by any kind of contact with objects, not just your feet hitting the ground</li>
</ul>
We also had a server disconnect during the second game, and all clients thought they were still in the game. Right now we are relying on Unity to call the correct functions when this disconnect happens. Obviously that isn't enough, so we are considering inserting our own pinging method. The idea would involve each client pinging the server for a connection, and if they didn't receive a response within a second or two, to automatically disconnect themselves.<br />
<ul>
</ul>
</div>
<div>
We already completed a couple of things on our list of tasks for Alpha 2:</div>
<div>
<ul>
<li>Characters can now be pushed while moving</li>
<ul>
<li>We are moving the rigidbodies of players in a new way, which has a new issue in that their velocities are not effected by it, however pushes work as expected now.</li>
<li>This new method also feels much smoother than changing the velocity</li>
</ul>
<li>The chatbox in the lobby and game was broken during the test, and has been repaired</li>
<ul>
<li>We forgot to update how we are sending players now, since that update in the last week before the test</li>
</ul>
<li>Duplicate names now have a number appended to them, which increments until it finds an open possible name</li>
</ul>
We've started the list for Alpha 2 goals, which will undoubtedly be modified in the coming days:</div>
<div>
<ul>
<li>Design abilities</li>
<li>Implement abilites (Why is this one item?!)</li>
<li>Game Lobby Character Creation</li>
<li>HUD</li>
<li>Handle Server Disconnect</li>
<li>Respawning at game end</li>
<li>Follow camera while respawning</li>
<ul>
<li>This is optional really, we are debating whether we even want this, as an overhead camera is fine</li>
</ul>
<li>Hit detection</li>
<li>Proper scoring for players and not just teams</li>
<li>More thorough testing on mouse input</li>
<ul>
<li>One of the testers reported issues when looking down while turning</li>
</ul>
<li>Try aiming camera from the side of the player, rather than from the top</li>
<ul>
<li>pushes will be generally aimed downward with the top camera, making the pushes less effective</li>
</ul>
<li>Characters currently lerp to their respawn location from where they hit the boundary, they should simply be teleported</li>
</ul>
The plan is to hit a few of these odds and ends issues from the test for the remainder of the week, while also beginning to draw out what all the abilities are going to be. We hope to have a ready list of abilities by next week. The 2 weeks after that will be spend implementing as many abilities as possible. The remaining 2 weeks will be spend cleaning up the other systems before the Alpha 2 test.</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-76778425387175987622014-01-15T20:36:00.000-06:002014-01-15T20:36:32.356-06:00Week 5 Day 3 - Physics my friend, We are the master now!So we found out what our problem was with the push ability. The problem that we perceived we had was that for no reason the force from the push would send the player flying straight up into the air, with only a little horizontal force. The problem that we actually had was the way we were handling movement.<br /><br />In our movement script every frame we were checking if the player was attempting to move, and subtracting our target velocity (0 if the character wasn't trying to move) from our current velocity. So if we were still and the character was trying to move, we would start moving, and if we stopped trying to move, the character would be slowed down to a velocity of 0. This means that every time we applied a force to that character, the next frame they would be slowed down to a stop. However, we were handling jumping (movement in the vertical direction) differently.<br />
<br />
Therefore in actuality, the vertical movement wasn't the problem, and the horizontal movement was. When we saw that our push ability didn't move the character very far, we vastly increased the force at which we were applying the ability. This made the forward movement seem a little more correct, but insanely increased the vertical force.<br />
<br />
Our solution was to revamp the way we were doing movement, and not push the player to a stop any longer. This means we now have to rely on actual physics for the character to come to stop, such as air drag and friction. After readjusting some values our movement is back to normal, and we finally feel comfortable with our push ability.<br />
<br />
We have the following variables that we can adjust to modify the finer movement mechanics of how the game runs:<br />
<br />
<ul>
<li>Gravity</li>
<li>Static Friction</li>
<li>Dynamic Friction</li>
<li>Air Drag/Resistance</li>
<li>Bounciness (we have not messed with this yet)</li>
</ul>
<div>
We still have an issue with how we are respawning players and the game ending. Currently, each client waits three seconds before trying to respawn their character, and if the game is over, they destroy their game object instead. However, if the game were to end, and a new game start in that three second time period, the game object wouldn't ever be destroyed. We would then have multiple game objects on one client, along with multiple cameras and strange things begin to happen.</div>
<div>
<br /></div>
<div>
Overall we feel pretty good about where we are, in relation to how far away our first alpha test will be.</div>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-39470392068275965132014-01-13T21:19:00.000-06:002014-01-13T21:20:55.460-06:00Week 5 Day 1 - NetworkViewIDs, Scorekeeping and Push abilityToday was spent adding a ScoreKeeper to the game. Whenever a player is respawned, they tell the player, and the score is updated appropriately. Right now we are only basing scores on when opposing players hit the edge of the map. In post-Alpha 1 builds, we intend to base it on the last player to push/effect the player before hitting the edge.<br />
<br />
We didn't fully get to an end game condition, however it seems like that won't take too much time to finish up tomorrow.<br />
<br />
There were more issues with how we were mapping players to their builds. It turns out that the NetworkPlayer that we were using will only work as we expected on the Server, and the unique numbers for each client are not available on other clients. We are now allocating a NetworkViewID (Which is guaranteed to be unique) for each player, and they pass this with all their correspondence.<br />
<br />
There is still work that needs to be done on the Push ability. It seems that no matter how we adjust the force being applied, it will often times transform into a large vertical movement, that we can't seem to follow. The vertical movement seems random, and we need to more thoroughly investigate this issue. It doesn't seem to be caused by physics materials on the object, as we are controlling for those.<br />
<br />
We also made an online form for the post-play questionnaire after the two test games. We also put a button linking directly to it in the main menu of the game, to make getting to the survey easy for our testers.<br />
<br />
The remaining list for Alpha 1 preparations:<br />
<br />
<ul>
<li>Push Ability adjustments</li>
<li>More thorough network testing</li>
<li>End condition for games (Score and timer)</li>
</ul>
The link to our Alpha 1 signup is at the following address: <a href="http://goo.gl/hgkHZU">http://goo.gl/hgkHZU</a>Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-7993499548275182142014-01-10T22:56:00.001-06:002014-01-10T22:56:12.835-06:00Week 4 Day 5 - Teams and Character Builds!Thursday and Friday were spent reworking how we are storing a player's data on the clients. It turns out that we misunderstood how the Unity Networking RPC and Network.Instantiate methods were passing "sender" data, and everything is actually coming from the server on the clients (which makes a lot of sense, now that we think of it...). We spent quite a long time hunting down this issue, which manifested when we were trying to pass a player's build to the other clients, which also includes what team they are on, and their chosen name. Once we figured out what the issue was caused by, everything worked as expected. <br />
<br />
We are now passing builds to all clients, and they are apply aspects of the build to each character. Right now the only change is the team, which will change the character's color. Post-Alpha 1, this will be where we apply their choices for jump/movement/role abilities, and weight.<br />
<br />
We also have a crosshair! Yay!<br />
<br />
This puts our list of tasks to complete by next Saturday's test at the following:<br />
<br />
<ul>
<li>Rework push ability</li>
<li>More thorough network testing</li>
<li>Score keeping, and win condition</li>
<li>Create official post-play questionnaire for Alpha 1</li>
</ul>
<br />
<div>
The link to our Alpha 1 signup is at the following address: <a href="http://goo.gl/hgkHZU">http://goo.gl/hgkHZU</a></div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-77312018920207811512014-01-08T20:59:00.001-06:002014-01-08T20:59:57.610-06:00Week 4 Day 3 - Current StatusWe are about a week and a half from Alpha 1 test. This week has been pretty productive, with completion of the following tasks:<br />
<br />
<ul>
<li>Game lobby character customization placeholder</li>
<li>System for character names, and rework of chat box</li>
<li>Boundaries to the arena, and respawning when you hit these boundaries</li>
<li>Reworked character ability management, so now abilities are loaded when the player is created</li>
<ul>
<li>Currently these are all predefined for each player, and is not sent over the network (That will probably be for Alpha 2)</li>
</ul>
<li>Network test</li>
<ul>
<li>Able to create servers and join them as expected</li>
<li>This test displayed an issue where some players will completely lose control of their character, and fly off in a random direction. We aren't sure what causes that issue, but it's definitely something that will need to be fixed before Alpha 1</li>
</ul>
</ul>
This puts us about on track for where we wanted to be at this time. We still have the following tasks to complete before Alpha 1:<br />
<div>
<ul>
<li>Rework push ability, to act more appropriately</li>
<li>Teams, score keeping and end of game</li>
<li>Game lobby game placeholder information</li>
<li>More thorough network testing</li>
<li>Add cross hair to the HUD</li>
<li>Create official post-play questionnaire for Alpha 1</li>
</ul>
We have also created the web form for our Alpha 1 test sign up, it can be found <a href="http://goo.gl/hgkHZU">here</a>. We are hoping for about eight people for each of the two testing times. That would give us a fairly large sample to draw data from, while still being manageable.</div>
<div>
<br /></div>
<div>
Shortened link to sign up form: http://goo.gl/hgkHZU</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-53515450732702017702014-01-01T23:11:00.001-06:002014-01-01T23:11:43.656-06:00Week 3 Day 3 - Ending and Exiting the gameToday was spent making it possible to end and exit games. The host player can now end the game for all players, sending them back to the game lobby. Any client player may leave the game, which sends them back to the main menu. <br />
<br />
There is currently a small error that Unity receives on the server during arbitrary game endings. This happens because the server removes all the objects in the game, but receives one last update from a client about their object. That last update throws an error because the object no longer exists. We are properly removing the footprint of RPC calls associated with each object, however this message manages to get through. It may just have to be an error that exists, as it doesn't actually cause any issues with the game.<br />
<br />
We also have a working Pause Menu and HUD. The pause menu features settings that can be modified in the game. The HUD currently just has placeholder information that will be added in later (possibly between the Alpha builds).<br />
<br />
We put together a list of items we have started, but need to put more work into before the Alpha 1 test:<br />
<br />
<ul>
<li>Physics/Push Ability</li>
<li>Game Lobby information and display</li>
<ul>
<li>Placeholder information for character customization</li>
<li>Placeholder information for game customization</li>
</ul>
<li>Spawning, Respawning, and boundaries to the arena</li>
<li>more thorough network testing</li>
<ul>
<li>We haven't actually gotten a game to work between two computers yet, however all the backend should exist now for that to work properly</li>
</ul>
</ul>
In addition to these items, we have a number of things we haven't started yet, but wish to complete before the first test:<br />
<br />
<ul>
<li>Teams</li>
<li>Character ability management</li>
<li>Score keeping and a win/loss condition</li>
</ul>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-20315513903398507722013-12-27T20:15:00.000-06:002013-12-31T16:43:58.427-06:00Week 2 Day 6 - Main Menus, Settings Menus, and Game Lobbies, Oh my!Today we exclusively worked on menus. We were having problems previously with how we were trying to implement our menus. Before we were having a problem in switching how things were being drawn in our OnGui function. This function is actually called twice, once for figuring out where everything should be drawn, and the second time for drawing it. Originally, we were changing how things were to be drawn in that function, so that each frame it was trying to draw two different things. We now a menu manager, which is different from our proposal. With this new system, we are always drawing the same thing during any particular frame.<br />
<br />
We were also encountering a problem in which the previous menu screen wasn't being cleared when switching menus. This resulting in menu buttons and screen objects being drawn on top of one another. This is because without a camera in the scene the screen would never be flushed. So we added a 'dummy' camera to sit in our scene while we navigated the menus, so that we could appropriately clear previous menus and draw new ones. This camera will allow us to provide an appropriate backdrop for the menus in the future.<br />
<br />
After we got this system set up, and working for the main menu, we split into working on two different menus. Jon worked on the Settings menu while Zach worked on the Game Lobby menu (we decided who would work on which with the roll of a die).<br />
<br />
We now have a basic settings menu containing multiple sliders and toggles allowing the user to change their preferences such as inversion, sensitivity, and field of view. We also have a basic game lobby menu that contains multiple placeholders that may or may not change as we make them actually useful.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbQ9VJjhru-6809IrHitUgJX0YTBx_-P5G_GPUUxpI0R6MO2kGSDV6I5PpjKV7juQVcQE617CQjOcpe843ZY7XjHmcQvGcjoZKoRTkokpiMcAi05IV_2x33iBSMuEX5Erc1svG24dPRS8/s1600/Chatbox.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbQ9VJjhru-6809IrHitUgJX0YTBx_-P5G_GPUUxpI0R6MO2kGSDV6I5PpjKV7juQVcQE617CQjOcpe843ZY7XjHmcQvGcjoZKoRTkokpiMcAi05IV_2x33iBSMuEX5Erc1svG24dPRS8/s640/Chatbox.PNG" height="368" width="640" /></a></div>
<br />
Above is shown two clients connecting to one another in the game lobby screen. In the bottom left you can see a text box that the user can type into. When they press enter the message is sent to every client connected, and added to a list of messages. That list is printed above the text box, as you can see on both clients above. We still need to add a specific box for the messages to appear in, along with a scroll bar so that the messages do not continue off screen.<br />
<br />
Due to more Christmas Festivities this weekend, we will not be able to work on Dias again until Monday. We will work on the following goals starting Monday:<br />
<br />
<ol>
<li>Get Dias to the point at which we can enter a game from the game lobby.</li>
<li>Basic HUD.</li>
<li>Pause menu.</li>
<li>Start working on teams.</li>
</ol>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-1211046449468589782013-12-26T17:23:00.000-06:002013-12-31T16:43:12.785-06:00Week 2 Day 5 - Basic Ability, Network Abilities, Spawn Manager and GUI BasicsSo, quick recap on the last week, as we haven't had many opportunities to post recently.<br />
<br />
Friday/Monday were spent working on the Cone Push Ability. On Friday, we spent more time than we intended working with Blender to create a basic cone, that was centered at the point on the cone, rather than the middle of the cone and getting that properly imported into Unity. We now have that figured out, and will be able to any shape/model importing much faster in the future. Here's a size comparison of the current cone push area:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgK_ILwGdyeYUA4ny-7c4bhJO7n8DPY99LCpbfqnpJzmM01aa8dFM3Uid-LjRQ33BHq9UEhjs6QvEEyUBlT4pLjVeGMwhXEhbdx9eQKNsw9yaqhj1t9RBpY7uuGSUbmwlGuFckehEJjArw/s1600/conepushobject.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgK_ILwGdyeYUA4ny-7c4bhJO7n8DPY99LCpbfqnpJzmM01aa8dFM3Uid-LjRQ33BHq9UEhjs6QvEEyUBlT4pLjVeGMwhXEhbdx9eQKNsw9yaqhj1t9RBpY7uuGSUbmwlGuFckehEJjArw/s400/conepushobject.PNG" height="192" width="400" /></a></div>
<br />
When trying to create the cone relative to their character we also had to take into account the third person point of view, take the following example:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT0Sp464z1J-Gz2x5vPxBYGw34V2avB1cmk68T21juCrx_kOPtBvrLo1ZO3_oYuYEn7fdGtn1f5QOe7q2S6IZLfm4n8k1zh6f1JN4VKvZhqr8Qtg74Jk2U1LWQpXP5_mHSHhHqcFfTAmY/s1600/thirdpersonabilityactivation.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjT0Sp464z1J-Gz2x5vPxBYGw34V2avB1cmk68T21juCrx_kOPtBvrLo1ZO3_oYuYEn7fdGtn1f5QOe7q2S6IZLfm4n8k1zh6f1JN4VKvZhqr8Qtg74Jk2U1LWQpXP5_mHSHhHqcFfTAmY/s640/thirdpersonabilityactivation.PNG" height="292" width="640" /></a></div>
<br />
The orange line represents where the player is aiming when they are activating an ability. The red line represents the actual direction where the ability will be cast from. As you can see, when the player aims at something in the center of their screen, the ability is not cast from the direction they are looking, but rather out of their character. This new direction can be calculated simply with some vector math, but it was interesting enough that we thought we would include it in here.<br />
<br />
It wasn't until Monday that we really got started on applying the ability over the network. We put some thought into how to implement this, and had to choose how we wanted to handle player collisions over the network. Our original model was a very authoritative server model, however Unity's networking is much simpler with a more distributed approach. We concluded that there were a few basic ways to approach this ability over the network:<br />
<br />
<ol>
<li>Player activates ability, tells server that he activated, server tells all clients to display cone, server tells certain clients that they need to apply a force to themselves.</li>
<ul>
<li>Authoritative to server</li>
<li>Some instances of others being pushed by this ability, even though they feel that they dodged it</li>
<li>Some instances of this client feeling like he hit someone, and not hitting them</li>
</ul>
<li>Player activates ability, tells all clients to display cone, caster client finds people he hit, telling those clients that they need to apply a force to themselves.</li>
<ul>
<li>Authoritative to caster's client</li>
<li>Some instances of others being pushed by this ability, even though they feel that they dodged it</li>
<li>Almost never instances of this client feeling like he hit someone, and not hitting them</li>
</ul>
<li>Player activates ability, tells all clients to display cone, those clients determine if they are hit, applying forces to themselves.</li>
<ul>
<li>Distributed to all clients</li>
<li>Almost never instances of others being pushed by this ability, even though they feel that they dodged it</li>
<li>Some instances of this client feeling like he hit someone, and not hitting them</li>
</ul>
</ol>
As it currently stands, we decided to go with implementation #3. This method does limit the amount of data sent over the network, as it only forwards the position, rotation, and the ability cast. Whereas other methods would require to additionally tell other clients if they needed to apply a force, and by how much. We also decided that it would reduce the number of discrepancies clients have while playing the game. The authoritative server, and authoritative caster methods would lend to more clients having discrepancies with the ability, while #3 seemed to provide the fastest feedback, and a majority of players would feel better if what happened to them reflected what they saw on their client.<br />
<div>
<br /></div>
<div>
Once we were able to use this ability over the network, we began experimenting with how it affected other players. The idea was that it would nearly push them off of any platform they are standing on, and a couple pushes would definitely push them off. We soon realized that we do not have nearly enough experience with Unity's physics engine, as we were plunged into resources on Physics materials and their effect on friction, applying the force against gravity, and a number of other issues directly related to our inexperience. Fine-tuning the numbers and methods of applying this force will need more work to proceed.<br />
<br />
<br />
<div>
Today, we implemented a spawn manager. There are a number of spawn points located on each of the platforms. When the platforms are created on each client, they register themselves with the Spawn Manager. This manager currently only keeps a list of spawn points, and gives one to the player when they are first joining the game. In the future, we will have it give spawn points based on what team the player is on, where their teammates are, and other game objectives.</div>
</div>
<div>
<br /></div>
<div>
We are approaching the point at which we need to start taking into account how teams are going to work, and when a player is beyond the bounds of the game. We feel that it is about time that we work on some GUI elements, and get the basics of creating a server/client and modifying our game variables are just as easily implemented with a GUI as without right now. Also, we are lacking any experience with Unity's GUI and want to get a feel for what we are getting ourselves into with that.</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-68331260457012167862013-12-20T15:16:00.000-06:002013-12-31T16:42:29.184-06:00Week 1 Day 4 - CC & PlatformsThere were no posts yesterday, as we hit several roadblocks in our work. The primary issues came about when trying to create a CharacterController (CC). The CC can only be moved by an absolute number of units (aka, has no velocity). It also doesn't naturally implement gravity. So when we were able to get gravity working, it was extremely high (because we increased it, due to Rigidbodies falling very slowly), to the point where you would jump up, and immediately hit the ground again. The jumping was also not consistent, as the character would be teleported to the jump height, rather than making a smooth jump, as the Rigidbody had. Both of those issues could be handled better by 'faking' velocity. So that was implemented, though the velocity needed to falloff toward zero each frame, to account for fake drag, because CCs don't have physics reactions to other objects colliding with them. Adding this falloff caused an unknown issue with the player's view spinning around for a split second while walking forward (the problem didn't exist when walking sideways or backwards).<br />
<br />
Due to these issues, we decided to toss out the CC option for the moment, and return to networking issues. Also, there was a CharacterMovement abstract class defined that defined a couple abstract methods for moving a character, and setting a character's rotation (amount of rotation is always determined by look scripts/cameras).<br />
<br />
On the networking side of things, we did implement a PlatformManagerScript that would create platforms across the network. These platforms would be instantiated by all clients that connected to the server. Because they are not moving yet, they remain in perfect synchronization, which can't be said for the characters.<br />
<br />
For today's (Friday's) goals:<br />
<br />
<ul>
<li>Polish character movement across network</li>
<li>Start a basic ability implementation (cone push)</li>
<ul>
<li>If there is time, attempt to push this over the network</li>
</ul>
</ul>
We took a while and compiled a list of all the things the game will need for Alpha 1, to be a worthwhile test:<br />
<br />
<ul>
<li>Creating & Joining server</li>
<li>Characters can move & cast an ability over the network</li>
<li>Main menu, settings, basic HUD, basic lobby (possibly chat), pause menu</li>
<li>Respawning after 'death'</li>
<li>Scorekeeping, win/loss condition</li>
<li>Teams</li>
</ul>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-85406590096640029092013-12-19T00:30:00.000-06:002013-12-31T16:42:12.649-06:00Week 1 Day 3 - NetworkingThe rest of the evening was spent playing around with networking. This might be a good point to mention, that most of the networking model that was described in our proposal will not work as we thought. It seems that Unity already has simple methods for synchronizing objects across the network, and we can simply do synchronization right on the object we wish to send out. Of course, certain pieces of that model will still be present at a later date, particularly the section about getting a game started.<br />
<br />
For now, we are going to proceed with the built-in Unity Networking. Its model more appropriately fits our needs, and is easy enough to use. This decision may change as we continue to work on networking this next week. We were able to get a local server set up, and connect clients to it, and have players move around.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVOHzyLkCFCGK8Zut7YKfmDvUkaNXPWHpdueRDVz14lr7uS27fcbazqjBXBWpqgyqKR8I-ZxmlwBhELnnwYQJqRp-NhIWDNYwlhWzRq9jlC_sMrhEqWLlJKtlLds7FuLwDDIy13nKL300/s1600/NetworkingStarted.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVOHzyLkCFCGK8Zut7YKfmDvUkaNXPWHpdueRDVz14lr7uS27fcbazqjBXBWpqgyqKR8I-ZxmlwBhELnnwYQJqRp-NhIWDNYwlhWzRq9jlC_sMrhEqWLlJKtlLds7FuLwDDIy13nKL300/s640/NetworkingStarted.PNG" height="344" width="640" /></a></div>
<br />
All players are created with the input script, movement scripts, and even the cameras. However we disable all of these by default, only enabling them for the given client's player.<br />
<br />
We immediately noticed the issue of using rigidbodies to control our players. When players collide, the physics engine will begin fighting against the NetworkPlayer script that updates the player's location. This is a serious issue, as the physics engine is still currently crucially important to how we will interact with the other game objects. However, now that we have started to work with networking and physics together, we may need to reassess how we are controlling the player.<br />
<br />
Goals for tomorrow:<br />
<br />
<ul>
<li>Write a Movement Script with the Character Controller (as opposed to a rigidbody) and see its effect on network movement</li>
<ul>
<li>Write a super class for both of these scripts, that defines an interface to move the player and rotate them</li>
</ul>
<li>Write a Platform Manager that will create all the platforms at the beginning of a game (for the server), and tell all the clients where to create the platforms</li>
<ul>
<li>Write a Platform script, that defines some basic platform information (this is mostly placeholder for stuff later)</li>
</ul>
<li>Discuss how player interaction should work</li>
<ul>
<li>What happens when players collide with each other? Going fast? Going slow?</li>
<li>What happens when players collide with a platform?</li>
</ul>
</ul>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-25773265081388645992013-12-18T18:48:00.002-06:002013-12-31T16:42:06.494-06:00Week 1 Day 3 - Telescope Polish, Abilities and NetworkingNot much coding has happened today. We fixed the telescope camera, by switching it to a perspective camera, rather than orthographic, and toying with its settings a bit. Originally we though that orthographic would be good for that long-distance view, however perspective is much easier on the eyes in practice. So we went with that.<br />
<br />
We sat down and starting thinking of ideas for abilities and how they would be associated with each player role. We have (sort of) arrived at this temporary (and not even complete) table:<br />
<br />
<br />
<table border="1">
<tbody>
<tr>
<th width="25%"></th>
<th width="25%">Light Role</th>
<th width="25%">Support (Builder) Role</th>
<th width="25%">Heavy Role</th>
</tr>
<tr>
<th>Attack-based Ability</th>
<td>Push (coned area)</td>
<td>Box Drop (from sky)</td>
<td>Push/Slam (area around player)</td>
</tr>
<tr>
<th>Defensive-based Ability</th>
<td>???</td>
<td>Create Wall</td>
<td>Steal Weight</td>
</tr>
<tr>
<th>Movement-based Ability</th>
<td>Roll (possibly ignore other abilities while rolling)</td>
<td>Grapple (like a grappling hook)</td>
<td>Ram (run forward and push other players out of the way)</td>
</tr>
<tr>
<th>Ultimate (and probably imbalanced) Ability</th>
<td>???</td>
<td>Destroy Platform</td>
<td>???</td>
</tr>
<tr>
<th>Passive Ability</th>
<td>Extra Jump</td>
<td>???</td>
<td>???</td>
</tr>
</tbody></table>
<br />
<div>
This chart still needs a lot of work before it is ready to go. These abilities will also not start to be implemented until after Alpha 1, according to our project schedule. We spent a short amount of time talking about how we would handle role abilities, and movement abilities. There is still a bit of thought that needs to be put into that before we get to the system.</div>
<div>
<br /></div>
<div>
We decided to delay working on the Distance Checker earlier, and decided that the basic player controls are sufficient for day 3 of development. We want to get started on networking early, as it will be a VERY large factor in how we proceed with development. Several hours were spent looking into different networking options for Unity. We both arrived at the same options, their benefits and risks.</div>
<div>
<br /></div>
<div>
<ul>
<li>Built in Unity Networking</li>
<ul>
<li>Player-hosted servers (like we planned, according to our proposal)</li>
<li>Questionable documentation and few available tutorials</li>
<li>Easy to implement</li>
<li>Known to be buggy (according to several forum posts)</li>
</ul>
<li>Photon Unity Networking</li>
<ul>
<li>"Cloud"-hosted central server only (opposite of what we planned)</li>
<li>Questionable documentation and some excellent tutorials</li>
<li>Easy to implement</li>
<li>Known to be reliable (according to tutorials and reviews)</li>
</ul>
</ul>
</div>
<div>
<br /></div>
<div>
We are playing around with a few small prototypes for each, and will use those to make our decision on which method to go with. We are both fond of the player-hosted server model, however the benefits (mostly the ease-of-use) of the Photon network are enticing.</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-77622634397889319262013-12-18T15:25:00.001-06:002013-12-18T15:27:16.379-06:00Questions and our AnswersWe were having some problems with comments on our posts not showing up. We disabled and re-enabled our comments and hoped that that fixed the problem. If your comments are still not showing up, let us know and we'll find another solution.<br />
<br />
Karl Ahrendsen asked a few good questions on our posts and I'll copy all of his comments down below.<br />
<br />
<b>Day 1 - Repository set up & Beginning Character Controls</b><br />
<b><br /></b>
<i>Karl</i>: "<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">Yes indeed. Cause physics. Make Dr. Stone proud, Zach, write those kinematic equations."</span><br />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="color: #404040;"><span style="line-height: 18px;"><i><span style="font-family: Roboto, arial, sans-serif; font-size: x-small;">Response: </span><span style="font-family: inherit;">"</span></i><span style="font-family: inherit;">All the physics!"</span></span></span><br />
<span style="color: #404040; font-family: Roboto, arial, sans-serif; font-size: x-small;"><span style="line-height: 18px;"><br /></span></span>
<b>Day 1 - Camera Collision Detection</b><br />
<b><br /></b>
<i>Karl</i>: "<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">I really like the raycast idea, but after thinking about it for a while, I think all it comes down to is remapping the downward navigation of the camera to forward navigation (toward the player). I would be interested to hear if you tried both ways and if they feel any different."</span><br />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #404040; line-height: 18px;"><i style="font-family: Roboto, arial, sans-serif; font-size: 13px;">Response: </i><span style="font-family: inherit;">"Your method is exactly how we originally tried to solve the problem. The problem we ran into was that we had one script detecting if we hit something to pull forward. Another script would detect that we are not at our set distance, and it would pull back a little bit. So we ended up with a camera that was jerking back and forth every single frame when it would collide with something.</span></span><br />
<span style="background-color: white; color: #404040; line-height: 18px;"><span style="font-family: inherit;"><br /></span></span>
<span style="background-color: white; color: #404040; line-height: 18px;"><span style="font-family: inherit;">We ended up using raycasts for a few reasons. Firstly, it was easy. There wasn't a lot of trig or math to crunch figuring out where to draw the camera. The raycast gave us the position. Secondly, raycasts are cheap. Thirdly we could always be 100% sure that the camera would be drawn where it was supposed to be drawn. Look at the picture below for an idea of a strange situation that we would have to move the camera appropriately. The character is standing on the left box and the camera is sitting on the right box. Along with the picture, another scenario is if the player is on a slope. We need the camera to slide along the slope. The raycast gives us an exact point, while the other method we would have to take multiple scenarios into consideration."</span></span><br />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRMxbQvGKyGiTn_VjwWG-VEuErbb0lvqDhHp5-Kc4PbOghctEc8gjfjboxBBKt7brsCiGRYE6BmK4AXjotb8iuFEDawY102MYgtEd3bujzytlO2VlkCfDd-T8Au4Y7VTy4kLO21OrBKkE/s1600/PlayerAndCameraOnBox.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="354" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRMxbQvGKyGiTn_VjwWG-VEuErbb0lvqDhHp5-Kc4PbOghctEc8gjfjboxBBKt7brsCiGRYE6BmK4AXjotb8iuFEDawY102MYgtEd3bujzytlO2VlkCfDd-T8Au4Y7VTy4kLO21OrBKkE/s640/PlayerAndCameraOnBox.PNG" width="640" /></a></div>
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<br />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<b>Day 2 - Camera Polish, Gravity, and Controls</b><br />
<b><br /></b>
<i>Karl: </i>"<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">From a player perspective, do you think that the difficulty judging distance is something that would be solved after a few minutes of playing the game? Do you think it arises from a familiarity with jumping in other video games and your game just has different jumping mechanics?</span><br />
<br style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;" />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">Whatever the case, I think that the distance checker is a good thing. Experienced players probably won't have to use it because they already know whether they will be able to make the jump and beginners will be able to figure out the jumping mechanics by methods other than trial and error. Of course, it's only a good thing if the mouse button would have otherwise gone unused."</span><br />
<span style="color: #404040; font-family: Roboto, arial, sans-serif; font-size: x-small;"><span style="line-height: 18px;"><br /></span></span>
<i>Response: </i><span style="font-family: inherit;">"</span>Actually it came about not because of a mouse button being used or not, but because of the controller. We didn't have anything mapped to the bumpers on our controller mapping, and so Zach was going to map the zooming controls to the bumpers. Jon felt this was wrong on moral level, and so came up with another control to map to the bumpers.<br />
<span style="font-family: inherit;"><br /></span>
On a more serious note, our game is different in that we do not have many points of reference to judge distances. Take Halo for example. If you wish to jump to another platform above or below you, you can judge the distance based on the rest of the world. You have an entire world around and below you to determine exactly where that platform is in relation to your position, and if you can make the jump. In our game all there is to determine if you can make the jump are the platforms in open space. Nothing else is around them. Not to mention that they are moving platforms, complicating the matter even further. So we wanted to add a tool for assisting the player in judging distances."<br />
<br />
<i>Karl: </i>"<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">In Super Smash Bros. I believe you could affect the speed of your fall by pressing down on the control stick. This might be something to consider, especially with the pivoting platforms. A player could slam into one side of the platform harder and cause more platform movement if they accelerated into the platform by holding "down""</span><br />
<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;"><br /></span>
<span style="background-color: white; color: #404040; line-height: 18px;"><i style="font-family: Roboto, arial, sans-serif; font-size: small;">Response: </i><span style="font-family: inherit;">"That is a good point, and something that we are actively considering. We don't have all of the abilities figured out yet, and are still debating on which abilities are going to be included and how they are implemented into Dias."</span></span><br />
<b><br /></b>
<b>Day 2 - Settings, Input, and Telescopes</b><br />
<b><br /></b>
<i>Karl: </i>"<span style="background-color: white; color: #404040; font-family: Roboto, arial, sans-serif; font-size: 13px; line-height: 18px;">I think the distance checker is something that would come in later in the design. It seems like a feature that would be nice, but is far from necessary for playing the game."</span><br />
<i><br /></i>
<i>Response: </i>"That is something that we discussed earlier today, and came to a similar conclusion. It will probably pushed back until between Alpha 1 and Alpha 2."Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-23241674631655337362013-12-17T22:41:00.000-06:002013-12-31T16:41:59.872-06:00Week 1 Day 2 - Settings, Input, and TelescopesSince the last post, we have added all the input controls that we think we will need. We have also created two new scripts to handle player settings, and game settings. Player settings include things like camera sensitivity and camera inversion. Game settings include everything else, from movement speed to jump height.<br />
<div>
<br />
<div>
We spent the vast majority of the evening working on the telescope camera. We decided, rather than moving the main camera in front of the character to zoom in, to just create another camera. However, once we began turning off whichever camera wasn't being used, we ran into a problem. The problem was that once one of the cameras was activated, it jumped to where it was last looking. So, I might be looking one way, but once I jumped into the telescope camera, I was suddenly looking behind me, because that's where the telescope was last pointing.</div>
<div>
<br /></div>
<div>
Our solution was to create a CameraController script, that managed both cameras. Instead of giving one of the camera script's the input information, we gave it to the CameraController to manage it all. The CameraController then gave whichever camera needed to be activated the appropriate information.</div>
<div>
<br />
<div>
Below is a picture of the telescope camera working.</div>
<div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEIaXWgjFVmdJNQJuaNvw_NM4r3b8FA1qHhvPFt22i95x-hakNud26kq9ZxXl-eKGfeuGNHlgKyR7gbJ3ozOi-EasSKBYmfAL-a5ItKvPd5ZAKwJ0bF-aLmOlpzlnUx2_DRxcLvlhQEO4/s1600/TelescopeCamera.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEIaXWgjFVmdJNQJuaNvw_NM4r3b8FA1qHhvPFt22i95x-hakNud26kq9ZxXl-eKGfeuGNHlgKyR7gbJ3ozOi-EasSKBYmfAL-a5ItKvPd5ZAKwJ0bF-aLmOlpzlnUx2_DRxcLvlhQEO4/s640/TelescopeCamera.png" height="358" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div>
In the bottom right corner you can see what the player would see on screen with the telescope camera. In the main scene, you can see the green capsule (the player) is looking off towards a distant platform. The invisible outlined box extending from the player is the view of everything that can be seen in the telescope. You can see how the bottom of the box skims along the distant platform, but the top misses the platform. This is reflected in the camera preview box in the bottom right.</div>
</div>
</div>
</div>
<div>
<br /></div>
<div>
Tomorrow we plan on working on the distance checker that was mentioned in our previous post, along with some minor polishing of the telescope. After that we plan on brainstorming and setting up a system for abilities, and different types of dashes and jumps. We may implement a few abilities, and after that, networking is our next objective.</div>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-28141557037598226662013-12-17T16:10:00.001-06:002013-12-31T16:41:50.955-06:00Week 1 Day 2 - Camera Polish, Gravity and ControlsWe started out the day with touching up the issues of clipping with platforms, and the camera going inside the player as the camera came closer during collisions. The player model now becomes transparent when the camera comes closer than 4 Unity units (~4 meters).<br />
<br />
Zach started working on player settings, and I started working on getting input for the rest of our controls. We had a debate about how to organize controls and such for all the actions a player will need to do during gameplay. We arrived at the following table:<br />
<br />
<br />
<table border="solid">
<tbody>
<tr>
<th width="30%">Player Action</th>
<th width="30%">Mouse/KB Mapping</th>
<th width="30%">Controller Mapping</th>
</tr>
</tbody><tbody>
</tbody><tbody>
<tr>
<td>Character Movement</td>
<td>WASD</td>
<td>Left Thumbstick</td>
</tr>
<tr>
<td>Camera Movement</td>
<td>Mouse Motion</td>
<td>Right Thumbstick</td>
</tr>
<tr>
<td>Camera Zoom</td>
<td>Mouse Scrollwheel</td>
<td>D-Pad up/down</td>
</tr>
<tr>
<td>Ability 1/2/3/4</td>
<td>Q/E/R/F</td>
<td>Left Trigger/Right Trigger/Y/B</td>
</tr>
<tr>
<td>Jump</td>
<td>Space</td>
<td>A</td>
</tr>
<tr>
<td>Dash</td>
<td>Shift</td>
<td>X</td>
</tr>
<tr>
<td>Telescope Zoom</td>
<td>Right Mouse Button</td>
<td>Left Bumper</td>
</tr>
<tr>
<td>Distance Checker*</td>
<td>Left Mouse Button</td>
<td>Right Bumper</td>
</tr>
<tr>
<td>Score Popup</td>
<td>Tab</td>
<td>Back</td>
</tr>
<tr>
<td>Pause Popup Menu</td>
<td>Esc</td>
<td>Start</td>
</tr>
</tbody></table>
<br />
<div>
*The distance checker is a new idea we came up with during the mapping of controls. A continuous issue with out game is the fact that it is difficult to judge distances and jumps to other platforms. The distance checker will fire out a ray, and get a platform from where the player is aiming. It will then use the standard jump distance and gravity to determine if the player can hit the platform. If they can, it will provide a visual cue. We are thinking this cue will be a glowing of the platform, but may be simply mapped to a HUD element during early development.<br />
<br />
We talked about possibly having other views of the game, possibly a large overhead view or a side view that could be activated by buttons. We are going to leave these out for the moment, but may come back to them at a later time.</div>
<div>
<br /></div>
<div>
For the rest of the day, we are going to continue working on settings, getting all this input, and possibly starting to get the Distance Checker and Telescope Zoom working.</div>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-10066464423581100872013-12-16T23:51:00.000-06:002013-12-31T16:41:44.890-06:00Week 1 Day 1 - Camera Collision DetectionAfter getting some standard movement and camera controls set up, we started trying to handle camera collisions with objects. Previously, and in the prototype, when the camera was moved into a solid object, it simply passed through, and we could see through the objects we were inside.<br />
<br />
We tried a couple different solutions to this, including:<br />
<br />
<ul>
<li>finding how far down the player had pulled the camera, after hitting an object. Using that distance to find the position along the object</li>
<li>Simply pulling the camera closer, whenever we were hitting an object</li>
</ul>
When these methods proved to be unnecessarily complicated, we got the idea to use a raycast from the position the camera would be looking at, out to the desired camera position. Using this cast, we can detect if we hit any objects in between the player and the camera, and set the camera at the position that we hit. This way, the player's camera will never be obstructed by any objects. This also eliminated us having to make a special case for when the camera's distance would place it on the opposite side of an object from the player (but not be hitting the object), this killing two birds with one stone.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ6AvOpdEf3odN0vv20cMIUQoXWqa7ixnsKhFBL93xMD9JoaGUsSXbkLGtu1-ZbnzlTnOEGzBVo-r-rTGTrw2yOnPBBaVqMWu2v-3QX0LHcqhnvPh3eqURT2_CQYSuh5E-Hi12NhTKPIo/s1600/cameracollisiondetection.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZ6AvOpdEf3odN0vv20cMIUQoXWqa7ixnsKhFBL93xMD9JoaGUsSXbkLGtu1-ZbnzlTnOEGzBVo-r-rTGTrw2yOnPBBaVqMWu2v-3QX0LHcqhnvPh3eqURT2_CQYSuh5E-Hi12NhTKPIo/s640/cameracollisiondetection.PNG" height="353" width="640" /></a></div>
<br />
Here's an image of the camera, as it intersects the platform below the player. It is closer than the standard camera distance, and still clearly placed the player in an unobstructed view (as you can see from the white lines that show the camera's view). This method is also REALLY smooth. The previous methods were causing some large jittering as we moved the camera forward and back, trying to place it in just the right location for where we were hitting objects. Doing the raycast gives us an exact point to place the camera (or a very close point, some optimizations will still need to be done to avoid clipping against the platform).<br />
<br />
We have written up some goals for tomorrow:<br />
<br />
<ul>
<li>Camera Polishing</li>
<ul>
<li>Character Opacity - make the character become transparent as the camera get's close to it</li>
<li>Platform Clipping - place the camera slightly above the raycast hit position for collisions</li>
</ul>
<li>Gravity</li>
<ul>
<li>right now, it seems like the player falls too slow</li>
<li>also, listen to the John Mayer song while doing this</li>
</ul>
<li>Ability Activation (basically placeholder right now)</li>
<li>Tighten character movement controls</li>
<li>Player Settings - store the data for this, don't actually make settings changeable yet</li>
</ul>
Anonymoushttp://www.blogger.com/profile/13893314857738356972noreply@blogger.com0tag:blogger.com,1999:blog-8729089156494538265.post-25804267640430367712013-12-16T17:32:00.001-06:002013-12-31T16:41:36.771-06:00Week 1 Day 1 - Repository set up & Beginning Character Controls<div class="separator" style="clear: both; text-align: left;">
Spent a few hours getting our Subversion repository working, followed by <u style="font-style: italic; font-weight: bold;">officially</u> starting development of Dias. Here are some photos of our code, math, and physics. The code allows the camera to move around the player, as far as they wish in the horizontal axis, and to a maximum and minimum degree in the vertical. Those values are calculated based on proportions set in camLocProportion. camLocProportion is the proportion of distanced behind and above the player model. The trigonometry shown below is also calculating the maximum and minimum degrees the camera should be allowed to rotate. And the kinematic equation shown in the top right calculated the initial jump velocity to be set to achieve a jump height 'd'. Cause physics. </div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4G_MDvjHe2MrLNXQtUOfqRrM-eLG5A1tLvjX2ZTWXSYCq6JZqT-kO8IH-Bd12p2fQoj3EPdkdlzzakfEjyVRoIOEClvHb4r3riAwLsGKAKcjc635ZSVBN7QcZsJBx0QDGXLlJ9xtLUl8/s1600/WP_000802.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4G_MDvjHe2MrLNXQtUOfqRrM-eLG5A1tLvjX2ZTWXSYCq6JZqT-kO8IH-Bd12p2fQoj3EPdkdlzzakfEjyVRoIOEClvHb4r3riAwLsGKAKcjc635ZSVBN7QcZsJBx0QDGXLlJ9xtLUl8/s640/WP_000802.jpg" height="640" width="480" /></a></div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBoGV2KLBkznIVABRGEZmOTtFnMuJvH3XkZEqSsVfy4Gcp7lCOn5LFGPSP7F8gjzEqpmOH06zng40cUSJj4xVt7mLk804g-Bd_7SIdaO2OyNkZauu-ivo9joXU5BAgNLEnAQPsXkX-l5o/s1600/code.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBoGV2KLBkznIVABRGEZmOTtFnMuJvH3XkZEqSsVfy4Gcp7lCOn5LFGPSP7F8gjzEqpmOH06zng40cUSJj4xVt7mLk804g-Bd_7SIdaO2OyNkZauu-ivo9joXU5BAgNLEnAQPsXkX-l5o/s640/code.PNG" height="582" width="640" /></a></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;">
~Zach Lorenzen</div>
<div class="separator" style="clear: both; text-align: left;">
~Jon Kenkel</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Zatchmeisterhttp://www.blogger.com/profile/12132279863141733713noreply@blogger.com0