Blipzkrieg Released

We are pleased to announce that Blipzkrieg is now available at Armor Games!

This is a great accomplishment for us, and we are all thankful to our friends, families, supporters, testers, and our sponsor: Armor Games.

 

What the Users Are Saying

Perfect. Just perfect. I love everything- the stealth, the music, the graphics, and the gameplay. This is great. If I could pay for this, I would.
-Geenf11

The timeless struggle between squares and circles XD. I don’t get why people rate RTS’s so low…
-SCOninja

@SCOninja, RTS’s get low ratings because people are lazy, and they dont want to be activeley clicking the mouse ^^, and while the controls for this game could b a little annoying i was extrememly addicted, tho i was stukc on the level “absolute power”. 9/10 so simple, yet so addicting ^^
-werthyman

Pretty good puzzle game with a little bit of action, Alot of elements that encourage teamwork as a way to proceed trought the game. Great graphcis, very nice soundtrack and sound effects, and great gameplay. This game in my opinion is 9/10.
-fantasy4life

I DEMAND MORE LEVELS!
That was definitely one of the best games i have played in a while, i wish you would make a new game with more levels! 10/10
-peaceman101

Dudes this game was so addictive. It has a good way of making you adapt to each situation, so well that you sorta evolve with the game. Which in turn gets harder with each level, but seems to avoid being stale. Something thats free and keeps my attention for an hour is A OKAY in my book.
-Loki31784

Honestly quite a beautiful game. First off, I love the concept of starting as one small blue orb but eventually gathering captives of the grey thingy. Alongside the music and the last level, I absolutely love it! 10/10
-awilliams4124

Halfway through and LOVING it. Generally I hate those games where you send out troops, capture a base and win the level.

But this game is a bright future for me. It uses SOME of that gameplay idea, but adds more stuff to it and overall makes this a wonderful game. Simple enough, nice graphics, its fun. Truly a joy to play.
-Solatoral

Already @blipzkrieg is cutting into my “midnight internet not sleeping right time” and I’m only on level 5. Yes!
-@redblockdrop

A glowing video review…

Whats Next?

In the coming weeks we’ll be working to get Blipzkrieg available to as many people as possible, including continuing the development of the mobile version! Thanks to everyone for the reviews, retweets, and ratings!

What’s New at GameClay

Blipzkrieg iconGameClay has been humming with activity since our last blog entry. We’ve worked on many interesting projects, technologies, and IPs. There’ll be some of our code in an upcoming release from Playdom, a sprinkling of our mojo in Racer on the Android Marketplace from Luma Arcade, my own special brand of ‘wisdom’ in #AltDevBlogADay (and on Gamasutra), and the expertise of the talented Alex Scarborough in an announcement at the Structure Conference. But we are most excited to announce our first, original title Blipzkrieg!

Blipzkrieg

Blipzkrieg is a fast-paced, retro-themed arcade-strategy game. As leader of the circle armies, you lead your troops through mazes, and around defensive towers, capturing power-stations and bases to reach the portal in the fastest time possible. It’s best seen, instead of described, so take a look at our gameplay trailer.

Blipzkrieg on Vimeo

The game is currently seeking a primary sponsor on Flash Game License and once that process is complete, we will be launching the game on Blipzkrieg.com, as well as several Flash portals. We designed the game with tablets in mind, and there are exciting announcements in that arena which I’ll save for another day. We’re just as anxious to get Blipzkrieg available to the public, as you are to play it. Much thanks to all our testers who provided invaluable feedback throughout the process.

What’s Next at GameClay

In the upcoming weeks, we will be talking about the lessons we learned during development of Blipzkrieg, and exciting announcements about where we’re going next with it. You can stay informed about Blipzkrieg at facebook.com/blipzkrieg, @blipzkrieg on Twitter, as well as our blog here. We’ll even put one of those easy-to-embed ‘Like’ boxes right here for you! Until next time, just remember: Circles Good, Squares Bad!

