Not too much to report today. I've had a pretty busy week with CS4400 and life in general, so I didn't get much done outside of class. Here are the things I did do(including class):

Got the team up to speed on the level editor design. It went pretty well, but we won't know how good or bad the design is until we jump into the work(which I am hoping for a full lab day today so that we can collaborate on the ideas.

All of our CS guys have been able to update to git, which I have fully merged yesterday. We also uploaded the level editor into our project, so the group should be able to easily download the code without any real work. I think that now we have a firm base on workflow, we should be plowing through from here on out.

Lastly, I reviewed the Evil list a little bit. I do believe that its a doable list to work around but some of the things that we have to guarantee really sucks(like absolutely no bugs, whatsoever). I guess we will see how this goes but I plan on bringing it up in the Stand-Up meeting.

Read More...»

Several things have happened.

First we've made some major progress on git. Casey, Nate, and Jeremy have both been able to push updates to the game(nothing major, yet), and all have said that its easier than it seems(which is how I feel too). This gave me an opportunity on learning how to merge the code, as well as resetting the HEAD of the current branch, along with editing remote branches(I feel these are all important for someone who is running the entire system).

On top of this, I wrote a design doc that further defines our level editor from the original definitions. This can be found here:

https://docs.google.com/document/edit?id=1moFbTO3htIemgeUpa1-shcrvQ-NwvlS5rE-fLFVWfR4&hl=en&authkey=CP760_gN

Me and Nate have started with writing the code, and have defined a Level(integrated with the Editor Interface that I mentioned in the doc), and an Entity. This is all minus the ability to import and export, as that is still up in the air on agreement with the group.

More on this later.

Read More...»

Do not attempt this tutorial before I demonstrate on Thursday(10-20-10)

Ok so the task here in this tutorial is to continue to help you get familiar with Git, by actually making changes in the repo. This is assuming you have set up Git already(See here) and that you have an understanding of VIM or have changed the editor to Notepad++(See here).

Disclamer:
As I know someone is going to run into the problem, I thought I would warn you: be sure that your msysgit is INSIDE of your Gravity-Shift folder before trying these commands. This is important because it won't work otherwise.

Okay, the first thing you need to do before you make any changes(to avoid merge conflicts) is to fetch the latest data from MY Git repo. To do this you do this command:

git fetch upstream

This will get all the newest files and changes that the team has made in a whole. At this point, you have these changes locally, but you have not applied it to your own version yet(so if you opened one of the changed files, you would not see any changes). To receive these changes, you must merge the code with this command:

git merge upstream/master

Stop for a second
Why "upstream/master" ? Well, what we are saying is that we want to merge the code from upstream's master branch. If we start using lots of branches(ones for specific bugs, ones for stable releases, etc) this will be important to understand, but for now always do "upstream/master"

We now have the newest code on the computer, which we should now see "ContactList.txt" in the Gravity-Shift folder. Open this and add your contact information into it. Do not forget to save.

The next thing you need to do is commit your changes. Simply do this command:

git commit -a

Which will prompt you for a commit message. This is REQUIRED, and would be best if you do clear messages so that your code is easier to review. The correct format is always "Present Tense" sentences, using words like Add, Remove, and Change instead of Added(Adding), Removed(Removing), and Changed(Changing). Try to be persistent on this format.

After you committed, you need to push your changes.

Alright, woah...
What is the difference between commit and push, and why do I need to do both?

Commit finalizes any local changes on your own local distribution. This means what ever changes you make are official on your own hard drive and that's it. Push, on the other hand, copies those changes into your Github repo(the one online) so that it can be shared with the rest of the team. It is very important to understand that these are separate things, and that committing does not always mean that you need to push as well. You should always commit any changes on a regular basis, but you should only push when you are ready to share with the rest of the team.

So to push your local changes to your online repo, use this command:

git push origin master

