It’s free and online! This is the book I wish I had when I started making games, and I want you to have it now!
I’ve only read the first few chapters, but already I can see this will be an indispensable resource for game programmers. The book is more low level, less on game design and more about the code at the heart of things, but it’s written beautifully and is chock full of examples.
Here are the basic steps for configuring a new TeamCity project and 2 build configurations, that will build the “AngryBots” demo that comes with unity in 2 flavors (Web and Windows).
Create a new project in TeamCity: Administration menu -> Create Project
Add build configurations per platform you’d like to build (One for Windows and another for Web Player)
Per configuration, add a build step with “Unity build runner”
That’s all there is to it! We have a basic CI system running that can automatically build Unity games in different flavors.
Optionally, A build trigger can be set per each configuration to start a build upon a source control check in. For the sake of our example the build will be started on demand from the TeamCity UI.
Here’s a list of issues I’ve come across:
In case of certain errors during the build, Unity build runner will fail to report these to the build log. I have already contacted the owner of this project, although i may attempt to fix it myself.
When building a Windows version of the game, the path given to the build runner should be the .exe file’s full path. When building a web player project, the path should be a folder name.
There are no mobile platforms (iOS/Android) available in the build runner dropdown. These are also not documented in Unity’s command line reference page (not sure if they are available).
Unity enforces a single running instance per project. The command line mode runs the same executable, and so it will fail to work when an instance of the engine is running and has the project being built open.
Unity doesn’t have a separate compiler/builder platform. The engine’s executable needs to be loaded to build the game, which can be CPU and memory intensive.
In the next post i will attempt to start exploring options of building upon this setup to add some basic automated testing of our built project, and show how it all integrates with TeamCity.
The idea of this event is simple – imagine a traditional game project with developers, designers and artists. Now press the “Fast Forward” button a bunch of times till you hit warp drive.
During the course of the weekend we had roughly 48 hours to come up with an idea for a game, and to actually develop it.
The result was Magic Ring – a (partly) working 2D game.
Here are some of my insights from the event.
These should assist fellow Global Game Jam noobs like me or any other aspiring developer that attends the event:
What Went Right:
Finished a simple game – There’s nothing more rewarding than working for 2 days with little sleep and getting something done!
Met new people – in such an environment, it is very hard not to hook up with new people and collaborate.
Game Ideas – while we worked on a single game, other game concepts were born, which may actually turn into real projects.
Experienced a real “Jam” – This is a must for anyone who wants to do game development! great atmosphere + great people.
What Went Wrong:
Precious time wasted on getting tools/syncing between team members – internet connection speed is poor. All tools/engines/whatever needed should be brought on a storage device.
We had no detailed “Game plan” – A 48 hour project should be simple enough to breakdown into all fine details upfront. This could’ve helped us spot potential issues that we ran into when it was getting too late.
We did not stay focused enough – We had many ideas for extending and improving the game. Looking back, the most important thing is to create the basic functionality first before moving on to improving/adding new features and complexity.