shawn's blog

Some Git and some Unity (and a little Redmine too)….(Deux)

Posted in Other, Unity by Shawn on March 27, 2012

Last time, new Unity project was started, as well as an initial commit, and a few extra ones. Now to add a remote repository!

Remotes are great for a number of reasons. If you’re working with other people, you can add their repository as a remote, and pull in the changes that they made to their project into your own project. It’s more common, however, to have one remote repository, and have members push & pull from that repo to share work. There are a few caveats that people need to be aware of (trying to fix merge conflits), but it’s generally painless, unless you and your coworker(s) are completely out of synch.

So, now to set up a simple remote repository. We’ll want to do this somewhere, well, remote, and not on the local machine. Redundancy is useful, especially if a local machine decides to crash, and you have another machine that you can work on. Also, the aforementioned working as a team; quickly pulling in changes is nice. What I’m going to do, is set up my remote repository within Redmine directory, for reasons I will explain later. Currently, I use Lindoe, and it’s been great to me so far. So, let’s say I’m in my online Redmine folder, and want to create a new remote repo:

[shawn@remote ~]$ cd Redmine/gitRepos/testRemote/
[shawn@remote  testRemote]$ mkdir testRemote.git
[shawn@remote  testRemote]$ cd testRemote.git/
[shawn@remote  testRemote.git]$ git init --bare
Initialized empty Git repository in /home/shawn/Redmine/gitRepos/testRemote/testRemote.git/
[shawn@remote testRemote.git]$ ls -al
total 40
drwxrwxr-x 7 shawn shawn 4096 Mar 26 21:20 .
drwxrwxr-x 3 shawn shawn 4096 Mar 26 21:20 ..
drwxrwxr-x 2 shawn shawn 4096 Mar 26 21:20 branches
-rw-rw-r-- 1 shawn shawn   66 Mar 26 21:20 config
-rw-rw-r-- 1 shawn shawn   73 Mar 26 21:20 description
-rw-rw-r-- 1 shawn shawn   23 Mar 26 21:20 HEAD
drwxrwxr-x 2 shawn shawn 4096 Mar 26 21:20 hooks
drwxrwxr-x 2 shawn shawn 4096 Mar 26 21:20 info
drwxrwxr-x 4 shawn shawn 4096 Mar 26 21:20 objects
drwxrwxr-x 4 shawn shawn 4096 Mar 26 21:20 refs
[shawn@remote  testRemote.git]$

This is the same thing done to set up the local repo, except, it’s bare. Within the local repo, there’s a folder called ‘.git’. When a bare repo is created, you’re basically creating a repo with only the contents of the .git directory. You’ll want to set up a bare repository for your remote repo. I also could have cloned my local repo, but made a bare clone, then copy that to the remote machine.

Now, to tell our local machine about this repository. To do this, you can run ‘git remote –add’, with a few more details after ‘add’. The command is git remote add “remoteName” [URL]:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git remote add mainRemote shawn@remote.org:/home/shawn/Redmine/gitRepos/testR
emote/testRemote.git

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git remote -v
mainRemote      shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
(fetch)
mainRemote      shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
(push)

The remote name, is what we’re going to call this remote, and the URL is the path to the .git folder. Git remote -v shows the remote repositories that have been set up. We can see that the newly set up remote is on that list. Time to push the local repo to the remote:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git push mainRemote master
Counting objects: 21, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (21/21), 11.30 KiB, done.
Total 21 (delta 9), reused 0 (delta 0)
To shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
 * [new branch]      master -> master

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$

(We had to specify the master branch for this first push. Later on, we can just say ‘git push remoteName‘ and be done with a push)

So, now, we have a remote repository which has everything we did locally. Fun times. Now, if someone wanted to, they could clone the remote repo onto their machine using ‘git clone‘. I’m to clone the remote repo on my Desktop:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ cd ..

shawn@SHAWN-PC ~/Desktop
$ git clone shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
Cloning into testRemote...
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 21 (delta 9), reused 0 (delta 0)Receiving objects:  61% (13/21)
Receiving objects:  71% (15/21)
Receiving objects: 100% (21/21), 11.30 KiB, done.
Resolving deltas: 100% (9/9), done.

shawn@SHAWN-PC ~/Desktop
$