Working with Git at GameClay

Our resident Git Evangelist, Alex Scarborough, has been our workflow consultant for this project. This workflow incorporates our version control, bug tracking, and Build Server. This workflow makes concurrent development of multiple features by multiple developers easy and manageable.

Why Git?

Git is a relatively new version control solution initially designed and written by Linus Torvalds. It's absurdly fast, absurdly small, and it has a system model from which all functionality is derived. A git repository is a directed acyclic graph; a graph where nodes are connected directionally, and it's impossible to make a circle. Each commit is a node, merges are nodes with multiple parents, and a branch is caused by two (or more) nodes with the same parent. (well there's more to it than that, but lets leave it there for now). 

To put it simply: git works; really-really well…and it's free. If you want more reasons, check out: http://whygitisbetterthanx.com/

Our Workflow

We are taking advantage of the easy (and functional) branching capabilities of Git to power our workflow. For each feature, or tracked-bug, we make a branch. 

Each branch we create is named in the format: initials/feature_name or initials/bug-# For example: pw/bug-3 or pw/Torque3D_Beta_Merge

Here is a section of one of our graphs that represents my workflow over the course of a week:

What is this madness? Time moves from left-to-right, with the numbers (in the grey bar) representing the 8th through 16th of this month. The black line represents the master branch. Each of the other colored lines represent feature, or bug-fix branches that occurred in parallel. Each dot is a commit. When a branch is merged back in to master, it is done so in a single commit. 

Why Use Feature-Branches

Using this workflow seems obtuse, at first. It is very important to discard any previous notions of branch-merging on other version control solutions. It is very easy to maintain several, simultaneous branches in development (as can be seen above), and switch between them without issues. Git commits by 'blob', not by file. This means that the same file can contribute to several branches, and several revisions in the same branch.

Using feature-branches means that you can create incremental commits during the development of your feature or bug-fix. Making atomic commits makes development much easier to manage. You can use git revert to easily undo changes, and it is very easy to go back and review how you, or someone else, developed a feature. 

Checking in a bug-fix

Merging the feature-branch back into master is done using the –no-ff flag. This tells git not to "fast-forward" the merge; guaranteeing the creation of a single "merge-commit" with two parents. This keeps all of the incremental commits in their own branch, and integrates the whole branch with master in a single commit, with the message: Merged branch 'branchname'

This makes it very easy to revert an entire bug-fix or feature with a single git revert. Performing a git revert with the SHA of a feature-branch will create a single, new commit that undoes that feature-branch; it does not remove or modify any previous commits. This allows you to go back and easily look at the development process of that feature, and hopefully easily spot, and fix, your mistake. 

Keeping your development off the master branch allows multiple developers to be working on multiple features, and never have a commit conflict with their local features in-development. Performing a git pull will always resolve cleanly if you do all feature development in branches. Personally, I often have several branches active at the same time, and I may even be committing blobs from the same file, to different branches. 

Integrating with Bug Tracking

After some evaluation, I picked Lighthouse for our bug tracking solution. Lighthouse is a hosted, web-based, minimalistic bug-tracking solution with a very powerful API, GitHub integration, and a Ruby interface lib. This solution has a minimum number of bug fields, and uses tags for the rest of the information. It fit my model for the build system perfectly. It is specialized, easily expandable, Ruby-based, and hosted (as a bonus). 

Our workflow bug-fix branch naming convention makes it possible to easily parse out bug-fix branch merges. All bug-fix branches are named in the format initials/bug-# and these merges are done using the –no-ff flag, so a bug-fix will always go into the codebase with a single-commit, and the message will be: Merged branch 'initials/bug-#'

Uttu Interacting with Lighthouse

To facilitate the integration of our version control, and bug tracker with our workflow, we created a GitHub Post-Receive Hook server, Uttu. This server is wired in to all of our bug-tracked projects (it can manage multiple GitHub repositories and Lighthouse projects). As the README talks about in more detail, the server is managed by CI Joe. When we check in a change to the Workflow server, CI Joe will install the new version, and restart the service. I will discuss the development, and testing of this tool in a future blog.

 Ruby |  copy code |? 
01
02
payload['commits'].each do |commit|
03
 
04
  # Look for bug fixes
05
  if commit['message'] =~ /Merge branch '.*\/bug-(\d*)'/
06
    begin
07
      ticket = Lighthouse::Ticket.find($1, :params => { :project_id => repoconfig['lighthouse_id'] })
08
      ticket.state = 'resolved'
09
      ticket.body = "Fixed by #{commit['author']['name']}.\n#{commit['url']}"
10
      puts "Marking ticket #{$1} fixed (#{commit['message']})" if ticket.save
11
    rescue
12
      puts "Error updating ticket #{$1} (#{commit['message']})"
13
    end
14
  end
15
 
16
end
17
I mentioned, previously, that I looked for tools which had good Ruby interfaces. The small chunk of code, above, is the meat of the Workflow server. It iterates the commits it receives from GitHub and does a regular-expression match on the commit message, looking for bug-fix merges. When it finds a commit that matches, it looks up the Lighthouse project id based on the GitHub repository name, then finds, and marks the associated ticket resolved. It adds some text to the ticket, and then saves it back to Lighthouse. As you can see from the commit history of the Workflow server, I wrote the initial implementation in an evening. Ruby is a fantastic environment for your build system.

Going Further

This has only scratched the surface of our workflow, and our plans for the Workflow server. Subsequent blogs will discuss finding bugs using git bisect and other workflow processes, as well as development, testing, and additional features for the Workflow server.

Build it Like GameClay

One of our best friends, in game development, is the build server. The build server makes clean builds when we forget. It keeps our artists supplied with up-to-date binaries. The simple things we just assume will always work, it will test without complaining. I thought I’d take some time and share some of the lessons we have learned in the past, and how we build our projects.

Why Use a Build Server

Why use a build server? You’ve got version control, why not just check in binary files? Most version control software is based around text files, and does not handle binary data very well. Since version control software will try and ensure that any version of a given file can be recreated, it will store a large amount of differences in binary files. This will quickly eat-up space in your version control. If you use a distributed version control solution, this is especially bad. 

Our projects include a BAT file that allows non-coders to pull down the latest binaries from the build server, and unpackages them into the recipients working copy; .gitignore contains entries for these files. This prevents repository bloat, and ensures that an up-to-date binary is always available. It provides a consistent platform on which to build; using the same SDK versions, compilers, and dynamic C libraries each time.

A previous game project, imported from SVN, created a 4GB Git repository, for what was a ~300MB game directory. This previous project checked in ZIP files of archived assets, and distributed builds to artists by checking builds in to the SVN repository. This was close to a worst-cased scenario, but if you don’t believe the bloat, just think about how many differences a 100MB ZIP file of a deploy-able package would incur each update. Using a distributed version control solution means that each developer would be downloading, and storing a 4GB package. 

You should never check your game builds into your version control repository, and you should prefer using text-based file formats for assets whenever possible. Instead, with proper use of version control, and a build server, you can generate binaries and packages using any current, or past version of your project.

A Little Help From Our Friends

We are game developers, not service hosts. The best service is the kind someone else can host; companies that do hosting as their business. We chose to manage our own build hardware, but use hosting providers for all our other needs. There are some wonderful projects out there, that are critical to our work-flow.

Our precious source code is hosted by GitHub (we will talk about Git, and our work-flow, in future development blogs). GameClay has a paid account that is used only to create, and manage repositories; only the build servers have an RSA keys linked to this account. I manage the GameClay GitHub account in my “off browser”; either Safari or IE since I am a Chrome user and this helps to avoid any badness with cookies and sessions. 

The Build Server

Our server is a 16-core Nehalem Xserve with 12GB of RAM running off an 128 SSD, using a DroboPro for a Time Machine target. Our office does not have a dedicated server room, instead we use a Kell Systems PSE12. It is well soundproofed, thermal controlled, and it also makes a great printer table! We use Parallels Server to host virtual build machines for Xbox360, Windows, Mac and Linux builds. CI Joe gives us an easy-to-use, easy-to-extend, continuous integration server, runnable on all platforms. 

This machine is almost entirely firewalled to the outside world, and only provides shell access through RSA-key authenticated SSH. The limited, externally accessible web services are located on virtual machines, and are backed up by Time Machine. Mac OS X Server is very easy to maintain, and because it needs so little external visibility, I burn almost no time administrating our limited, internal services.

The GameClay fork of CI Joe adds the ability to send push notifications to an iPhone using Prowl, and some other features. CI Joe listens for GitHub to send information from a Post-Receive Hook, and will automatically perform a build every time there is a push to the repository. When a build is successful, it packages the required binary files, and makes them available for our non-coders.

By Our Powers Combined…

So what do these nodes, wired together with a little Ruby contribute to our development process? Well first of all: it works, I set all up in less than a man-week (accumulated over time), and most of the elements are hosted by people with better bandwidth, redundant everything, and great security. 

A consistent build platform allows us to dodge issues with D3DX DLL’s and Visual Studio run-time libraries that plague teams of coders who all work in their own, personal development environments. 

During development of a previous PC title, we delivered incremental updates via a patcher solution. This worked fine until one release magically broke for around 20% of our user-base. The culprit? A different developer had done the build, and was linking with a different version of DirectX, requiring a different D3DX DLL. Our solution at the time? Make the same developer do the builds. This was inconvenient many times, like if the testers needed a build, and he was not at his computer, or if he was on vacation and we needed to do an emergency fix.

With a build server, the official binary comes from one place, one place only, and it is always available. It allows developers to do what developers do: try out new tools, and new versions without compromising the ability to deliver an up-to-date build at any time. By using virtual machines, we have given ourselves the ability to create several versions of environments and make the most of the hardware we do host in-house.

Knowing is Half the Battle

I chose to use services and projects which are specialized in purpose, like CI Joe, GitHub, and Lighthouse (more on our bug tracking in a future post).  In my experience, you always want to tweek something, or add one tiny feature to your build system. All of these projects use Ruby for their functionality, and this is intentional. 

A common interface between all the required pieces of your build system is very advantageous. Elements of the system can easily be modified and integrated with each-other and Ruby is host to a powerful set of tools to build new elements. Among them: Sinatra provides an amazing platform to write custom web services, and grit brings the battle-tested Git interface that powers GitHub. 

The project isn’t complete yet, but we do have a build system that meets our needs with a minimum investment of set-up time, and maintenance. It’s ability to stand up to a full game development cycle is yet to be proven. We refined our process many times during our time at GarageGames, and each iteration improved our workflow. This has been the easiest, and most flexible build system set-up by far. 

We will be making more blog posts about our development process during this still-unannounced game project. We hope this will help small game teams gain the advantage of some of the great, open (and closed) source friendly, services and tools that make our lives easier. 

GameClay Moves In

GameClay started off the new year by moving in to our new downtown Eugene office. We are now located at 30 E. Broadway, Suite 160; just downstairs from our friends at Mad Otter Games.

We kicked things off, on January 1st, with some assembly (but this did not involve registers; it was the bad kind of assembly). Due to a slight misunderestimation about the size of Pat’s car, we were without tops to our desks for the following week.

Pat’s mother and brother came in and started work painting some nicer tones on the wall, and hanging our “whiteboards”. We are using tileboard paneling that can be found at home supply stores. It is around $12us for an 8′x4′ section. It doesn’t erase as nicely, but it will save a good bit of cash. Keep some alcohol-based cleaner around when it gets dirty; vodka does work in dire situations.

Next the experts painted our logo on the wall by using an overhead projector, and some good fine-motor skills (we will do a full write-up on this process soon). We acquired the essentials: mini-fridge, and couch, and started moving hardware into the office.



With no space for a server room, we chose to use a Kell Systems ComputerVault Pro PSE12. This heavy-duty piece of equipment arrived in a 400lb shipping crate. Due to another misunderestimation about what exactly a ‘crate’ was, we spent 30 minutes opening the container using a screwdriver and small hammer in the back alley. This enclosure keeps our hardware cool, quiet, and makes a classy corner table to boot! If you order one of these, make sure you bring tin-snips, and a crow-bar the day it arrives.

You can check out all the pictures of office construction over in the set on Flickr. We will have some exciting announcements in the coming months!

Announcing GameClay

For Immediate Release:

Former GargageGames Developer Forms GameClay

Industry Veteran to Focus on AAA Solutions for Torque
Eugene, OR – September 15, 2009 – GameClay LLC today announced its formation. Using the award-winning Torque development platform, GameClay will provide affordable, AAA development solutions for Xbox 360 and PS3 developers.

Former GarageGames developer Pat Wilson, who has partnered with his former employer to bring Torque and other tools to major console platforms, founded the company.

“We’re really pleased to have Pat’s tremendous skills and talent continuing to push Torque forward,” said Brett Seyler, GarageGames’ Vice President of Business Development. “Pat not only knows the technology inside and out, but already has years of experience porting Torque technology and Torque-powered games to different platforms. This is a perfect fit for us and our licensees.”

Pat Wilson has been part of the Torque development team since before its public launch in 2001. Since then he has ported the best-selling engine to the Xbox and Xbox 360. All told, Wilson has developed nine Torque titles across six different platforms, including Xbox Live hit Marble Blast Ultra.

Announcing its official formation at the Austin Game Developers Conference in 2009, GameClay has quickly begun work on Torque products and tools for the Xbox 360 and Playstation 3. Wilson’s goal is to bring game developers the highest quality solutions for console development at an accessible cost. “Torque provides console developers with a proven technology to achieve next-gen results,” said Pat Wilson. “You don’t have spend seven figures or be in Mark Rein’s Rolodex to get your hands on world class development tools and technology.”

GameClay.com is now live and provides more information about GameClay products, documentation, and a link to GarageGames.com site where the engine and tools can be purchased.

About GameClay
Founded by industry veteran, Pat Wilson, GameClay provides world-class game development technology and services. GameClay is located in Eugene, Oregon and on the web at www.gameclay.com

About GarageGames
Best known as the as the makers of Frontline award-winning (2008) Torque 3D and Frontline award-nominated (2005) Torque 2D, Torque’s cross-platform technology has been selected by studios around the globe to bring hundreds of titles across every genre to market. The most widely licensed game engine technology in the industry, Torque has been licensed by Electronic Arts, BioWare, NCsoft, Activision and Ubisoft as well as hundreds of educational institutions around the world. Torque is carving out new space for developers to quickly bring quality products to emerging platforms by offering a consistent tool set for rapid iteration and easy deployment to Windows, Mac, Wii, Xbox 360, PS3, PSP, iPhone, Facebook and GarageGames’ own InstantAction web-based gaming service.

GarageGames is headquartered in Eugene, Oregon with offices in Portland, OR; Las Vegas, NV.  To learn more, please visit us on the web at www.garagegames.com

Links and Media
GameClay
Torque 3D
Torque-powered Titles
Torque 3D Logos – Dark / Light

Torque 3D Screens:

###

Contact: Pat Wilson
pat@gameclay.com

Click here to download this release as an Adobe Acrobat PDF

Welcome to GameClay

Welcome to the temporary website for GameClay, a new company founded in Eugene, Oregon.