Ahh, another weird command
Calm down, we are just saying that we want to push our changes to origin(which is our personal repo's) on its master branch.

VERY LAST STEP!!!!
Go to my repo(See here) and in the upper right corner you will see a button that says "Pull Request" . Press this button, and fill in the popup box with your changes(same format as commit messages) and send it off. I will then be able to take your code and merge it into the main repo so everyone can receive the changes.

Read More...»

So, while using msysgit, you will more than likely end up using VIM to write text at least once(unless you change it, which I will tell you how to do that at the end of this tutorial). A good example of when VIM is required is during a commit. The editor is extremely difficult to understand, especially without any instructions, which is exactly what this tutorial is for.

Lets make an assumption that I just made some change to the code; how bout I added the ability for the player to change colors. Once I had the job finished, I would commit:

git commit -a

This would immediately start the text editor, VIM. It would have a print out something like this:

(Your cursor should be here)
#############################
# You made a change that needs to be committed
# The following files have been changed
# (To reset to head, use git reset HEAD)
# WindowsGame1/Player.cs
@
~
~
~

Or something like this at least. Your cursor should be at the very top, if its not, you'll need to move it using the arrow keys.

1. Press the letter i to enter Insert Mode.

2. Type your message: Add player ability to change his color

3. Press the Escape key to exit Insert Mode

4. We now want to save. Type :w (do not forget the : in front of the w) and press enter

5. To exit VIM, type :q (do not forget the : in front of the q) and press enter

Your file will then report to git that you are done writing the commit message and are now ready to commit.

As a final reference, to start VIM with a file(it will be a new file if it doesn't exist yet) type this command:

vi

To difficult?
Yeah I agree, that's why I went in search of a different solution, which I will share with you. Be sure you have dowloaded Notepad++(found here) and type this command in msysgit:

git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' multiInst -notabbar -nosession -noPlugin"

So the git config --global core.editor tells git you want to change the text editor. The 'C:/Program Files (x86)/Notepad++/notepad++.exe' is the location of Notepad++ so it might be different for you. You will have to browse your computer for the Notepad++.exe.

Read More...»

As I mentioned, I was tasked with the opportunity to define what a "Physics Engine" would need, and how we would define it. I came up with this here:

The physics engine is built with 3 levels.

Top Level - Gravity Direction Control
---Attributes

* Gravity Direction

---Functionality

* Change Gravity Direction

Second Level - Physics Environment
---Attributes

* Gravity Magnitude
* Terminal Speed
* Gravity Erosion
* Directional Magnitudes


Third Level - Physics Objects
---Attributes

* Gravity Force
* Additional Force
* Velocity
* Position

---Functionality

* Update itself
* Load itself
* Collision Detection
---With other objects
---With the world
* Enforce Terminal Velocity


This is actually all subject to change(and will, most likely)

As a test of the theory, I rewrote some of the engine to reflect this model, and it works pretty well. Most changes that will need to be made is going to be initiated by what the rest of the group decides on their definitions(things like the level definitions and such).

Read More...»

Alright, we are finally starting to make progress on the good stuff, which makes me very excited. The first exciting thing is that we have just about everyone understanding, at least the basics of git. The art people are going to struggle a bit with this, so I'm working on a new tutorial that uses TortoiseGit or maybe some other GUI that makes it easier on them. Hopefully I can find a good middle ground for them.

Actually, what I was thinking was that maybe we should break our project up for the art people. In the main repo(the one that contains all the programming) add the Content folder to the .gitignore file. From there, make a second project that just contains the Content folder. This way, the art people would not get any of the extra files that they would normally be attacked with, and we could just pull from their repo when any changes are made. I'm still on the edge about it because I'm pretty worried about how well that idea would even work, but it should definitely keep things as abstract and seperate as possible which is a good thing.

The second thing I'm excited about is that we gave out jobs on Thursday, in which the members of our team have to break up all the generic ideas that we came up with for a BETA version of our game. This should be what makes our product backlog and I feel like its going to really help move us forward by the time we meet up again on Tuesday. I've started us a wiki at:

http://github.com/DizWARE/Gravity-Shift/wiki/Gravity-Shift-Development-Wiki

so that anything we come up with is always readily available to all of us at anytime. As for my task, I was given the Physics Engine since I've already brainstormed on the many things that a physics engine would need.

Read More...»

So I haven't updated my blog this week which is a big oops because I have actually done quite a bit over the weekend, so this will actually go over both the progress I've made between Thursday(10/1) to Tuesday(10/4) and the progress made between Tuesday(10/4) to Thursday(10/7).

Thursday(10/1) to Tuesday(10/4):

Sat down with the code again. The problem with the original physics engine prototype is that if I were to add 10 physics object into the environment, they should all react exactly the same in that environment. So I restructured a bunch of the PhysicsObject code, and have made a new PhysicsEnvironment code that gets passed to the PhysicsObject as a reference. Now, if the player changes values in the PhysicsEnvironment, then any other PhysicsObject that has that same environment will also experience the change. This method may be subject to change(maybe PhysicsEnvironment 's own all PhysicsObjects that are within it, and update each object every time the game updates).

During class: We brainstormed what needs to go on our backlog, which I think came out fairly well. The list is being managed by Curtis(Scrum Master), and we also talked about a very important aspect of keeping things together; Source Control. We decided to use Git, which I was actually the only member who has used Git. I managed to convince everyone on it, and our tasks to do by Thursday is to learn the system.

This morning (Wednesday 10/5) I wrote a tutorial for everyone on how to get Git up and running, and how to use it. Link is here:
http://dizgames.blogspot.com/2010/10/git-instructions-for-team.html

Read More...»

Also, just a note(I'll probably bring this up thursday), as just users of the git repo, this should be your process for setting up(using a command line git program):

Step 0: Create a Github account

You need a github account before you can do anything. Go to github.com to get it

Step 1: Set up your SSH keys

You'll be pulling your hair out if you miss this step. Be sure to read it carefully. This is assuming you are using msysgit(which I still recommend for the cs people)
http://help.github.com/msysgit-key-setup/

Step 2: Fork Project

Forking the project is pretty easy. Go to http://github.com/DizWARE/Gravity-Shift/ and click the "Fork" button near the top on the right side

Step 3: Clone Repo

git clone git@github.com:(Your Github Username)/Gravity-Shift.git

This will automatically add this git repo to as your remote upstream/downstream, under the alias "origin"

Step 4: Add the original repo for fetching the newest updates

cd Gravity-Shift
git remote add upstream git://github.com/DizWARE/Gravity-Shift.git
git fetch upstream

This will add the main git repo for global updates, under the alias "upstream"

At this point, you should not have to do the Steps 1 - 4 ever again(unless something happens). From here on out should be your update cycle for anytime you make any changes.

Step 5: Make modifications

Adding/removing code or any files(images and such) will do this

Step 6: Committing your changes

git commit [Filename/s]
to commit one or more file

or

git commit -a
to commit all files

This will immediately start the default text editor(usually 'vi') to add a commit message.
Always, always, always fill out your commit messages, so that when you try to update your code on the main repo.
These commit messages should all be in present tense(important) and should start with a brief description on what is changed, and then a list of all changes. Here's an example after I added the ability jump in the physics engine, and the controls for it in the control scheme(hypothetical):

Add the ability to jump in the game
-Add the physics definitions for jumping in the physics engine
-Add the controls for jumping in the control schemes

Step 7: Push updates up to your fork

git push origin (branch name)

(branch name) is usually master if you have not created and checked out a different branch. So basically, if you don't know, use 'master'

Step 8: Sharing your updates with everyone

In github, go to http://github.com/(Your Github Username)/Gravity-Shift.git and click the "Pull Request" button in the upper right hand corner

Step 9: Getting peoples updates from git

git fetch upstream
git merge upstream/master

Lastly, for those who are still doubting on the WHY of git, take a look at this video of Linus(inventor of git, and also the inventor of Linux): http://www.youtube.com/watch?v=4XpnKHJAok8
Skip ahead a bit, because he gets into the details near the end.

Read More...»