I had to specify the URL of the online repo, ending the URL in .git. Let’s take a look at the log for this clone repo:

shawn@SHAWN-PC ~/Desktop
$ cd testRemote/

shawn@SHAWN-PC ~/Desktop/testRemote (master)
$ git hist
* [45bcf31] 2012-03-26 (HEAD, origin/master, origin/HEAD, master) | Another Great
Update
* [21adf6e] 2012-03-26 | Initial Commit

shawn@SHAWN-PC ~/Desktop/testRemote (master)
$

It’s the same history for the original repository that was set up! It would make more sense if I cloned this onto a different computer, of course. Also, when you clone a repository, it automatically the source URL as a remote repository called origin.

shawn@SHAWN-PC ~/Desktop/testRemote (master)
$ git remote -v
origin  shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
(fetch)
origin  shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
(push)

You can rename this if you would like, using git remote rename [old name] [new name]. You can also make changes here, push to the remote repository, then have other people pull the changes that you pushed. Now, this is being oversimplified, and for a better understanding of some of these features, I strong suggest sources such as Git Immersion and Pro Git.

With Redmine, you’re able to add a repository for a specific project to track. You can do this within the Settings –> Repository section of your project within Redmine. Remember that url for the bare repo I created? Let’s get that, and add it to the page:

Adding the remote to a project

(Note: The repo needs to be within the actual Redmine directory on the machine with Redmine. For more info, check out this page). Now, we have a new tab next to Settings called “Repository”. On that page, we’ll see the repository’s details, such as the Assets and Project Settings Folder. Clicking on the folder, or the corresponding “+” icon, will show you the contents of that folder.  Now, anytime someone pushes changes to this remote repository, the changes will be reflected on this page.

On the repository page

On the repository page

As others probably know, Unity does come with its own Version Control System, the Asset Server. It is a very nice tool, and definitely useful. I’ve used it during game jams, and the speed of the asset server is wonderful. For something fully integrated into Unity, you’d expect it to be that good. However, there are some things that I do find useful about using other version control systems over the Asset Server (at least, for now).

For example, you can’t really use the Asset Sever in any type of way outside of Unity. As far as I know, there aren’t many project management tools you can use with Unity, which are also integrated (however, this one looks very good). I can, however, easily use Unity and Git and Redmine together, without too much of a drop in the workflow, compared to just using the Asset Server.

For example, within Redmine, I can create a task (called issues in Redmine), something along the lines of “Make Project Great!”. After creating this issue, Redmine will assign it a number. I now have task “Issue #277: Make Project Great”.

Making the project great

So, now to Unity. After ‘x’ hours, I’ve made a bunch of changes to my project, all of them related to issue #277. So, I save my work, and commit this to my local repository. But, let’s make the commit look like this:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Assets/Example.cs
#       modified:   Assets/ExampleScene.unity
#
no changes added to commit (use "git add" and/or "git commit -a")

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git add .

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git ci -m "Did really cool things; refs #277"
[master 1b2b47e] Did really cool things; refs #277
 2 files changed, 4 insertions(+), 6 deletions(-)

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$

The ‘ref #277’ does what one may assume it does. It references issue #277 in Redmine. Rather, it will, once I push it to the remote repository. So….

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git push mainRemote
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.58 KiB, done.
Total 5 (delta 2), reused 0 (delta 0)
To shawn@remote.org:/home/shawn/Redmine/gitRepos/testRemote/testRemote.git
   45bcf31..1b2b47e  master -> master

And after pushing, let’s take a look at our repository page in Redmine again:

Changes on the Repository page

The commit message shows up, and the ‘#277’ is linked. If we click on it, we’re brought directly to the issue we created beforehand. And now, we can even see this commit show up on that page:

Changes on #277

This can turn out to be very useful for larger projects, or projects which see a good number of updates a day. It’s relatively easy to lose track of a project, and if something goes wrong, there’s a lot of visual feedback to help track down which commit caused the problem, and what part of the project someone was working on when that specific commit caused the problem. Of course, it’s only as good as the people using the tools. If no one keeps track of what they are doing, then it’ll be a bit more difficult to track down bugs and similar negative issues. There are other ways to interact with your issues through commits, such as close issues through commit messages as well — git commit -m “Made game great!; closes #24” , then push your changes to the server — which will close the task, and let everyone know that you’re finished making the game great if they were to look at the task.

