https://cse125.ucsd.edu/cse125/2013/cse125g1/api.php?action=feedcontributions&user=Erik&feedformat=atomSpartacats - User contributions [en]2024-03-28T17:43:53ZUser contributionsMediaWiki 1.27.0https://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=940MediaWiki:Sidebar2013-12-09T10:47:29Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Progress Screenshots<br />
** Gameplay Screenshots|Gameplay Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
** Final Writeup|Final Report<br />
* SEARCH<br />
* TOOLBOX</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=931Main Page2013-06-21T22:34:03Z<p>Erik: /* Controls */</p>
<hr />
<div>[[File:SpartaCats Logo.png|600px|center|Image on center]]<br />
[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
<br />
== Download ==<br />
Requirements:<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer]<br />
<br />
== Story ==<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
:Move Forward: Lower Right Trigger<br />
:Move Back: Lower Left Trigger<br />
:Steering/Camera movement: Right thumbstick <br />
:Cycle Front Weapon Left: Left<br />
:Cycle Front Weapon Right: Right<br />
:Fire Front Weapon: A<br />
:Fire Rear Weapon: X<br />
<br />
:Boost Thrusters: B<br />
:Jump: Y<br />
<br />
== Art ==<br />
[[Game Art and User Interface]]<br />
<br />
[[3D Models]]<br />
<br />
== Media ==<br />
[[Gameplay Screenshots]]<br />
<br />
[[Gameplay Videos]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=930Final Writeup2013-06-15T23:24:26Z<p>Erik: </p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
:[Nico] Our initial design entailed armor power ups based on an element/color but we wound up going with random element/color assignment on spawns due to time constraints. The system works out well as players are forced to adapt to their element accordingly. There were also a few items that didn't make the final cut such as a ghost item (drive through walls and be invisible) and a bomb weapon which no one really knew what it should do.<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
:[Nico] And heap corruptions.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities throughout development and provided a way to see what other people were working on. This works out best when all members of the team update. General gameplay decisions were based on votes during meetings.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
:[Nico] Memory management mainly. Working with the audio meant attaching sounds to objects that would eventually got destroyed so keeping track of which sounds should be released was a bit painful at first.<br />
<br />
:[Amer] I thought that the collision detection would be easier but it ended up taking a lot of resources and I had to remove a lot of my optimizations due to the a speed of the Gatling gun bullets. If I had to do it over again, I would probably implement some different type of hit detection for fast objects.<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
:[Stephanie] Particle systems because they make everything beautiful.<br />
:[Nico] The auditory chaos when 4 players are trying to blow each other up!<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
:[Stephanie] Debugging shaders. General debugging approach was to pass in hard coded values to shaders and drew a giant red line in the middle of the world if expected values were received. For whatever reason, some tricks used in tutorials did not work in our code and it took a while to figure that out...<br />
:[Nico] Performance for the audio engine. Since all the sounds in the game are 3D sounds updating every sound all the time was very expensive, so implementing the logic for when, where, and how a sound should play was often frustrating.<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
: [Welander] Note that collisions logic actually resides in the server, and the collisionengine is unused.<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
:Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
:Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
==== Creating a Model ====<br />
:1) Create your model in ZBrush and save it in the default file format for further editing.<br />
:2) Export as an OBJ file.<br />
<br />
==== Texturing ==== <br />
:I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
:1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
:2) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
:3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
:4) On the left hand side click Material and pick MatCap White.<br />
:5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
:6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
:7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
:8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
:9) You can now export to an OBJ file again using Export.<br />
<br />
:Preparing for import into the game engine:<br />
:1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
:2) Export as an OPENCOLLADA *.dae file<br />
<br />
:Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
:1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
:2) Rotate the gizmo so that Y is up.<br />
:3) Export as Autodesk COLLADA.<br />
:4) Import COLLADA file.<br />
:5) Export as OPENCOLLADA.<br />
<br />
:We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
:[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
==== Audio ====<br />
:0) Buy fancy headphones since you are the sound guy now.<br />
:1) Download free sound clips.<br />
:2) Edit it down to what we needed (make a loop if necessary) in Audacity.<br />
:3) Load into game using our asset manager.<br />
:4) Attach sound to an object or event in game.<br />
:5) Explode peoples' ears during the demo.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
:From scratch.<br />
:[Nico] From scratch was awesome and it will be fun to take advantage of pre built engines as well!<br />
:[Amer] I liked it from scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
: We did not use a networking library.<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
:*Separate client game logic and server game logic. We have a shared game logic library where the files have mixed client-side and server-side code and it can get gross.<br />
:*Test in release mode throughout the last week so we don't have heart attacks throughout the hour before the demo.<br />
:[Nico] Test the audio more with the mega speakers!<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
:[Welander] I would say Math 155A<br />
:[Stephanie] CSE 167, CSE 110<br />
:[Nico] CSE 190 (3D UI)<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
:*Managing and designing large scale software system.<br />
:*People.<br />
:*Need more C++ in the cirriculum<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
:[[Gameplay Screenshots]]<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
:* Introduction to 3D Game Programming with DirectX 11: Implementing particle systems using stream out to efficiently support many particle effects.<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
:*Make your schedule as free as possible.<br />
:*Communicate frequently both in person and online.<br />
:*Meet and work together in the labs.<br />
:*Try to work in at least pairs.<br />
:*Plan a few quarters ahead to lighten your course load for spring quarter.<br />
<br />
=== 3. How can the course be improved for next year? ===<br />
:*Encourage groups to have structure so that decisions can be made with certainty and increase accountability.</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=929Final Writeup2013-06-15T23:17:34Z<p>Erik: /* 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
:[Nico] Our initial design entailed armor power ups based on an element/color but we wound up going with random element/color assignment on spawns due to time constraints. The system works out well as players are forced to adapt to their element accordingly. There were also a few items that didn't make the final cut such as a ghost item (drive through walls and be invisible) and a bomb weapon which no one really knew what it should do.<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
:[Nico] And heap corruptions.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities throughout development and provided a way to see what other people were working on. This works out best when all members of the team update. General gameplay decisions were based on votes during meetings.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
:[Nico] Memory management mainly. Working with the audio meant attaching sounds to objects that would eventually got destroyed so keeping track of which sounds should be released was a bit painful at first.<br />
<br />
:[Amer] I thought that the collision detection would be easier but it ended up taking a lot of resources and I had to remove a lot of my optimizations due to the a speed of the Gatling gun bullets. If I had to do it over again, I would probably implement some different type of hit detection for fast objects.<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
:[Stephanie] Particle systems because they make everything beautiful.<br />
:[Nico] The auditory chaos when 4 players are trying to blow each other up!<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
:[Stephanie] Debugging shaders. General debugging approach was to pass in hard coded values to shaders and drew a giant red line in the middle of the world if expected values were received. For whatever reason, some tricks used in tutorials did not work in our code and it took a while to figure that out...<br />
:[Nico] Performance for the audio engine. Since all the sounds in the game are 3D sounds updating every sound all the time was very expensive, so implementing the logic for when, where, and how a sound should play was often frustrating.<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
: [Welander] Note that collisions logic actually resides in the server, and the collisionengine is unused.<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
Audio:<br />
<br />
0) Buy fancy headphones since you are the sound guy now.<br />
<br />
1) Download free sound clips.<br />
<br />
2) Edit it down to what we needed (make a loop if necessary) in Audacity.<br />
<br />
3) Load into game using our asset manager.<br />
<br />
4) Attach sound to an object or event in game.<br />
<br />
5) Explode peoples' ears during the demo.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
:From scratch.<br />
:[Nico] From scratch was awesome and it will be fun to take advantage of pre built engines as well!<br />
<br />
:[Amer] I liked it from scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
:*Separate client game logic and server game logic. We have a shared game logic library where the files have mixed client-side and server-side code and it can get gross.<br />
:*Test in release mode throughout the last week so we don't have heart attacks throughout the hour before the demo.<br />
:[Nico] Test the audio more with the mega speakers!<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
:[Welander] I would say Math 155A<br />
:[Stephanie] CSE 167, CSE 110<br />
:[Nico] CSE 190 (3D UI)<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
:*Managing and designing large scale software system.<br />
:*People.<br />
:*Need more C++ in the cirriculum<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
:[[Gameplay Screenshots]]<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
:* Introduction to 3D Game Programming with DirectX 11: Implementing particle systems using stream out to efficiently support many particle effects.<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
:*Make your schedule as free as possible.<br />
:*Communicate frequently both in person and online.<br />
:*Meet and work together in the labs.<br />
:*Try to work in at least pairs.<br />
:*Plan a few quarters ahead to lighten your course load for spring quarter.<br />
<br />
=== 3. How can the course be improved for next year? ===<br />
:*Encourage groups to have structure so that decisions can be made with certainty and increase accountability.</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=909Final Writeup2013-06-13T16:38:04Z<p>Erik: /* 12. Please post final screenshots of your game on your group pages for posterity. */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities throughout development and provided a way to see what other people were working on. This works out best when all members of the team update. General gameplay decisions were based on votes during meetings.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
:[Stephanie] Particle systems because they make everything beautiful.<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
:[Stephanie] Debugging shaders. General debugging approach was to pass in hard coded values to shaders and drew a giant red line in the middle of the world if expected values were received. For whatever reason, some tricks used in tutorials did not work in our code and it took a while to figure that out...<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
:From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
:*Separate client game logic and server game logic. We have a shared game logic library where the files have mixed client-side and server-side code and it can get gross.<br />
:*Test in release mode throughout the last week so we don't have heart attacks throughout the hour before the demo.<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
:[Welander] I would say Math 155A<br />
:[Stephanie] CSE 167, CSE 110<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
:*Managing and designing large scale software system.<br />
:*People.<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
:[[Gameplay Screenshots]]<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
:* Introduction to 3D Game Programming with DirectX 11: Implementing particle systems using stream out to efficiently support many particle effects.<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
:*Make your schedule as free as possible.<br />
:*Communicate frequently both in person and online.<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=908Final Writeup2013-06-13T16:37:50Z<p>Erik: /* 12. Please post final screenshots of your game on your group pages for posterity. */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities throughout development and provided a way to see what other people were working on. This works out best when all members of the team update. General gameplay decisions were based on votes during meetings.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
:[Stephanie] Particle systems because they make everything beautiful.<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
:[Stephanie] Debugging shaders. General debugging approach was to pass in hard coded values to shaders and drew a giant red line in the middle of the world if expected values were received. For whatever reason, some tricks used in tutorials did not work in our code and it took a while to figure that out...<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
:From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
:*Separate client game logic and server game logic. We have a shared game logic library where the files have mixed client-side and server-side code and it can get gross.<br />
:*Test in release mode throughout the last week so we don't have heart attacks throughout the hour before the demo.<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
:[Welander] I would say Math 155A<br />
:[Stephanie] CSE 167, CSE 110<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
:*Managing and designing large scale software system.<br />
:*People.<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
[[Gameplay Screenshots]]<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
:* Introduction to 3D Game Programming with DirectX 11: Implementing particle systems using stream out to efficiently support many particle effects.<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
:*Make your schedule as free as possible.<br />
:*Communicate frequently both in person and online.<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=883Final Writeup2013-06-13T09:09:14Z<p>Erik: /* 10. Which courses at UCSD do you think best prepared you for CSE 125? */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities. This works out best when all members of the team update <br />
:General gameplay decisions were based on votes during meetings.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
:From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
:[Welander] I would say Math 155A<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=881Final Writeup2013-06-13T09:06:35Z<p>Erik: /* 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
:From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=880Final Writeup2013-06-13T09:02:37Z<p>Erik: /* 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
:Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=879Final Writeup2013-06-13T09:02:28Z<p>Erik: /* 1. Game concept: How and why did your game concept change from initial concept to what you implemented? */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
:Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=878Final Writeup2013-06-13T09:02:13Z<p>Erik: /* 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
:We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
:Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=877Final Writeup2013-06-13T09:01:51Z<p>Erik: /* 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
:[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=876Final Writeup2013-06-13T08:59:26Z<p>Erik: /* 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
[Welander] My most annoying software problem was definitely trying to rotate models using 3DS Max. The solution was to do the rotation in code instead (as mentioned in part 6).<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=875Final Writeup2013-06-13T08:57:39Z<p>Erik: /* 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from w...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
:We had a scrum based approach using Asana/Google Docs for team members to acquire tasks. The approach allowed flexibility for changing task priorities.<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Welander] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=873Final Writeup2013-06-13T08:52:21Z<p>Erik: /* 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from w...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Erik] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner, faster, and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=872Final Writeup2013-06-13T08:51:58Z<p>Erik: /* 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from w...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Erik] I found that in some cases this does not work (or messes with the lighting). In my opinion, writing some code to set a "pre rotation" of the model was a much cleaner and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=871Final Writeup2013-06-13T08:51:33Z<p>Erik: /* 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from w...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
[Erik] I found that in some cases this does not work (or messes with the lighting). I found that writing some code to set a "pre rotation" of the model was a much cleaner and easier method of fixing the y/z up issue.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=870Final Writeup2013-06-13T08:49:19Z<p>Erik: /* 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from w...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
Our game concept did not change very much. We set out to do a kart battle game and ended up with one.<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
<br />
Tools: 3DSMax, OPENCOLLADA, Assimp SDK, ZBrush 4R5, Photoshop<br />
<br />
Download Assimp SDK, and OPENCOLLADA plugin for 3DSMax<br />
<br />
Creating a Model:<br />
<br />
1) Create your model in ZBrush and save it in the default file format for further editing.<br />
<br />
2) Export as an OBJ file.<br />
<br />
<br />
Texturing: <br />
<br />
I will be going over how to texture an object in ZBrush starting from an OBJ file. This was you can also use models that you created in 3DSMax (maybe use ZBrush for texturing only). I'll be referring to the default toolset.<br />
<br />
1) Import an OBJ file. Using 'Import' The imported file should be selected as a tool. (Press ';' to close the Project Screen in the middle of your workspace)<br />
<br />
3) Right click and drag in the workspace to create an instance of your model. Do this only once! Click edit at the top. Select Rgb and deselect Zadd. <br />
<br />
3) On the right hand side scroll down the tool bar to Polypaint. Click Colorize.<br />
<br />
4) On the left hand side click Material and pick MatCap White.<br />
<br />
5) Start painting on your model. You can look up tutorials or you can just mark the areas on you model and further paint it in photoshop.<br />
<br />
6) Click on UV Map under Polypaint on the right and select your texture resolution.<br />
<br />
7) On the top bar, go to ZPlugin -> UV Master -> Unwrap. You can play around with settings if you think the unwrapped UV Map takes too much space.<br />
<br />
8) Click on Texture Map under UV Map. Click Create -> From Polypaint.<br />
<br />
9) You can now export to an OBJ file again using Export.<br />
<br />
<br />
Preparing for import into the game engine:<br />
<br />
1) Import the OBJ file into 3DSMax and make sure the texture goes on correctly.<br />
<br />
2) Export as an OPENCOLLADA *.dae file<br />
<br />
<br />
Your model will be exported at Z up no matter what you do. You can do a pre-rotation in your game engine to handle this. You can also avoid any complications by following the next steps.<br />
<br />
1) Edit your poly. Go to Hierarchy -> Affect Pivot Only<br />
<br />
2) Rotate the gizmo so that Y is up.<br />
<br />
3) Export as Autodesk COLLADA.<br />
<br />
4) Import COLLADA file.<br />
<br />
5) Export as OPENCOLLADA.<br />
<br />
We export as OPENCOLLADA because it give us nice things (binormals and tangents) for bump mapping and other fun things.<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
From scratch.<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=859MediaWiki:Sidebar2013-06-10T23:55:21Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
** Final Writeup|Final Report<br />
* SEARCH<br />
* TOOLBOX</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=858MediaWiki:Sidebar2013-06-10T23:54:32Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
** Final Report|Final Report<br />
* SEARCH<br />
* TOOLBOX</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=857Final Writeup2013-06-10T22:03:07Z<p>Erik: /* C. Finally, if you wish, I would appreciate any feedback on the course */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 3. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=856Final Writeup2013-06-10T22:01:48Z<p>Erik: </p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
=== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ===<br />
<br />
=== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ===<br />
<br />
=== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ===<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
=== 1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ===<br />
<br />
=== 2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ===<br />
<br />
=== 3. Which aspects of the project are you particularly proud of? Why? ===<br />
<br />
=== 4. What was the most difficult software problem you faced, and how did you overcome it (if you did)? ===<br />
<br />
=== 5. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ===<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
=== 6. In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ===<br />
<br />
=== 7. Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ===<br />
<br />
=== 8. For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ===<br />
<br />
=== 9. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ===<br />
<br />
=== 10. Which courses at UCSD do you think best prepared you for CSE 125? ===<br />
<br />
=== 11. What was the most important thing that you learned in the class? ===<br />
<br />
=== 12. Please post final screenshots of your game on your group pages for posterity. ===<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
<br />
=== 13. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ===<br />
<br />
=== 14. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ===<br />
<br />
=== 15. How can the course be improved for next year? ===</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=855Final Writeup2013-06-10T21:30:06Z<p>Erik: /* If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use th...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=854Final Writeup2013-06-10T21:29:51Z<p>Erik: /* If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use th...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=853Final Writeup2013-06-10T21:28:55Z<p>Erik: /* If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use th...</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
<br />
We counted the lines of code per-project, using this command in powershell:<br />
(dir -include *.cpp,*.hpp,*.h,*.hlsl,*.hlsli,*.rc -recurse | select-string .).Count<br />
<br />
Leaving us with this result: (after subtracting out 2 library files)<br />
<br />
AudioEngine: 673<br />
Client: 3837<br />
CollisionEngine: 148<br />
GameLogic: 10400<br />
GraphicsEngine: 15830<br />
InputEngine: 552<br />
NetworkingEngine: 774<br />
Server: 1141<br />
Shared: 2659<br />
-----------------------<br />
Total: 36014<br />
<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=852Final Writeup2013-06-10T21:02:27Z<p>Erik: /* Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) */</p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
Our final schedule and our projected schedule contain very few similarities. The main reason being that things we thought would be hard were easy, and things we thought were easy turned out to be hard.<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=851Final Writeup2013-06-10T21:00:31Z<p>Erik: </p>
<hr />
<div>__NOTOC__ <br />
<br />
= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=850Final Writeup2013-06-10T20:59:20Z<p>Erik: </p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =<br />
== What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed? ==<br />
== I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? ==<br />
== How can the course be improved for next year? ==</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=849Final Writeup2013-06-10T20:58:15Z<p>Erik: </p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch? ==<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=848Final Writeup2013-06-10T20:56:54Z<p>Erik: </p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect? ==<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=847Final Writeup2013-06-10T20:56:26Z<p>Erik: </p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
<br />
== Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
<br />
== What software methodology and group mechanics decisions worked out well, and which ones did not? Why? ==<br />
== Which aspects of the implementation were more difficult than you expected, and which were easier? Why? ==<br />
== Which aspects of the project are you particularly proud of? Why? ==<br />
== What was the most difficult software problem you faced, and how did you overcome it (if you did)? ==<br />
== If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid? Finally, how many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted. ==<br />
== In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? ==<br />
== Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?<br />
== For those who used a networking library (e.g., RakNet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect?<br />
== Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation? ==<br />
== Which courses at UCSD do you think best prepared you for CSE 125? ==<br />
== What was the most important thing that you learned in the class? ==<br />
== Please post final screenshots of your game on your group pages for posterity. ==<br />
<br />
<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=846Final Writeup2013-06-10T20:53:52Z<p>Erik: </p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
<br />
== 1. Game concept: How and why did your game concept change from initial concept to what you implemented? ==<br />
== 2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any? ==<br />
== 3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.) ==<br />
<br />
= B. Then address these more general questions =<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Final_Writeup&diff=845Final Writeup2013-06-10T20:52:29Z<p>Erik: Created page with "= A. In the project review document, start by addressing these main questions = = B. Then address these more general questions = = C. Finally, if you wish, I would appreciate ..."</p>
<hr />
<div>= A. In the project review document, start by addressing these main questions =<br />
= B. Then address these more general questions =<br />
= C. Finally, if you wish, I would appreciate any feedback on the course =</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=843MediaWiki:Sidebar2013-06-10T10:46:14Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
* SEARCH<br />
* TOOLBOX</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=842MediaWiki:Sidebar2013-06-10T10:46:05Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
* SEARCH<br />
* TOOLBOX<br />
* [File:SpartaCats Logo.png|130px|center|Image on center]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=841MediaWiki:Sidebar2013-06-10T10:45:50Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
* SEARCH<br />
* TOOLBOX<br />
* [[File:SpartaCats Logo.png|130px|center|Image on center]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=MediaWiki:Sidebar&diff=840MediaWiki:Sidebar2013-06-10T10:41:16Z<p>Erik: </p>
<hr />
<div>* navigation<br />
** Main Page|Main Page<br />
** Progress Screenshots|Screenshots<br />
** Reports|Reports<br />
** Downloads|Downloads<br />
* SEARCH<br />
* TOOLBOX<br />
<br />
[[File:SpartaCats Logo.png|130px|center|Image on center]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Downloads&diff=795Downloads2013-06-09T05:52:21Z<p>Erik: /* Hardware Requirements */</p>
<hr />
<div>== Requirements ==<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
* <strike>A CPU which supports [http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX AVX] instructions (we may drop this requirement).</strike> Removed from week 8 and onwards.<br />
<br />
== Downloads ==<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week7/BattleCarts_Installer.exe BattleCarts Installer, week 7] (Requires AVX support)<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week8/BattleCarts_Installer.exe BattleCarts Installer, week 8]<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week9/BattleCarts_Installer_Release.exe BattleCarts Installer, week 9]<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer, week 10]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=794Main Page2013-06-09T05:49:14Z<p>Erik: </p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
<br />
== Download ==<br />
Requirements:<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer]<br />
<br />
== Story ==<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Art and UI Design]]<br />
<br />
[[3D Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=793Main Page2013-06-09T05:10:06Z<p>Erik: /* Download */</p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
[[file:SpartacatsLogo.png|thumb|250px|]]<br />
<br />
== Download ==<br />
Requirements:<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer]<br />
<br />
== Story ==<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Art and UI Design]]<br />
<br />
[[3D Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=792Main Page2013-06-09T05:04:44Z<p>Erik: </p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
[[file:SpartacatsLogo.png|thumb|250px|]]<br />
<br />
== Download ==<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer]<br />
<br />
== Story ==<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Art and UI Design]]<br />
<br />
[[3D Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=760Main Page2013-06-09T03:06:41Z<p>Erik: </p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
:'''Reminder''': replace weekly screenshot with Spartacats logo<br />
:'''Reminder''': post youtube video when it's up<br />
<br />
== Download ==<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer]<br />
<br />
== Story ==<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Art and UI Design]]<br />
<br />
[[Object Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Downloads&diff=759Downloads2013-06-09T02:53:33Z<p>Erik: /* Downloads */</p>
<hr />
<div>== Hardware Requirements ==<br />
* Windows 7 64-bit SP1, or Windows 8 64-bit.<br />
* Direct3D 11 compatible graphics card.<br />
* <strike>A CPU which supports [http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX AVX] instructions (we may drop this requirement).</strike> Removed from week 8 and onwards.<br />
<br />
== Downloads ==<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week7/BattleCarts_Installer.exe BattleCarts Installer, week 7] (Requires AVX support)<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week8/BattleCarts_Installer.exe BattleCarts Installer, week 8]<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week9/BattleCarts_Installer_Release.exe BattleCarts Installer, week 9]<br />
<br />
[//cse125.ucsd.edu/cse125/2013/cse125g1/installers/week10/Spartacats_Installer.exe Spartacats Installer, week 10]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=714Main Page2013-06-09T00:14:09Z<p>Erik: </p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot]]<br />
:'''Reminder''': replace weekly screenshot with Spartacats logo<br />
:'''Reminder''': post youtube video when it's up<br />
<br />
== Story ==<br />
[Theresa update?]<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Concept Art]]<br />
<br />
[[Object Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Main_Page&diff=713Main Page2013-06-09T00:13:38Z<p>Erik: </p>
<hr />
<div>[[file:Mushrooms.jpg|thumb|250px|Weekly Screenshot... from maybe 4 weeks ago]]<br />
:'''Reminder''': replace weekly screenshot with Spartacats logo<br />
:'''Reminder''': post youtube video when it's up<br />
<br />
== Story ==<br />
[Theresa update?]<br />
:Long ago, aliens invaded a far away planet occupied by the Cat, Corgi, Panda, and Rabbit nations. One hero, Spartacat mastered all three elements, earth, fire, and water, to defeat them. He gained a following among the four nations and today they celebrate by using alien technology for their gladiator games.<br />
<br />
== Rules ==<br />
Vehicle combat with front weapons and rear weapons. Overall gameplay is timed deathmatch. Winner has most kills.<br />
<br />
'''Color Scheme'''<br />
*Three colors red, green, and blue represent a rock-paper-scissors scheme. (Think pokemon fire, grass, water.)<br />
*Vehicles have defensive color. Front weapons have attacking color. Rear weapons are neutral.<br />
*Color influences:<br />
:*Greater attack color => double damage. <br />
:*Same/Neutral attack color => base damage. <br />
:*Weaker attack color => heals defender.<br />
<br />
'''Player's Equipment'''<br />
*Each player can have one of each front weapon type.<br />
*Each player can only hold onto one type of rear weapon at a time.<br />
<br />
'''Weapon Types'''<br />
*Front Weapons (Dependent on color types.)<br />
:*Missile: Homes on enemies for moderate damage with special terrain-aware homing. Damage influenced by color scheme.<br />
:*Pulse cannon: Homes on enemies to stun with minimal damage. Stun time and damage influenced by color scheme.<br />
:*Gatling gun: Auto aims to spray enemy with rapid fire moderate damage. Damage influenced by color scheme.<br />
*Rear Weapons (Independent of color types.)<br />
:*Proximity Mine: Detects nearby players for high damage.<br />
:*Fire Trail: Drop a trail of fire for enemies to drive through. Damages over time.<br />
<br />
'''Shield'''<br />
*Timed with immediate activation to nullify all damage and healing.<br />
*Will nullify damage from pulse cannon but user can still be stunned.<br />
<br />
==Controls==<br />
'''Keyboard'''<br />
:Move Forward: W<br />
:Move Back: S<br />
:Move Left: A<br />
:Move Right: D<br />
:Cycle Front Weapon Left: E<br />
:Cycle Front Weapon Right: R<br />
:Fire Front Weapon: Right click mouse<br />
:Fire Rear Weapon: Left click mouse<br />
<br />
:Boost Thrusters: Q<br />
:Jump: SPACE<br />
:First Person / 3rd Person Toggle: T<br />
<br />
'''USB XBox Controller'''<br />
[Needs to be updated]<br />
<br />
== Art ==<br />
[[Concept Art]]<br />
<br />
[[Object Models]]<br />
<br />
== Project Development ==<br />
[[Group Management]]<br />
<br />
[[Development Roles]]<br />
<br />
[[Tools]]<br />
<br />
[[Documentation]]<br />
<br />
[[Logging]]<br />
<br />
== Schedule ==<br />
=== Progress Screenshots ===<br />
[[Progress Screenshots]]<br />
<br />
=== Milestones ===<br />
[[High Level View]]<br />
<br />
[[Weekly View]]<br />
<br />
=== Group Reports ===<br />
[[Group Reports]]<br />
<br />
=== Individual Reports ===<br />
[[Amer]]<br />
<br />
[[Erik]]<br />
<br />
[[Helen]]<br />
<br />
[[Jimmy]]<br />
<br />
[[Nico]]<br />
<br />
[[Stephanie]]<br />
<br />
[[Theresa]]</div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Progress_Screenshots&diff=712Progress Screenshots2013-06-09T00:12:53Z<p>Erik: /* Week 10 */</p>
<hr />
<div>== Week 1 ==<br />
<br />
<gallery widths=200px><br />
file:camera1.png|Third Person Camera<br />
file:camera2.png|First Person Camera and sky map<br />
file:ModelLoading.png|Model Loading<br />
file:BoundingBoxes.png|Bounding Boxes<br />
file:BoundingSpheres.png|Bounding Spheres<br />
file:Gui.jpg|2D Text and images<br />
file:textures.png|Textures<br />
file:Lighting.png|Lighting<br />
file:RenderToTexture.jpg|Rendering of 2D text and images to textures.<br />
file:BumpMapping.png|Bump Maps, the teapots have a grass bump-map applied to them.<br />
</gallery><br />
<br />
== Week 2 ==<br />
<br />
<gallery widths=200px><br />
file:Glowmaps.jpg|Glow Maps, parts of the texture stays lit, even in the shade.<br />
file:PointLights.png|Point Lights.<br />
file:PointLights2.png|Point light in a house.<br />
file:PointLights3.png|Multiple moving point lights.<br />
file:FixedBumpmapping.png|Realized we didn't know how to generate bump maps. Fixed it.<br />
file:MultiplePlayers.png|Working networking, multiple Players.<br />
file:MiniMap.png|Basic minimap.<br />
file:Dolphins.png|Static dolphin "projectiles".<br />
file:Multiplayer.png|3 players sitting on the height-map.<br />
file:Rotatingminimap.png|Minimap that shows relative location of other players.<br />
</gallery><br />
<br />
== Week 3 ==<br />
<br />
<gallery widths=200px><br />
file:3DHeightMap.png|A 3D heightmap makes it possible to walk below other terrain.<br />
file:SpecularHighlights.png|Specular highlights.<br />
file:Spotlight.png|Spotlights.<br />
file:Particles.png|Particle System.<br />
file:Fog.png|Atmospheric fog.<br />
file:RainbowBoundingSpheres.jpg|Rainbow colored bounding spheres.<br />
file:Particles2.png|More particles.<br />
file:Takingdamage.png|Players taking damage from each other's weapon projectiles.<br />
</gallery><br />
<br />
== Week 4 ==<br />
<br />
<gallery widths=200px><br />
file:GrassFog.png|There is fog and grass everywhere!<br />
file:Rain.png|Rain! First efficient particle system.<br />
file:Rain2.jpg|Several players sitting in the rain.<br />
file:Fire.png|Player on fire!<br />
file:FireRain.png|Fire and rain.<br />
file:Blending.png|Texture blending map for the terrain.<br />
file:Week4Screenshot.png|Fire and rain with texture blended map.<br />
file:CatWizards.png|New cat and vehicle models.<br />
</gallery><br />
<br />
== Week 5 ==<br />
<br />
<gallery widths=200px><br />
file:FrustumCullingTerrain.png|Frustum culling of the terrain.<br />
file:smoke2.jpg|Smoke and fire.<br />
file:Thrusters.png|Thruster particle system.<br />
file:ThrustersTurn.png|Thrusters adjust based on turn direction.<br />
file:VehicleColor.png|Vehicles have color types.<br />
file:AlienFire.png|Alien fire.<br />
file:Youaredead.png|Death screen. Using RE's for now.<br />
file:TerrainMaps.jpg|Applied all of our model texture maps to the terrain.<br />
</gallery><br />
<br />
== Week 6 ==<br />
<br />
<gallery widths=200px><br />
file:PowerUpColor.png|Front weapon power ups show color type.<br />
file:FrontWeaponColor.png|Front weapon shows color type.<br />
file:MuzzleFlash.jpg|Weapon fire lights up the surroundings.<br />
file:MissileParticlesNew.png|Missle projectile particles.<br />
file:PulseParticles.png|Pulse cannon projectile particles.<br />
file:VehicleExplodes.png|Death particle effects.<br />
file:Animation.png|Giant Doom model is animated.<br />
file:RotationToGround.jpg|The player is rotated to sit on the terrain.<br />
</gallery><br />
<br />
== Week 7 ==<br />
<br />
<gallery widths=200px><br />
file:Loading.png|Using random concept art as a loading screen.<br />
file:Shadows.png|Initial shadows. Still a bit buggy.<br />
file:Shadows2.jpg|Mostly fixed the shadow acne.<br />
file:Shadows3.jpg|Shadows from trees.<br />
file:PlayerList.jpg|List of connected players.<br />
</gallery><br />
<br />
== Week 8 ==<br />
<br />
<gallery widths=200px><br />
file:Mines.png|Mines align with the ground.<br />
file:Character.png|The vehicle is actually occupied now.<br />
file:Tiles.jpg|Updates player tiles with an HP bar.<br />
file:Minimap.png|Rendering of the world to the minimap.<br />
file:MuzzleFlashParticle.jpg|Gatling gun with muzzle flash.<br />
file:DeathCamera.jpg|Death camera.<br />
file:Character_Selection.jpg|Character selection screen.<br />
</gallery><br />
<br />
== Week 9 ==<br />
<br />
<gallery widths=200px><br />
file:SpotlightShadows.jpg|Shadows from spot lights.<br />
file:ElectricalDamage.png|Electrical damage for either taking damage or getting stunned.<br />
file:Shield.jpg|Shield neutralizes damage.<br />
file:PowerUpParticles.jpg|Particle system for acquiring power ups.<br />
file:NewDeadScreen.jpg|New dead screen.<br />
file:FireTrail.jpg|Fire trail weapon.<br />
file:DiffChars.jpg|Different character models.<br />
</gallery><br />
<br />
== Week 10 ==<br />
<br />
<gallery widths=200px><br />
file:Mushrooms.jpg|Final UI and Level design.<br />
</gallery></div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Progress_Screenshots&diff=711Progress Screenshots2013-06-09T00:12:44Z<p>Erik: </p>
<hr />
<div>== Week 1 ==<br />
<br />
<gallery widths=200px><br />
file:camera1.png|Third Person Camera<br />
file:camera2.png|First Person Camera and sky map<br />
file:ModelLoading.png|Model Loading<br />
file:BoundingBoxes.png|Bounding Boxes<br />
file:BoundingSpheres.png|Bounding Spheres<br />
file:Gui.jpg|2D Text and images<br />
file:textures.png|Textures<br />
file:Lighting.png|Lighting<br />
file:RenderToTexture.jpg|Rendering of 2D text and images to textures.<br />
file:BumpMapping.png|Bump Maps, the teapots have a grass bump-map applied to them.<br />
</gallery><br />
<br />
== Week 2 ==<br />
<br />
<gallery widths=200px><br />
file:Glowmaps.jpg|Glow Maps, parts of the texture stays lit, even in the shade.<br />
file:PointLights.png|Point Lights.<br />
file:PointLights2.png|Point light in a house.<br />
file:PointLights3.png|Multiple moving point lights.<br />
file:FixedBumpmapping.png|Realized we didn't know how to generate bump maps. Fixed it.<br />
file:MultiplePlayers.png|Working networking, multiple Players.<br />
file:MiniMap.png|Basic minimap.<br />
file:Dolphins.png|Static dolphin "projectiles".<br />
file:Multiplayer.png|3 players sitting on the height-map.<br />
file:Rotatingminimap.png|Minimap that shows relative location of other players.<br />
</gallery><br />
<br />
== Week 3 ==<br />
<br />
<gallery widths=200px><br />
file:3DHeightMap.png|A 3D heightmap makes it possible to walk below other terrain.<br />
file:SpecularHighlights.png|Specular highlights.<br />
file:Spotlight.png|Spotlights.<br />
file:Particles.png|Particle System.<br />
file:Fog.png|Atmospheric fog.<br />
file:RainbowBoundingSpheres.jpg|Rainbow colored bounding spheres.<br />
file:Particles2.png|More particles.<br />
file:Takingdamage.png|Players taking damage from each other's weapon projectiles.<br />
</gallery><br />
<br />
== Week 4 ==<br />
<br />
<gallery widths=200px><br />
file:GrassFog.png|There is fog and grass everywhere!<br />
file:Rain.png|Rain! First efficient particle system.<br />
file:Rain2.jpg|Several players sitting in the rain.<br />
file:Fire.png|Player on fire!<br />
file:FireRain.png|Fire and rain.<br />
file:Blending.png|Texture blending map for the terrain.<br />
file:Week4Screenshot.png|Fire and rain with texture blended map.<br />
file:CatWizards.png|New cat and vehicle models.<br />
</gallery><br />
<br />
== Week 5 ==<br />
<br />
<gallery widths=200px><br />
file:FrustumCullingTerrain.png|Frustum culling of the terrain.<br />
file:smoke2.jpg|Smoke and fire.<br />
file:Thrusters.png|Thruster particle system.<br />
file:ThrustersTurn.png|Thrusters adjust based on turn direction.<br />
file:VehicleColor.png|Vehicles have color types.<br />
file:AlienFire.png|Alien fire.<br />
file:Youaredead.png|Death screen. Using RE's for now.<br />
file:TerrainMaps.jpg|Applied all of our model texture maps to the terrain.<br />
</gallery><br />
<br />
== Week 6 ==<br />
<br />
<gallery widths=200px><br />
file:PowerUpColor.png|Front weapon power ups show color type.<br />
file:FrontWeaponColor.png|Front weapon shows color type.<br />
file:MuzzleFlash.jpg|Weapon fire lights up the surroundings.<br />
file:MissileParticlesNew.png|Missle projectile particles.<br />
file:PulseParticles.png|Pulse cannon projectile particles.<br />
file:VehicleExplodes.png|Death particle effects.<br />
file:Animation.png|Giant Doom model is animated.<br />
file:RotationToGround.jpg|The player is rotated to sit on the terrain.<br />
</gallery><br />
<br />
== Week 7 ==<br />
<br />
<gallery widths=200px><br />
file:Loading.png|Using random concept art as a loading screen.<br />
file:Shadows.png|Initial shadows. Still a bit buggy.<br />
file:Shadows2.jpg|Mostly fixed the shadow acne.<br />
file:Shadows3.jpg|Shadows from trees.<br />
file:PlayerList.jpg|List of connected players.<br />
</gallery><br />
<br />
== Week 8 ==<br />
<br />
<gallery widths=200px><br />
file:Mines.png|Mines align with the ground.<br />
file:Character.png|The vehicle is actually occupied now.<br />
file:Tiles.jpg|Updates player tiles with an HP bar.<br />
file:Minimap.png|Rendering of the world to the minimap.<br />
file:MuzzleFlashParticle.jpg|Gatling gun with muzzle flash.<br />
file:DeathCamera.jpg|Death camera.<br />
file:Character_Selection.jpg|Character selection screen.<br />
</gallery><br />
<br />
== Week 9 ==<br />
<br />
<gallery widths=200px><br />
file:SpotlightShadows.jpg|Shadows from spot lights.<br />
file:ElectricalDamage.png|Electrical damage for either taking damage or getting stunned.<br />
file:Shield.jpg|Shield neutralizes damage.<br />
file:PowerUpParticles.jpg|Particle system for acquiring power ups.<br />
file:NewDeadScreen.jpg|New dead screen.<br />
file:FireTrail.jpg|Fire trail weapon.<br />
file:DiffChars.jpg|Different character models.<br />
</gallery><br />
<br />
== Week 10 ==<br />
<br />
<gallery widths=200px><br />
file::Mushrooms.jpg|Final UI and Level design.<br />
file:DiffChars.jpg|Different character models.<br />
</gallery></div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Progress_Screenshots&diff=710Progress Screenshots2013-06-09T00:12:30Z<p>Erik: /* Week 10 */</p>
<hr />
<div>== Week 1 ==<br />
<br />
<gallery widths=200px><br />
file:camera1.png|Third Person Camera<br />
file:camera2.png|First Person Camera and sky map<br />
file:ModelLoading.png|Model Loading<br />
file:BoundingBoxes.png|Bounding Boxes<br />
file:BoundingSpheres.png|Bounding Spheres<br />
file:Gui.jpg|2D Text and images<br />
file:textures.png|Textures<br />
file:Lighting.png|Lighting<br />
file:RenderToTexture.jpg|Rendering of 2D text and images to textures.<br />
file:BumpMapping.png|Bump Maps, the teapots have a grass bump-map applied to them.<br />
</gallery><br />
<br />
== Week 2 ==<br />
<br />
<gallery widths=200px><br />
file:Glowmaps.jpg|Glow Maps, parts of the texture stays lit, even in the shade.<br />
file:PointLights.png|Point Lights.<br />
file:PointLights2.png|Point light in a house.<br />
file:PointLights3.png|Multiple moving point lights.<br />
file:FixedBumpmapping.png|Realized we didn't know how to generate bump maps. Fixed it.<br />
file:MultiplePlayers.png|Working networking, multiple Players.<br />
file:MiniMap.png|Basic minimap.<br />
file:Dolphins.png|Static dolphin "projectiles".<br />
file:Multiplayer.png|3 players sitting on the height-map.<br />
file:Rotatingminimap.png|Minimap that shows relative location of other players.<br />
</gallery><br />
<br />
== Week 3 ==<br />
<br />
<gallery widths=200px><br />
file:3DHeightMap.png|A 3D heightmap makes it possible to walk below other terrain.<br />
file:SpecularHighlights.png|Specular highlights.<br />
file:Spotlight.png|Spotlights.<br />
file:Particles.png|Particle System.<br />
file:Fog.png|Atmospheric fog.<br />
file:RainbowBoundingSpheres.jpg|Rainbow colored bounding spheres.<br />
file:Particles2.png|More particles.<br />
file:Takingdamage.png|Players taking damage from each other's weapon projectiles.<br />
</gallery><br />
<br />
== Week 4 ==<br />
<br />
<gallery widths=200px><br />
file:GrassFog.png|There is fog and grass everywhere!<br />
file:Rain.png|Rain! First efficient particle system.<br />
file:Rain2.jpg|Several players sitting in the rain.<br />
file:Fire.png|Player on fire!<br />
file:FireRain.png|Fire and rain.<br />
file:Blending.png|Texture blending map for the terrain.<br />
file:Week4Screenshot.png|Fire and rain with texture blended map.<br />
file:CatWizards.png|New cat and vehicle models.<br />
</gallery><br />
<br />
== Week 5 ==<br />
<br />
<gallery widths=200px><br />
file:FrustumCullingTerrain.png|Frustum culling of the terrain.<br />
file:smoke2.jpg|Smoke and fire.<br />
file:Thrusters.png|Thruster particle system.<br />
file:ThrustersTurn.png|Thrusters adjust based on turn direction.<br />
file:VehicleColor.png|Vehicles have color types.<br />
file:AlienFire.png|Alien fire.<br />
file:Youaredead.png|Death screen. Using RE's for now.<br />
file:TerrainMaps.jpg|Applied all of our model texture maps to the terrain.<br />
</gallery><br />
<br />
== Week 6 ==<br />
<br />
<gallery widths=200px><br />
file:PowerUpColor.png|Front weapon power ups show color type.<br />
file:FrontWeaponColor.png|Front weapon shows color type.<br />
file:MuzzleFlash.jpg|Weapon fire lights up the surroundings.<br />
file:MissileParticlesNew.png|Missle projectile particles.<br />
file:PulseParticles.png|Pulse cannon projectile particles.<br />
file:VehicleExplodes.png|Death particle effects.<br />
file:Animation.png|Giant Doom model is animated.<br />
file:RotationToGround.jpg|The player is rotated to sit on the terrain.<br />
</gallery><br />
<br />
== Week 7 ==<br />
<br />
<gallery widths=200px><br />
file:Loading.png|Using random concept art as a loading screen.<br />
file:Shadows.png|Initial shadows. Still a bit buggy.<br />
file:Shadows2.jpg|Mostly fixed the shadow acne.<br />
file:Shadows3.jpg|Shadows from trees.<br />
file:PlayerList.jpg|List of connected players.<br />
</gallery><br />
<br />
== Week 8 ==<br />
<br />
<gallery widths=200px><br />
file:Mines.png|Mines align with the ground.<br />
file:Character.png|The vehicle is actually occupied now.<br />
file:Tiles.jpg|Updates player tiles with an HP bar.<br />
file:Minimap.png|Rendering of the world to the minimap.<br />
file:MuzzleFlashParticle.jpg|Gatling gun with muzzle flash.<br />
file:DeathCamera.jpg|Death camera.<br />
file:Character_Selection.jpg|Character selection screen.<br />
</gallery><br />
<br />
== Week 9 ==<br />
<br />
<gallery widths=200px><br />
file:SpotlightShadows.jpg|Shadows from spot lights.<br />
file:ElectricalDamage.png|Electrical damage for either taking damage or getting stunned.<br />
file:Shield.jpg|Shield neutralizes damage.<br />
file:PowerUpParticles.jpg|Particle system for acquiring power ups.<br />
file:NewDeadScreen.jpg|New dead screen.<br />
file:FireTrail.jpg|Fire trail weapon.<br />
file:DiffChars.jpg|Different character models.<br />
</gallery><br />
<br />
== Week 10 ==<br />
<br />
<gallery widths=200px><br />
file::Mushrooms.jpg|Final UI and Level design.<br />
</gallery></div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=Progress_Screenshots&diff=709Progress Screenshots2013-06-09T00:12:03Z<p>Erik: /* Week 10 */</p>
<hr />
<div>== Week 1 ==<br />
<br />
<gallery widths=200px><br />
file:camera1.png|Third Person Camera<br />
file:camera2.png|First Person Camera and sky map<br />
file:ModelLoading.png|Model Loading<br />
file:BoundingBoxes.png|Bounding Boxes<br />
file:BoundingSpheres.png|Bounding Spheres<br />
file:Gui.jpg|2D Text and images<br />
file:textures.png|Textures<br />
file:Lighting.png|Lighting<br />
file:RenderToTexture.jpg|Rendering of 2D text and images to textures.<br />
file:BumpMapping.png|Bump Maps, the teapots have a grass bump-map applied to them.<br />
</gallery><br />
<br />
== Week 2 ==<br />
<br />
<gallery widths=200px><br />
file:Glowmaps.jpg|Glow Maps, parts of the texture stays lit, even in the shade.<br />
file:PointLights.png|Point Lights.<br />
file:PointLights2.png|Point light in a house.<br />
file:PointLights3.png|Multiple moving point lights.<br />
file:FixedBumpmapping.png|Realized we didn't know how to generate bump maps. Fixed it.<br />
file:MultiplePlayers.png|Working networking, multiple Players.<br />
file:MiniMap.png|Basic minimap.<br />
file:Dolphins.png|Static dolphin "projectiles".<br />
file:Multiplayer.png|3 players sitting on the height-map.<br />
file:Rotatingminimap.png|Minimap that shows relative location of other players.<br />
</gallery><br />
<br />
== Week 3 ==<br />
<br />
<gallery widths=200px><br />
file:3DHeightMap.png|A 3D heightmap makes it possible to walk below other terrain.<br />
file:SpecularHighlights.png|Specular highlights.<br />
file:Spotlight.png|Spotlights.<br />
file:Particles.png|Particle System.<br />
file:Fog.png|Atmospheric fog.<br />
file:RainbowBoundingSpheres.jpg|Rainbow colored bounding spheres.<br />
file:Particles2.png|More particles.<br />
file:Takingdamage.png|Players taking damage from each other's weapon projectiles.<br />
</gallery><br />
<br />
== Week 4 ==<br />
<br />
<gallery widths=200px><br />
file:GrassFog.png|There is fog and grass everywhere!<br />
file:Rain.png|Rain! First efficient particle system.<br />
file:Rain2.jpg|Several players sitting in the rain.<br />
file:Fire.png|Player on fire!<br />
file:FireRain.png|Fire and rain.<br />
file:Blending.png|Texture blending map for the terrain.<br />
file:Week4Screenshot.png|Fire and rain with texture blended map.<br />
file:CatWizards.png|New cat and vehicle models.<br />
</gallery><br />
<br />
== Week 5 ==<br />
<br />
<gallery widths=200px><br />
file:FrustumCullingTerrain.png|Frustum culling of the terrain.<br />
file:smoke2.jpg|Smoke and fire.<br />
file:Thrusters.png|Thruster particle system.<br />
file:ThrustersTurn.png|Thrusters adjust based on turn direction.<br />
file:VehicleColor.png|Vehicles have color types.<br />
file:AlienFire.png|Alien fire.<br />
file:Youaredead.png|Death screen. Using RE's for now.<br />
file:TerrainMaps.jpg|Applied all of our model texture maps to the terrain.<br />
</gallery><br />
<br />
== Week 6 ==<br />
<br />
<gallery widths=200px><br />
file:PowerUpColor.png|Front weapon power ups show color type.<br />
file:FrontWeaponColor.png|Front weapon shows color type.<br />
file:MuzzleFlash.jpg|Weapon fire lights up the surroundings.<br />
file:MissileParticlesNew.png|Missle projectile particles.<br />
file:PulseParticles.png|Pulse cannon projectile particles.<br />
file:VehicleExplodes.png|Death particle effects.<br />
file:Animation.png|Giant Doom model is animated.<br />
file:RotationToGround.jpg|The player is rotated to sit on the terrain.<br />
</gallery><br />
<br />
== Week 7 ==<br />
<br />
<gallery widths=200px><br />
file:Loading.png|Using random concept art as a loading screen.<br />
file:Shadows.png|Initial shadows. Still a bit buggy.<br />
file:Shadows2.jpg|Mostly fixed the shadow acne.<br />
file:Shadows3.jpg|Shadows from trees.<br />
file:PlayerList.jpg|List of connected players.<br />
</gallery><br />
<br />
== Week 8 ==<br />
<br />
<gallery widths=200px><br />
file:Mines.png|Mines align with the ground.<br />
file:Character.png|The vehicle is actually occupied now.<br />
file:Tiles.jpg|Updates player tiles with an HP bar.<br />
file:Minimap.png|Rendering of the world to the minimap.<br />
file:MuzzleFlashParticle.jpg|Gatling gun with muzzle flash.<br />
file:DeathCamera.jpg|Death camera.<br />
file:Character_Selection.jpg|Character selection screen.<br />
</gallery><br />
<br />
== Week 9 ==<br />
<br />
<gallery widths=200px><br />
file:SpotlightShadows.jpg|Shadows from spot lights.<br />
file:ElectricalDamage.png|Electrical damage for either taking damage or getting stunned.<br />
file:Shield.jpg|Shield neutralizes damage.<br />
file:PowerUpParticles.jpg|Particle system for acquiring power ups.<br />
file:NewDeadScreen.jpg|New dead screen.<br />
file:FireTrail.jpg|Fire trail weapon.<br />
file:DiffChars.jpg|Different character models.<br />
</gallery><br />
<br />
== Week 10 ==<br />
<gallery widths=200px><br />
file::Mushrooms.jpg|Final UI and Level design.<br />
</gallery></div>Erikhttps://cse125.ucsd.edu/2013/cse125g1/index.php?title=File:Mushrooms.jpg&diff=708File:Mushrooms.jpg2013-06-09T00:11:03Z<p>Erik: Week 10: Final level design.</p>
<hr />
<div>Week 10: Final level design.</div>Erik