Now that your teams have been established we'll look into a more elegant method for managing your source code. Up until now you've probably solved your problem of managing code amongst multiple team members by passing around source code through scp or email. While this may work without much overhead for 2-3 member teams, it will probably not be very efficient for 4-5+ member teams. Subversion is a tool designed to help fill this productivity gap.
Subversion (SVN) is a popular source code management system (SCMS). Like other SCMS, Subversion was designed to help facilitate source code audits and concurrent development between multiple programmers. It is similar to SCMS such as CVS, and Git with a specific emphasis on centralized storage and ease of use. Using a client-server network architecture, clients are able to send their code modifications to a server to be checked out by other developers, as well as query additional information about file modifications made by users.
So how does SVN facilitate source code auditing and concurrent development? First, SVN provides a database of all your code that can be accessed by anyone of your team members anywhere provided they have internet access and an SVN client. Code may be easily checked in and out of an SVN server by authorized clients allowing for around-the-clock access and modification. No longer will you have to worry about having a stale copy of the code; through one simple command you will be able to update to the latest and greatest version of your project code.
Because the source code is centrally maintained within a database, a history of all code commits exist. If a bug is introduced between commits SVN provides tools that will help display exactly which changes occured between file revisions as well as who was responsible for the changes. If necessary, your current version of the code may be rolled back to a previous version very easily.
Lastly, concurrent development introduces a problem known as a conflict. This occurs when two people working independently make conflicting modifications to code and both try to commit their changes without being aware of the others commit. The tradional approach to this problem has been to manually pass in both copies of the file into diff to see where the problems lie and then fix the code by hand. While SVN will not automatically fix the conflict for you, it will let you know where those conflicts are and tag them for you so that you may easily locate and resolve them.
Let's begin by first creating a repository for your team. Only ONE member from your team will need to do this. Login to the
right side of the
CS dept webpage
where it says Student and Staff Login.
In here you should find a link entitled Subversion Manager.
Go into the manager and click Add a New Repository. Give it a name
and a description. If you did this correctly you should now be
taken the repositories page and be able to see your repository in the list.
The next step will be to allow your teammates read/write access to the repository. Click the perms link next to your repositories link. Go ahead and begin adding your group members to the permissions list. Once that is done, ensure that is says edit under the view and edit column for each team member so that they may write as well as read the contents of your repository.
Great! Now everyone should have access.
For this lab I will introduce the following important SVN commands that you will undoubtably find use for during this quarter:
A free book which covers every aspect of Subversion is available here. Everything we cover today may be referenced in Chapter 2: Basic Usage.
For this portion of the lab you will need to do the following within your team:
More detail and a demonstration will be provided during lab.
Last week we looked at how to export meshes from Blender. To construct our simple scene last time we procedurally hard coded the attributes of each entity, light, and camera directly within the source code. While procedural level generation is sufficient for certain types of games (e.g. puzzle games), it is not well-suited for very detailed interior and exterior environments where careful placement of objects by an artist is required (procedural placement is still suitable for certain types of regularly placed objects such as foliage, rocks, clouds, trash).
Today we will look at how we may leverage Blender to not only create our meshes but also to generate our levels. We will do this through the DotScene XML scene format . Creating our levels will be as simple as placing our game objects in Blender, exporting out the DotScene XML format, and populating our scene manager with the objects specified in the file. A class will be provided to do the last part.
Go ahead and download the starter code from here. Most of the code should resemble that of lab 1 with the exception of the new DotScene parser. Since a DotScene file named Scene.xml does not exist in the media file, the program will crash on start. I will give you a quick demonstration of how to generate this DotScene file in Blender.
To begin constructing your scene you will first need a few meshes. You may create your own or download them from the internet from various free 3d model sites. An excellent source for themed untextured meshes may be found at 3dchaya.com. For this lab applying materials to your meshes will not be required as it may be a time consuming process, however you are free to do so if you wish.
Once you have acquired your set of meshes, the next step will be import them into Blender and export them out to .mesh files (like last time). Be sure that when you export the mesh that you don't have a material files which redeclare existing material names declared in other material files (if you do, OGRE will abort). You can avoid this by making sure that all of your materials have different names before exporting. If you share materials between meshes you may have to manually remove duplicates entries.
Now you can begin to construct your scene. If you wish to have multiple instances of one particular mesh, select the mesh you wish to duplicate, and in object mode press ALT-D. This will duplicate the object and not the mesh. This will not only save space, but cut down on the number of meshes you need to export out. With instancing, if you try to modify one mesh all other objects which share that mesh will be modified as well. Object transformations performed in object mode (scale, rotate, translate), however, are unique to each object.
Once you have your scene set up go to the scripts editor and under the export
menu (same place as last lab) you should see an OGRE Scene option.
Select this. Next, select the objects which you want to see in OGRE, set the export path,
and the RotX field to 90. The file will automatically be exported as Scene.xml. Now go ahead
and place it anywhere in your media folder. If all went well ogreapp should now greet
you with your scene.
The last requirement will be to move a character around the screen using keyboard input. This will prime us for the next lab involving collision detection. This OGRE tutorial will cover everything you need to know to meet this requirement. Not all of it might be relevant, but if you understand what everything is doing, it shouldn't be too hard to figure out the relevant portion. If you don't, be sure to ask questions.
Create a basic level using models from the net (untextured is ok) through the DotScene format.
There should be a couple of objects in your scene (buildings, or characters), a ground (a simple mesh), and a skybox. For the objects, there should be at least 2 meshes with 2+ instances per mesh.
Finally, you should be able to control one character within your scene using the keyboard.