Now, of course, there are a number of things that you need to be aware of. While Redmine is free/open source, you do need to set it up on a machine. This means man hours with trying to set it up, and money for a machine to host it. It all depends on what you’re willing to sacrifice!

That’s it for this 2-parter. What I covered is really just the surface. There’s a lot more to be uncovered, and definitely things that could be made better/more optimized/etc. But hopefully someone finds something here useful to some degree.

Comments Off on Some Git and some Unity (and a little Redmine too)….(Deux)

Some Git and some Unity (and a little Redmine too)….(Uno)

Posted in Other by Shawn on March 21, 2012

Quite often on this blog, I talk about the tools that I use, those tools being Redmine, Git, and Unity 3D. I do mention how I use them together, but never in detail. Today, I’m going to talk a bit more about some of these things. With each of these areas, it’s quite easy to get lost in a world of features, so I’ll going to be a bit broader in this post. Maybe, in the future, I’ll go into more detail about a specific aspect.

Disclaimer: I am not a pro at Git, Redmine or Unity. I just like them all a lot.

So, one of the first things that I should probably mention is how cool version control really is. Regardless of whether you are working with a team, or on your own, version control is something worth looking into. Bundled with the fact that a lot of these are freely available, there really shouldn’t be too much of an excuse as to why you aren’t using version control (in my opinion, of course). My choice for a vcs is Git. I learned how to use Git from my day job, and I’m glad I did. I don’t know too much about the other options, so I’m not going to say anything like “Git is better than ‘X’ for reasons 1, 2, etc”. I’ll leave that job to sites like this one.

Previous version of Unity did not allow users of the free version of Unity to use external version control. However, that changed with the latest release of Unity 3.5. This was a positive for me, as I had a few projects that I just decided to stick entirely in version control. Now, nothing major went wrong, since I was working along, and I was able to do some funky things (like downgrade a project!), but since 3.5 allows non-pro users access to an external vcs, a lot of weight has been lifted off of my shoulders. And I’ve been talking more with others about working with a team, as we would be able to share files without odd hacks.

If you want to grab Git, you can do here. Again, I’m not planning to go into too much detail with how to use Git. Which is super easy to use, and strikingly fast. For a quick, but useful crash course on Git, check out Git Immersion. For more details about Git, and some of the crazy things you can do with it, I’d recommend Pro Git. As a side note, I’m also going to do things on the command line.

Let’s set up a local repository. I made a new Unity project, which only has one example script, and a blank scene. What we want to do is initialize the repository. So, let’s change directories, and do just that.

shawn@SHAWN-PC ~
 $ cd Desktop/TestProject/
shawn@SHAWN-PC ~/Desktop/TestProject
 $ git init
 Initialized empty Git repository in c:/Users/shawn/Desktop/TestProject/.git/
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Cool, we now have a repo! Time go branch, merge, cherry-pick, stash, log, etc, right? Unfortunately, no. Let’s take a look at what’s in this current repo.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 #
 # Initial commit
 #
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       Assets/
 #       Library/
 #       ProjectSettings/
 #       Temp/
 nothing added to commit but untracked files present (use "git add" to track)
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Git status’ will show me the current state of my working directory. Let’s also change the directory, and take a look under the Assets Folder.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ cd Assets/
shawn@SHAWN-PC ~/Desktop/TestProject/Assets (master)
 $ ls
 Example.cs  ExampleScene.unity
shawn@SHAWN-PC ~/Desktop/TestProject/Assets (master)
 $

I have a couple of files that are currently untracked, waiting to be put into version control. However, we don’t want to commit anything just yet. If you’re going to use Git (or any external vcs for that matter), and Unity, you’ll want to do is to enable external version control. To do this, we want to go to Edit –> Project Settings –> Editor. The inspector tab will reveal a few options. Change the first option to “Meta Files”. Once you do this, your project will automatically generate the proper .meta files that need to be ‘versioned’.

Enable Meta Files

Now, let’s take a look again at the files under the Assets Folder.

shawn@SHAWN-PC ~/Desktop/TestProject/Assets (master)
 $ ls
 Example.cs  Example.cs.meta  ExampleScene.unity  ExampleScene.unity.meta
shawn@SHAWN-PC ~/Desktop/TestProject/Assets (master)
 $

