Blogs - ArchaicMage

When I started working on Space Miners for Dream Build Play, I began with the same new-project process that I do with all my web projects.

git init

Little did I know that after a short while, I was going to run into some not so litte problems later on.

I think I speak on behalf of every programmer when I say that there is a sense of clarity when starting a new project. With no pre-existing design choices dictating the direction a project must go, the possibilities of writing a scalable, perfectly architected system sit waiting directly in front of you.

So why GIT; Why not SVN or Mercurial? For starters, I have never worked with Mercurial, and while knowledge of code-versioning transfers pretty well I did not want to spend the time learning a new code-versioning tool when I already had years of experience with the former candidates.

I chose GIT over SVN for its distributed nature.Since each local copy of my project is itself a git repository, I am able to work and commit changes without network access to my repository, and sync it with my remote origin later. SVN is completely dependent on acess to remote origin in order to commit changes, so if I were to work away from network access, I would simply be forced to sit on pending changes until I had the ability to commit to remote origin.

Unfortunately, GIT does not play extremely well with large binary files. To accomodate this, GIT offers LFS or (Large File Storage) which replaces large files with text pointers inside GIT, while storing contents on a remote server. Unfortunately I did not really find out about GIT LFS until my repository on BitBucket was over the 2Gb hard-limit, and my repository was set to read only. This was exacerbated by the fact that for some of my project, I used a tool called GitKraken, which DOES NOT contain support for GIT LFS. This meant that for some of my commits, the large files were commited to my project without GIT LFS, increasing my repository file size considerably. These files in question were primarily contained within a large audio package, but by the time I noticed, these files were already committed way back in my project history, and I would need to use a tool like git filter-branch or the BFG Repo-Cleaner.

In the end, I was almost ready to push my project to Unity Cloud Build anyways, and really just needed one last push to remote origin, so I opted to create a new repository on BitBucket, push my code once and wire up Cloud Build, since I was no longer making code changes to my project, the read-only enforcement on the repository was not an issue.

Several months ago I began my trials and tribulations; switching away from Leadwerks and C++, to work with Unity3d. Despite mixed emotions from learning a new development platform / production pipeline, and many many hours sifting through documentation and tutorials (both written and video) I have come out way ahead of where I was previously. After 14 individual builds (that I actually kept track of), and many hours of play-testing I have finally accomplished the development of a project ready to be submitted to the Microsoft Dream Build Play competition ending December 31, 2017. As I write this post, I do not feel much accomplishment. On a weekly basis I find myself sifting through the other projects submitted to the DBP gallery only to find myself questioning my work of art. Asking myself questions like, "Is my project really entertaining?", "Is my project innovative enough to stand out to the judges?".

To be honest, I have no idea if my game will stand out or provide entertainment. I know from my play-sessions that my friends seem to enjoy themselves, tossing aside idle banter and name-calling in a last minute attempt to gain the upper hand, but I can only hope that what I submit is good enough to impress.

I am building a game called Space Miners, which is a couch co-op space-brawler featuring a king-of-the-hill game mode called Conquest. Players attempt to establish influence over planet(s) by capturing and controlling the zones that surround each planet, while eliminating opponents attempting to do the same. Each point captured passively generates CP; and when a player gains 60 CP before time runs out to, he or she wins the match.

I chose to develop a co-op space-brawler so I could avoid writing networking code, avoid managing split-screen, etc, and simply focus on developing mechanics and gameplay while continuing to learn Unity3d. As a single member team I knew I needed to bite off a smaller project in order to learn, and be successful. Too many times in my past I have joined a game development competition and had nothing to submit, and I wanted to avoid the same outcome this time at any cost. So far, I feel as though I have been fairly successful.

I took my Agile practices from my work and best applied them to my Space Miners project using Toggl to keep track of my time, TinyPM to keep track of my requirements and manage my two week iterations. My project was developed using Unity3d technologies, writing all my code in Visual Studio 2017 backed by ReSharper with several other plugins.

Below, you will find a collection of all the tools I've found useful in my development. I hope that you may find use to them as well!

• Unity3d 2017.x
• Visual Studio 2017 Professional with ReSharper
• Visual Studio Code (https://code.visualstudio.com/)
• Toggl (https://toggl.com/)
• TinyPM (http://www.tinypm.com/)
• GIT for version control (https://git-scm.com/)
• BitBucket for source code hosting (https://bitbucket.org/)