We can see now that we have a few new files, ending with .meta. These files are important, and will definitely be stuck into the version control system. Basically, when you add/create a new file in Unity (and have external version control enabled), Unity will generate the corresponding .meta file.

Okay, so we’re almost there. Let’s commit our files. We only want to commit two sets of things. Everything under the folder ProjectSettings, and everything under the Assets Folder (unless your workflow demands otherwise). Everything else, we can ignore. There are a few ways to go about this. The first would be to move everything to the staging area. To do this, we would run ‘git add .‘. The ‘ . ‘ specifies that we want to add everything. So, doing this (after changing back to the main project folder) would result in:

shawn@SHAWN-PC ~/Desktop/TestProject/Assets (master)
 $ cd ..
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git add .
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 #
 # Initial commit
 #
 # Changes to be committed:
 #   (use "git rm --cached <file>..." to unstage)
 #
 #       new file:   Assets/Example.cs
 #       new file:   Assets/Example.cs.meta
 #       new file:   Assets/ExampleScene.unity
 #       new file:   Assets/ExampleScene.unity.meta
 #       new file:   Library/AnnotationManager
 #       new file:   Library/AssetImportState
 #       new file:   Library/AssetServerCacheV3
 #       new file:   Library/AssetVersioning.db
 #       new file:   Library/BuildPlayer.prefs
 #       new file:   Library/BuildSettings.asset
 #       new file:   Library/EditorUserBuildSettings.asset
 #       new file:   Library/EditorUserSettings.asset
 #       new file:   Library/FailedAssetImports.txt
 ..........

All of these files are now ready to be committed to the project. But this isn’t want we want to commit. We only want everything under the Assets Folder and the ProjectSettings folder. So, let’s reset this. If you already had a commit in your history, you’d be able to run ‘git reset’, and be done. But since I haven’t commit anything yet, I’m going to need to run git rm -r –cached *‘  to reset the staging area. After running this, everything will be set to as it was before we ran git add . ‘.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git rm -r --cached *
 rm 'Assets/Example.cs'
 rm 'Assets/Example.cs.meta'
 rm 'Assets/ExampleScene.unity'
 rm 'Assets/ExampleScene.unity.meta'
 rm 'Library/AnnotationManager'
 rm 'Library/AssetImportState'
 rm 'Library/AssetServerCacheV3'
 rm 'Library/AssetVersioning.db'
 ..................
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 #
 # Initial commit
 #
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       Assets/
 #       Library/
 #       ProjectSettings/
 nothing added to commit but untracked files present (use "git add" to track)

Okay, now let’s just add those specific folders, and files within them. We could stage things individually, like so:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git add Assets/Example.cs

or, we can add the entire folder:

shawn@SHAWN-PC ~/Desktop/TestProject (master) $ git add Assets/Example.cs

Now, if we run git status, we can see that we have a bunch of files ready to be committed:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$ git st
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   Assets/Example.cs
#       new file:   Assets/Example.cs.meta
#       new file:   Assets/ExampleScene.unity
#       new file:   Assets/ExampleScene.unity.meta
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       Library/
#       ProjectSettings/

shawn@SHAWN-PC ~/Desktop/TestProject (master)
$

We can do the same thing for the ProjectSetting Folder. After we stage everything we want to stage, we’ll commit our files. We can run ‘git commit -m’, and after the -m part, include our commit message within quotation marks. So….:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git commit -m "Initial commit"
 [master (root-commit) e143bb3] Initial commit
 15 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 Assets/Example.cs
 create mode 100644 Assets/Example.cs.meta
 create mode 100644 Assets/ExampleScene.unity
 create mode 100644 Assets/ExampleScene.unity.meta
 create mode 100644 ProjectSettings/AudioManager.asset
 create mode 100644 ProjectSettings/DynamicsManager.asset
 create mode 100644 ProjectSettings/EditorBuildSettings.asset
 create mode 100644 ProjectSettings/EditorSettings.asset
 create mode 100644 ProjectSettings/InputManager.asset
 create mode 100644 ProjectSettings/NavMeshLayers.asset
 create mode 100644 ProjectSettings/NetworkManager.asset
 create mode 100644 ProjectSettings/ProjectSettings.asset
 create mode 100644 ProjectSettings/QualitySettings.asset
 create mode 100644 ProjectSettings/TagManager.asset
 create mode 100644 ProjectSettings/TimeManager.asset
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

So, we commit a bunch of stuff! Lovely right? Let’s look at our log.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git hist
* [e143bb3] 2012-03-20 (HEAD, master) | Initial commit

Git hist is an alias that I set up for the git command git log. There’s a bit more formatting details that I won’t get into, but it makes everything look pretty:

Git log made 'pretty'

After looking at the history, we can see that our log contains the initial commit with the message.

Let’s run ‘git status’ again:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       Library/
 nothing added to commit but untracked files present (use "git add" to track)

Looks like there’s some of stuff that we don’t want to track. In fact, we just want to ignore it. Well, there’s a nice file that we can create called ‘.gitignore‘, which will do that for us. You can open up whatever editor you want, name a file .gitignore, and add the files you want git to…well, ignore. Let’s take a look at some of the files I have in my .gitignore:

.gitignore
 Assembly-CSharp-vs.csproj
 Assembly-CSharp.csproj
 Assembly-CSharp.pidb
 Library/
 TestProject-csharp.sln
 TestProject.sln
 TestProject.userprefs

In this file, I’m ignoring everything under the Library folder, some of the files generated when opening up MonoDevelop, an IDE that comes Unity, and the .gitingore file itself. If I had Unity on two machines, and was doing work on both of them, I may consider leaving the .gitingore line out of the .gitignore file. But, I’m not sure if that would be wise at this point.

Edit: As pointed out by kLinus (and some others), it’s probably better practice to not ignore the .gitignore file most of the time. There may be files that most people should ignore, and it wuld be easier if they didn’t have to set up the .ignore files on their end.  Also, a more transferable version of what to put in .gitignore could look like this:

*.csproj
*.pidb
*.sln
*.userprefs
Library/
Temp/

The Temp folder is created and destroyed when you open/close Unity, so if you happen to commit files while Unity is still open, you won’t run the risk of including Temp files. I’ve also heard talk of people saying that it’s better to close Unity before committing. I’m sure closing Unity is safer, but I don’t have any reasons to promote why committing while Unity is open is bad.

There are a few more thing you can do in regards to ignoring files. If you want to ignore things that everyone should ignore, then .gitignore is a good place to add things, and you can go and commit the .gitignore files. However, if there are files that you want to ignore, but everyone else may not want to, you can add your files to .git/info/exclude. This may be useful for specific files generated by an editor, or a platform specific program (the help and credit for that goes to a coworker of mine).

 

So, we create our file, save it, and run git status again:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 nothing to commit (working directory clean)
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Now, we don’t need to worry about a Git tracking a bunch of other things. If we made this file before we made our first commit, we could have ran ‘git add . ‘, and only have Git add the files under Assets and ProjectSettings.

Okay, now we’re ready to work on our Unity project some more. Let’s say some changes were made to the example script, such as a Debug.Log statement added, or some new variables. After saving the script, you’ll see something happen after running ‘git status‘ again:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 # Changes not staged for commit:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #       modified:   Assets/Example.cs
 #
 no changes added to commit (use "git add" and/or "git commit -a")
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Well, we have some modified files that need to be committed. Here, you can see that these file are already tracked by Git. If we made a new file, for example, called NewScriptTwo, and saved it, Git would tell us we also have another file (and it’s corresponding .meta file), but it’s currently not being tracked:

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git status
 # On branch master
 # Changes not staged for commit:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 #       modified:   Assets/Example.cs
 #
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       Assets/NewScriptTwo.cs
 #       Assets/NewScriptTwo.cs.meta
 no changes added to commit (use "git add" and/or "git commit -a")
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Let’s stage things individually. First, let’s add the new file, commit it, and look at our log.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git add Assets/Example.cs
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git commit -m "Adding Example.cs"
 [master 9e2293f] Adding Example.cs
 1 files changed, 3 insertions(+), 2 deletions(-)
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git hist
* [9e2293f] 2012-03-20 (HEAD, master) | Adding Example.cs
 * [e143bb3] 2012-03-20 | Initial commit
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

The log shows a new commit, right on top of the first commit. Let’s also commit the other files, then view the history.

shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git add .
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git commit -m "Adding NewScriptTwo"
 [master bca80ab] Adding NewScriptTwo
 2 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 Assets/NewScriptTwo.cs
 create mode 100644 Assets/NewScriptTwo.cs.meta
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $ git hist
 * [bca80ab] 2012-03-20 (HEAD, master) | Adding NewScriptTwo
 * [9e2293f] 2012-03-20 | Adding Example.cs
 * [e143bb3] 2012-03-20 | Initial commit
shawn@SHAWN-PC ~/Desktop/TestProject (master)
 $

Looks like it’s coming along.

But that’s it for now. I’ve come to realize that this post is getting quite long, which means that it needs to be split up. Next, I’m going to do a little bit more locally, bring remotes into the fold, and look at some Redmine.

Planning for the next month

Posted in Music, OriGamInc, Other, Tone Def, Unity by Shawn on March 19, 2012

So, my laptop’s screen is definitely broken. Pretty good timing too, I guess. The last time I had laptop issues, the deadline to the IGF was quickly approaching. I was out a laptop for a good week, which meant I couldn’t do a lot of programming.

This time, the deadline for IndieCade is coming. What are the plans for IndieCade? Well, I hope to submit two games, Mr. Condyle’s Escape and Tone Def. So, the problem is, I have two games to work on, can’t work on them full time, and have no laptop. Still, that doesn’t mean that I can’t do other things, in regards to planning, designing, organizing and more. After I get my laptop back, I do plan to, as they say, ‘kick it in high gear’, I think. That means I’ll have a lot more content to share, on the design front, as well as other aspects.

By mid next week, I hope to be in full swing with my music production. In the mail, coming my way, is a new Midi Controller that I plan to use with Reason, my current DAW. Rather, I should say ‘first’ Midi Controller. All of my work with Reason has been me using my mouse and keyboard. That doesn’t mean that I’ve haven’t been able to make music that I’m unhappy with. All it means is that I should be able to make music faster, which I’m looking forward to. Hopefully, later on this week, or early next week, I should have some new musical pieces that I can share via the blog/soundcloud. For now, I’m going to continue working on a cheaper borrowed, non midi keyboard, to help me get ideas out of my head. Also, I purchased the sheet music book for various Legend of Zelda Songs.

In terms of designing, there’s a lot that still needs to be done. The part that does make me a bit upset is that I can design some things, and put them into my game, then update them based on how they appear in game. I’ll have to do some waiting before I can see my ideas and plans in production. Each time I get a free chance, I muck about in my Redmine, doing a lot of organizing. The way I work is in 2-week iterations. I assign myself a number of task that I think I’ll be able to complete within the two week timeline. More often than not, I bite off more than I can chew, which is okay for now, since I’m my own boss. But, setting these goals and iteration time periods help me keep track of what I’m doing, how long it takes for me to accomplish a task, and helps me form a nice timeline of production. It also helps me figure out where something went wrong, and who to blame it on (I can only blame it on myself….).

In terms of actual planning, I have outlined what’s needed for Tone Def, thing the player will actually see. More instruments, more instrument effects, and new level types. Also, interesting light shows (more on that in a future post, hopefully). There’s more work behind the scenes that need to be done also. I recently starting to make more and more custom editors, and there are a few other thing that would work better for me if I had a few custom inspectors in this Unity project. Such as the aforementioned light show. I’ve been thinking about going into some detail regarding some of the editor scripting. I’m still on the fence about it, since most of the time I start writing a blog update, I delete it. This is actually the third time I’ve tried to write this particular one.

But that’s it for now, before I go ahead a delete this one. I’m hoping to move at a better pace, and have something good before the IndieCade submission date. I’ve gotten some feedback from others regarding Tone Def, and it seems like other people don’t think it’s terrible!

Comments Off on Planning for the next month

Managing Assets

Posted in Other, Unity by Shawn on January 31, 2012

So, this past weekend was the Global Game Jam. I jammed up in the Philadelphia area, and it was definitely very fun. I do have plans to actually continue this, and the project is currently online here on GitHub. Fun stuff, and I can’t wait to jam again, potentially in June.

Speaking of jamming, a big thing for most people there, are the methods of collaboration. Not everyone needs to work together. Someone from the jam I attended work on a game alone, but did a really awesome job. My group took advantage of the Unity’s offer for letting free licenses use the pro version of Unity. Someone at the jam had set up the Asset Server, so we were able to share our projects that way. Very awesome indeed. I’ve heard of people using the Asset Server, and loving it, but I have also heard the opposite, were people feel as if this thing is a waste of time. I finally got to use it, and now I get to form a much better opinion.

Let’s talk about the positives that I found in my short time with the server. One was the speed. It was very *very* fast to use. The fact that it is fully integrated helps tenfold and makes the process much easier. Simply open the window (if you don’t have it tabbed), add files and commit them. This allowed me to do collaborate with my other members quite easily. I could definitely see why people would use the Asset Server.

It wasn’t all roses however. There are a number of reasons why I wouldn’t use the Asset Server for major projects. The Asset Server is fully integrated with Unity 3D. And that seems to be it. And I did search (not for too long, I will admit), but I didn’t really find anything that would lead me to believe otherwise. The install of Unity comes with MonoDevelop. However, Unity 3D doesn’t use MonoDevelop for anything regarding merges, changes, logs, etc. Yes, it does have it’s own history viewer, but the one with MonoDevelop acted much better when I used it. Actually, despite the complaints that people have against MonoDevelop, I really do like the changes that I found. In regards to version control, MD read the directory that my project was it, and found that I was using Git. Because of this, MD was able to allow me to view a number of different things, including logs, changes, blames, etc. Even funnier, and I guess potentially unsettling that information such as this is easily shared, was that m Gravatar icon show up when I was looking through the commits and changes. I do wonder how another vcs would integrate with MonoDevelop, but it’s out of the box interactions with Git was rather impressive. I’m not at my laptop right now, but I do also think I remember a history tree of my files/commits.

The asset sever, again doesn’t integrate itself well outside of Unity (from what I can find), which isn’t good if you’re using some sort of project management system to manage your files. I’ve mentioned this before, but I’m currently using Redmine to manage my work. Redmine, and things like it, are great for keeping me organized, and I’m sure getting it to work well with the Asset Server would require me to develop a set of slick skills, ones that I’m a bit too distracted to learn at the moment.

But again, along the lines of integration, with Git/Redmine, I can add/commit/push my files to a remote repo. I can also tag files related to certain task/issues that I have open. For example, I can create task #210: Bug fix for Squarebots. Once I finish that task, in my git commit message, I can close the task. This would allow others (if I were working with others), to see in Redmine, “Oh, this task that Shawn was working on is now closed. Let me now do x, y, z”. Yes, you can do this in person, text message, email, etc, but the less time you have to spend doing such, the faster production can potentially be, especially if people aren’t working in the same location. Fun stuff!

So, what’s this all mean with the Asset Server? Basically, that the level of integration outside of Unity seems to be very non-existent. Personally, I don’t think it would fly for me, as I like to keep things organized and enjoy fully utilizing project management tools to help me get work done.  Not to say that you need that, but it has certainly helped me get work done, stay organized, etc. My brain is cluttered enough as it is, and it’s nice to put a piece of it somewhere…..figuratively.

But that’s it for now.  I could go into more details and such, and of course, this is all my opinion, AND I plan to do some more research on this! For now, the Asset Sever doesn’t look like a better option than using an external vcs.

Comments Off on Managing Assets

MCE – End of Iteration 10

Posted in MCE, Music, Unity by Shawn on November 28, 2011

So what happened this iteration?

Well, unfortunately, not as much as I would have liked. This past Thursday was Thanksgiving Day, so I do understand why some things may have slowed down. But, while I did not do as much as I would have like to, (I don’t have as many assorted tasks as usual since it’s mostly grinding out levels),  the work that was completed will make future work much easier.

I spent a lot of time messing with the Custom Editor API that Unity provides, and wrote a few things to help me out. My last Redmine instance crashed, and my data with it. On that machine, I had the solutions for the games levels. For play testing, I need the solutions, and rather not spend most of my time trying to beat levels over again, as I forget solutions all the time. So, having easy access to the solutions is key. They are written down in two notebooks, but the notes are very sloppy, and the levels are not in the right order. Sometimes, when searching through the book for a level’s solution, it felt like it’d be easier to just try and solve the level rather than search through the scribbles in my notes.

Anyway, in regards to the custom editor scripts, aside from making an easy list to spawn tools I need, I’m not documenting my solutions on an external file. Very simple, but still very cool. Basically, every time I beat a level, I save the solution to the level. Easier than writing them down, not as messy, and allows me to save time when play testing consecutive levels.

I also have a new song for MCE! I’m not sure where this song will go though. I was thinking this would be set for world 3, but I’m not fully sure what world 3 will be yet. World One is ‘TheCity’ and world two is ‘TheForest’, and I have a slight idea of where I should go next.

Speaking of more musical things, I set up a SoundCloud profile, featuring ‘Less’ and another piece that I worked on some time last year. I do plan to upload more MCE work on SoundCloud for easier sharing/access etc, but two for now will suffice.

But that’s it for now. I have to seriously think of what I’m doing for the next world. And make some more music.

Comments Off on MCE – End of Iteration 10

Delays and Deadlines

Posted in MCE, Other by Shawn on September 19, 2011

I think I’ve mentioned deadlines before, or something similar to that.

Well, currently, I’m using Redmine to act as my project management tool. I had this running on a Fedora 14 (yes, ‘old’) running on Virtual Box. However, due odd setup situations and setups, things broke. And backups? Not working. While my data is still there (I need to mount the LVM, which apparently I shouldn’t have been using anyway, and search for the files), there isn’t really a great way to get my files off of the machine. So….

Enter Linode, and a new Fedora distro (15!). I have a few things running on the machine – irssi, remote git repositories, but I have yet to set up Redmine. I had a bit of a problem setting it up last time, but that was mostly due to me being foolish. Hopefully, the second time around will be much easier. This is _if_ I cannot get my files from my older machine….which would make me sad, because I have a lot of important resources on that. Right now, experiences with Linode have been good. When I more free time, I plan to play around with different types of Linux for kicks.

Anyway, the breaking of things delayed me and slightly set me back in terms of motivation, which means I didn’t get too much done every day this week. On the days that I did do something, I was happy with the results. Right now, for what I want to submit to random Indie festivals, I have all the music and art I need. I need more levels!

Oh, and I made this chart a few weeks back. It shows the result of everything the player does; what happens when you click start, pause, etc etc. It’s somewhat interesting, which is why I’m posting it.

It's what you'll do

But that’s it for now. I realized that I haven’t blogged for a while, so I wanted to update someone or anyone. But back to working!

Tagged with: ,

Comments Off on Delays and Deadlines

Roadmap – TriWeek1

Posted in MCE, Music, Unity by Shawn on May 24, 2011

Last year’s initial deadline for the IGF was October 18th. Which means that as of today, if things are similar to last year, the deadline for the IGF will be on or around October 17th. This means I have about 5 months left. 5 months may be a lot of time in…normal world time, but for me, it’s not a lot at all. Especially with my schedule of late, as the many things that call for my attention when I’m not (or even during) working on my game.

I have decided to create several roadmap iterations in Redmine, each of which last for three weeks. This should actually bring me right around to the first deadline. You are actually allowed to develop and submit past the deadline date, but only to update a game that has already been submitted by the deadline date. Even though this is true, I want to actually submit as close to a quality project as soon as possible, and leave that post-update time for fixing those wonderful bugs that seem to pop up at the right moments.

So far, I’ve only made three iterations, which span three weeks each (9 weeks total). The task are me playing it very safe, which means that while I think I may be able to reach something this iteration, I probably placed it in the next one. I rather move task up an iteration rather than push them back. I’d feel a bit more depressed if I did.

This iteration contains assignments such as fixing a lot of important bugs, modifying levels to support collectable items, and the wonderful music, something that I have been neglecting. I actually created a track and put it on the sidelines due to not liking it. A few weeks later, I created a different track, and eventually realized that I made something eerily similar to the one I made a few weeks ago. This could possibly be a sign that I should keep it, or that I should try and shoot for a different style of music. Of course,  I do not need to stick to one style, which is one great thing about being in charge.

In addition to my task, I have a nebula set up for other things that I would like to put it, but may not really find necessary/important. But, depending on how well I do, I may reward myself with including these extra features.

Somewhere within the next two iterations (6 weeks), I’m planning on putting out a more refined test version, which others can play. So, if you want to be first in line, let me know! You can also still grab the first playable build that I put out. It’s not going anywhere anytime soon.

But that’s it for now. I want to finish sorting out these roadmap details.

Comments Off on Roadmap – TriWeek1