Balance

Original Author: Byron-Atkinson-Jones

The indie-game panel

I recently took part in a panel at this years Develop conference in Brighton. A lot of the topics centred on the subject of work-for-hire and more importantly, how do you balance that along with creating games that your company set out to make. This is a subject that is very close to my heart at the moment because in my particular circumstance this balance has been lost and it’s mostly leaning towards the work-for-hire camp. This was not by choice.

In previous articles I’ve talked about how I use work-for-hire to fund my company Xiotex Studios in between game releases. None of the games to date have made enough money to allow the company to be self-sustaining. So when a high paying contract comes my way I have to take it seriously and in most cases take it.

Making a releasing a game part time

Using this model of work I have been able continue working on Xiotex Studios games. An example of this was when I was contracted to work on http://www.ea.com/create for EA. It meant a commute into Guildford every day and I made use of that commute to work on a game and during the course of the contract I was able to complete and release http://itunes.apple.com/gb/app/koan/id366816832?mt=8 on iPhone. Because it was a part-time game it’s not the best game I could have made but it sold enough and has over 11831 unique scores in its high-score table, not a top seller but a game I was able to develop and release which is an achievement.

The end of balance

Wind on a couple of months and I am approached to work on an Advergame and I am intrigued with this concept so I agreed to do it. It would be this game that would destroy the balance completely.

Stupid hours

The client was convinced that the game was very close to completion so in the last month I put in an extra effort and pulled stupid hours and days in order to get that extra polish in and make sure that as many bugs as possible were eliminated. In the end it meant working something like 47 days in a row with no breaks save maybe one day. A lot of those days were 9am to midnight type hours but I felt it would be worth it because as soon as the game was finished and handed over to the client there would be plenty of time to rest.

It’s these stupid hours and days the effectively killed off any development time that could be dedicated to building games for Xiotex Studios and it’s something I regret. While the contract paid it managed to throw my original plans onto the scrap heap and now it’s time to pull them out again much of the original drive has been lost and all I want to do now is rest.

A warning

So if there is anything that should be taken from this is guard your time and if you are tempted to take on work-for-hire then do so with completely open eyes and really judge if it is something you can manage side-by-side with your other projects. Don’t underestimate how much of your time it will suck away from you and also how much an effect this can have on your morale.


The unexpected performance of debug builds

Original Author: Tom Gaulton

Following on from previous post, The unexpected behaviour of debug builds, I thought I’d follow up with some observations on debug performance, again focussing on the effect of the debugger as opposed to the debug build itself.

The Debug Heap (revisited)

This first example shows how the debug heap can really affect your performance. I used two functions for the test, one that allocates a string on the stack and another that allocates a string on the heap. Each function writes a short string into the buffer using strcpy_s, and has a template parameter allowing me to vary the size of the buffer:

1
 
  2
 
  3
 
  4
 
  5
 
  6
 
  7
 
  8
 
  9
 
  10
 
  11
 
  12
 
  13
 
  14
 
  15
 
  16
 
  17
 
  18
 
  
template <int TBufferSize> void StackStringCopyTest()
 
  {
 
        for(int i=0; i<100000; i++)
 
        {
 
              char buffer[TBufferSize];
 
              strcpy_s(buffer, "hello world");
 
        }
 
  }
 
   
 
  template <int TBufferSize> void HeapStringCopyTest()
 
  {
 
        for(int i=0; i<100000; i++)
 
        {
 
              char *buffer = new char[TBufferSize];
 
              strcpy_s(buffer, TBufferSize, "hello world");
 
              delete [] buffer;
 
        }
 
  }

When using a 50,000 character long buffer these were the timings were:

Build Running Under Debugger Stack allocation method (milliseconds) Heap Allocation method (milliseconds)
Debug Yes 1,303 16,343
Debug No 1,295 5,023
Release Yes 6 >11,624
Release No 6 146

It comes as little surprise that debug is slower than release and that running under the debugger is slower than running without the debugger. However what might surprise you is just how significant that difference can be. Because the behaviour of the debug C-runtime is to fill the stack and heap memory on initialisation the vast majority of the time is spent doing that, and not the code we’ve actually written. In some cases the difference between debug and release is more than two orders of magnitude. That’s a lot.

Another surprise for me was the speed of the Debug stack allocation compared to the heap allocation when not running under the debugger. Looking down the right hand column it would seem that filling the 50K buffer takes around 5 seconds. In the first row the fill happens three times (once due to the C-runtime on allocation, and twice due to the debug heap on allocation and then on free), in the second row it happens just once (due to the C-runtime) and in the third row it happens twice (due to the debug heap). Yet in the left column the fill triggered by the C-runtime has happened in just over one second. I’m afraid I haven’t had time to investigate this fully so it’s left as an exercise for the reader.

Some other strange behaviour came to light when I started adjusting the size of the buffer. I expected a fairly linear performance curve, at least until the buffer is small enough that the cost of the string copy becomes significant. But although this held true for the stack allocation, the heap allocation didn’t behave at all as I’d expected. Instead, the performance seems to stay roughly the same (actually getting faster as the block size increases) up to a threshold at which is suddenly jumps. Moreover, once the performance suddenly drops off, it stays bad, even for smaller block sizes. Here’s a small selection of example values:

Buffer Size Time (ms)
2100 1056
2490 1007
2520 1009
2550 970
2570 2250
2600 2204
2800 2194
128 2357
2550 2201

As you can see, the execution time is around a second up to 2.5K, decreasing slightly as we approach that limit. But as soon as this boundary is breached the time jumps up and sticks there, even for smaller block sizes. These figures are taken from a debug build running under the debugger, release was much the same but performance without the debugger attached was much more in line with what I’d expect.

The only real conclusion I’ve drawn from this is to never ever profile code with the debug heap enabled, because it’s really weird.

Exceptions

A similar profiling test can be done with the use of exceptions. I’d be very wary of using exceptions at all in performance critical code, but for tools development I find them to be a valuable tool. Having said that, I recently discovered that throwing exceptions excessively can be incredibly expensive when using the debugger. Take this example:

1
 
  2
 
  3
 
  4
 
  5
 
  6
 
  7
 
  8
 
  9
 
  10
 
  11
 
  12
 
  
for(int i=0; i<10000; i++)
 
  {
 
      try
 
      {
 
            char buffer[64];
 
            strcpy_s(buffer, "hello world");
 
            throw 1;
 
      }
 
      catch(...)
 
      {
 
      }
 
  }

It just runs a loop 10000 times, throwing and catching an exception each time round. The string copy is just there to make sure the compiler doesn’t get too smart at optimising the loop out. When running under the debugger the exception handling slows down dramatically. With the debugger attached the time to execute this loop was 3532ms in debug and 3075ms in release, while without the debugger it was 35 and 34ms respectively. I tried turning off exception messages in the Visual Studio debug output window but that made no difference, I also experimented with attaching and detaching the debugger during execution and unlike the debug heap code, it’s definitely the presence of the debugger at the time the exception is thrown which is the deciding factor.

A 100x slowdown under the debugger may same like an extreme example, however I stumbled across a case recently that was almost as bad. I’d written a Python script within our tool-chain that would scan all objects in the asset database finding ones with a particular property set to a particular value, however my first attempt caused the script to throw an exception for any asset which didn’t have that property. Under the debugger the script took a full 20 seconds to execute, but without the debugger attached the script executed in under 500ms – and that included taking the results, sorting them and serving them up as a formatted HTML page. So that’s a 40x speed differential, even when there’s plenty of real code executing.

In Conclusion

What I recommend based on these findings is simple: If you want to profile code and get a realistic result, make sure you aren’t running under the debugger. That’s it. You could spend a lot of time learning how and why the debug heap makes such a difference, and why exceptions catching in Visual Studio is so slow, but that won’t ever help you get good profiling results.

Using Kickstarter to fund our indie game or Summer of Adventure, Part 2

Original Author: Becca Posey

THE ADVENTURE CONTINUES

What a big month this July has been for Robots Love Ice Cream, and the Kickstarter project we’ve launched to promote it, we’ve experienced a lot. There’s been a lot of excitement, a few surprises, some achievements, and some challenges, as well.

I’ve decided to use this post to share what the process has been like for us, in hopes that it’ll provide some illumination for anyone else who’s thinking about using this platform.

EXCITEMENT AND ACHIEVEMENTS

I can say without a single doubt that doing a Kickstarter launch was a great first step to raise the profile of the game and of our studio. We’ve received some amazing coverage and support from local, national, and international writers and media outlets, including the following:

WIRED MAGAZINE – support our Kickstarter launch.

NOTCOT – our beautiful reward poster, reminiscent of 20th Century space propaganda.

INDIE GAMES CHANNEL – Disasterpeace.

We’ve also received some great Atlanta hometown love from the innovation bloggers at IGDA’s curated Kickstarter page.

STILL IN IT TO WIN IT

I can also say that from a short-term fundraising standpoint, as things currently stand, we would have been better off using the many, many hours (and a few dollars) we spent creating and promoting the Kickstarter project to just go earn some money contracting to help finance our software and contractor needs. Much better off, actually, because if we fall short of our Kickstarter goal, we’ll get no financial payoff for our efforts.

However, I don’t want to jinx the project because I absolutely have not given up. I still believe that the universe can rise up and everything can fall into place by Saturday at midnight to get us the $18,000 we need to fund and finish the game.

We’ve seen plenty of examples this past month of games that lagged for nearly their entire term on Kickstarter and then took off in the last 48 hours to meet their goals (see encourage friends, colleagues, family, and strangers to pledge.

WHERE WE STAND

As of 7pm this evening, Robots Love Ice Cream on Kickstarter stands at $6425 pledged by 96 backers, with 4 days left to go to meet our $18,000 goal. We’ve broken 35% funding, which according to Kickstarter’s historical data is the point after which over 90% of projects succeed.

One of our challenges has been breaking past our immediate circle of friends and family for support. Looking at the data, I was surprised to realize that the number of our supporters is broken down nearly 50/50. Forty-nine of our supporters are friends or family; forty-seven are strangers to us or friends of friends whom we don’t know personally.

When we look at the overall levels of pledging, it’s a different story. We’ve received $4240 in pledges (66% of total) from friends and family, and $2185 (34% of total) from strangers.

It’s not surprising that the people who have known us all our lives would pledge larger amounts. But it underscores the importance for our project of breaking through to the general public to be able to achieve the level of support necessary to reach our goal. And that’s what we still need to do, despite some great coverage and the goodwill and help of a lot of people who are influential and well-networked on the periphery of  our work.

LESSONS LEARNED FOR NEW PROJECT LAUNCHES

This process has taught me a thing or two. The biggest lesson: just because you have an amazing looking project, and just because other Kickstarter projects in your same category have met their goals for similar levels of funding, doesn’t mean you’re anywhere near having it all locked up.

It appears that mobilizing a large relationship-based network in advance of your launch will get you a lot farther than will a beautiful, compelling presentation that’s presented to the general public.

Our impression upon launching the project was that we would promote aggressively to our personal and extended networks, and the Kickstarter public and gamedev community would find our project thanks to buzz and word of mouth.

While we’ve received great coverage, and our approach has worked at turning out our closest friends and family, my impression is that buzz and word of mouth are still too ‘soft’ to bring in pledges at the level at which we need them.

If you take a look at Kickstarter projects that successfully meet high goals, you’ll notice that they’re likely to have hundreds of backers. They may have fifty backers on their first day. This represents not just a broad network outreach, but also a mobilized network that’s already been sold and committed to action. This means they either had name recognition or project recognition, or both, before the project launch. As newbies, we’ve been using our Kickstarter project to build our brand rather than the other way around. Not necessarily a bad thing for our studio in the long run, but not optimal for meeting our funding goal.

For Robots Love Ice Cream, the best practices I’ve identified weren’t possible at the time we launched our project, because we launched very early in the development process.  We did this in order to schedule the project completion on a date that would let us receive the funds in time to keep the project moving without a break.

THOUGHTS ON THE PROCESS

If I had it to do over again, and had the option to do things differently, I’d have a more finished project to show for launch and I’d have a networks of gamedevs and game journalists who were already familiar with the project and had pledged to write about it. I’d seriously consider making my project longer than 30 days (sorry @GMSarli)to have more time to cultivate media coverage and let publicity grow.

I’m also feeling a bit ambivalent about Kickstarter’s ‘ask for what you really need to finish your project’ guideline. We asked for what we really needed to finish the project, and we’re still 65% behind with 4 days remaining. So if the project doesn’t succeed, not only will we not have the funding to finish the project; we won’t even have the funding to half-finish it. I definitely understand the concern over creatives who use Kickstarter to raise funds for a project that never gets finished and leaves backers hanging. But I believe it should be possible to manage backer expectations to find a middle ground that enables the production of something that won’t get produced without community support.

Ultimately, the jury will be out on this one until Saturday at midnight Pacific time. If we had broken the project down into smaller chunks, we could have funded it in three rounds and taken advantage of successive rounds of publicity and buzz. But we still would have run into the problem of what rewards we’d have available for backers who funded only the first one-third of a still-uncompleted project.

WHAT COMES NEXT?

Addo Games definitely going to need an infusion of capital to bring Robots Love Ice Cream to life. Burton and I are working for free, but software is expensive and our artists are professionals. We’re hopeful that it won’t take another few months of working/saving/bootstrapping to make that happen.

We’ve been approached by some potential investors, but Burton and I both we need those people to put their money where their mouths are. Will the community turn out? We’ll see. Many of them already have, but we need many more to make this dream a reality.

It’s clear that the project is already beloved and admired. My hope is that at the end of this year, Robots Love Ice Cream will not only be fully funded–it’ll be the number one iPad app on the app store. So stay tuned and we’ll see you around the AltDevBlog!

 

 


Procrastination: Gollum and the 8th Deadly Sin

Original Author: Pete Collier

Procrastination: Gollum and the 8th Deadly Sin

Procrastination: Gollum and the 8th Deadly Sin

Is Playing A Waste of Time?

Original Author: Amos Laber

Like many of today’s developers, I started programming because of games. You could say playing games sparked my interest in programming, and in specific coding techniques.Lets face it – playing video games takes a lot of time. As a kid, I was hooked on video games spent countless hours playing arcade games on machines like Atari 2600 and Commodore 64. In the 90s, games became more complex and diverse. At some point, my attention shifted over to other things. Those were simple times, and time wasn’t really an issue.

These days I own multiple consoles and mobile devices and play on all of them, but time now is a much more valuable resource. This bring the question – is that time well spent?

Sure, spending quality time with your favourite console game helps you relax.

 

But I find that it also helps me get more creative. This may sound trivial, but one cannot be a serious game developer without playing lots of games. Playing other people games helps us get a perspective of our own work product. Whether playing high profile console titles, casual, plattformers, or mobile games, the first hand experience is what helps us understand what works and what not, or how a single aspect makes or brake the entire game.

For me there is also the attempt to play through to the end – I confess that I often fail in that. Some of my favourite games proved too difficult to pass. I could never finish GTA IV (although I came close) and struggled hard beating levels  in Bioshock 2; I do much better on casual and puzzle games.

Even for technical aspects playing can be helpful. A certain cool feature we first see in a game can drive a coder to try to imitate it, or improve on it. I can tell for myself that I often get into experiments trying to reverse engineer a certain feature  just to see if I can pull it off.  In that sense playing breeds creativity, and we don’t call it creative coding for nothing.

What about playing shortly just to compare shading, frame rate and polygon count? One can argue that playing briefly for research doesn’t really count. The dynamic of gameplay, the progress and gained achievements are things that take time to experience. This is true in my opinion for almost any non-casual title.

So it turns out we need to play and keep playing, even only for staying in touch. How much time should we spend on it remains an open question.

 

Gathering and Analyzing Data with Django: Part 1

Original Author: Don Olmstead

Playtesting is a great way to tune gameplay. It can provide insightful feedback which can be applied to provide a superior experience. However there may be some valuable information that is not articulated through interviews, because its not something the player is conscious of. By recording their encounters and then analyzing them new observations can be made which can further enhance the game.

In this series of articles we’ll be developing a web site that gathers gameplay data, processes it and then visualizes it. It is structured as a primer on Django, and explores many of its features. This knowledge can then be leveraged when analyzing your own game.

The Problem

Suppose we’re working on a RPG. One of the things we want to keep track of is a player’s progress through the various quests in the game. The data we’d like to glean is how many players encountered the quest, how many finished it, and how long it took to finish it. This information will give us some insight as to how well the quest is received.

Introducing Django

Django is an open-source web framework written in Python. The benefit of using a web framework is its handling of the more mundane aspects of web development, such as communicating with a database. This frees the developer to focus on the functionality of the site, speeding up its development. As you’ll see over the course of the series there isn’t a whole lot of code to get the site up and running.

One of the great things about Django is its site.

Building the Site

Width Django installed we can begin creating the web site. In Django terminology a web site is made up of one or more projects. A project is a collection of applications, which will be introduced shortly, all sharing the same database and settings. To start a project the django-admin.py script is used.

 
  django-admin startproject gameanalytics
 
  

This call creates a gameanalytics directory and three files of interest. The fourth file, __init__.py, is a Python convention for marking directories as a Python package and will be found in multiple places in the application. Its normally an empty file so we’ll be ignoring it for the duration.

  • manage.py – A utility we’ll be using to perform various tasks in the web application.
  • settings.py – A script containing various configuration options, such as the database

    connection.

  • urls.py – The URL mappings for the application.

The next step is to create an application within the project. The way applications are used within a project is similar to an Entity System. Each application provides a single set of self-contained functions, and the combination of them defines the behavior of the project.

 
  python manage.py startapp game
 
  

This command creates the game directory and three files of note.

  • models.py – Defines the data being stored.
  • tests.py – Contains unit tests.
  • views.py – Defines functions that will be called during URL requests.

Architecturally Django follow the Model-View-Controller pattern as evidenced through its naming scheme. Django refers to its variant as Model-Template-View. In terms of mapping between the two the View can be thought of as the Controller, which contains the business logic, the Template corresponds to the View, which handles the presentation, and the Model is just that, the data.

Modeling the Game Data

We’ll begin development by opening models.py and defining our data.

from django.db import models
 
   
 
  class Player(models.Model):
 
  	name = models.CharField(max_length=100)
 
   
 
  class Quest(models.Model):
 
  	name = models.CharField(max_length=100)
 
  	code = models.CharField(max_length=100, unique=True)
 
   
 
  class QuestState(models.Model):
 
  	DECLINED_STATUS = 1
 
  	ACCEPTED_STATUS = 2
 
  	COMPLETED_STATUS = 3
 
   
 
  	QUEST_STATUS = (
 
  		(DECLINED_STATUS, 'Declined'),
 
  		(ACCEPTED_STATUS, 'Accepted'),
 
  		(COMPLETED_STATUS, 'Completed')
 
  	)
 
   
 
  	player = models.ForeignKey(Player)
 
  	quest = models.ForeignKey(Quest)
 
  	status = models.IntegerField(choices=QUEST_STATUS, null=True)
 
  	start_time = models.IntegerField(null=True)
 
  	end_time = models.IntegerField(null=True)

Django provides Object-Relational Mapping, which translates between the Object-Oriented data model and the underlying relational database. This functionality is contained in the Model class which our classes descend from in order to access.

The individual fields expressed in the class definition correspond to fields within the database. The full listing of potential fields can be found in the documentation. Each of them can take additional arguments which allow for more control of the underlying data. In our example we created an enumeration for the quest status, and allowed it to contain a null value.

A quick aside about fields. It is possible in Django to create custom fields. In this example the start and end time contain an integer which will represent the number of seconds of playtime. From there we’ll create a timedelta object. We could skip this step by providing a custom field that works directly with a timedelta, but as this is a more advanced feature we’ll forgo this. For those interested the documentation provides an example.

Before we can create the database schema we need to configure the database connection. This is specified in settings.py within the application root. Django supports PostgreSQL, mySQL, Oracle and SQLite out of the box. For our purposes we’ll use SQLite which requires no configuration on our end, as Python has built-in support for it. When deploying to a web server this will need to be modified accordingly.

DATABASES = {
 
      'default': {
 
          'ENGINE': 'sqlite3',
 
          'NAME': 'test.db3',
 
          'USER': '',
 
          'PASSWORD': '',
 
          'HOST': '',
 
          'PORT': '',
 
      }
 
  }

Additionally we need to register our application within the project. Page down to the bottom of settings.py and modify the INSTALLED_APPS, adding the application to the listing.

INSTALLED_APPS = (
 
      'django.contrib.auth',
 
      'django.contrib.contenttypes',
 
      'django.contrib.sessions',
 
      'django.contrib.sites',
 
      'django.contrib.messages',
 
      'gameanalytics.game',
 
  )

Now we can create the database using manage.py.

 
  python manage.py syncdb
 
  

During execution the script will prompt you to create a superuser. This account allows you to access the admin panel. Create an account as we’ll be accessing it later.

Within the root of the application the database file, test.db, should be present. To examine the underlying schema a tool like SQLiteBrowser can be used. This can be used to examine how our models map to the database.

Database Schema

The Admin Interface

Next we’ll enable the admin site so we can create some data. First we need to uncomment the admin component in settings.py. Next we modify urls.py enabling the three lines related to the admin site.

Now we can startup the site. Django provides a built-in web server that can be used during development. It is started by, you guessed it, manage.py.

 
  python manage.py runserver
 
  

Login to the admin site by navigating to http://127.0.0.1:8000/admin. Afterwards your screen should look like this.

The Admin Panel

The Admin Panel

Here you can add additional logins, but that’s about it currently. To access our data we need to register it with the admin component. Create admin.py and modify it as follows to hook it into the admin panel.

from django.contrib import admin
 
  from models import *
 
   
 
  admin.site.register(Player)
 
  admin.site.register(Quest)
 
  admin.site.register(QuestState)

Restart the web server and refresh the web page to see our models.

Admin Panel with Models Added

Admin Panel with Models Added

Through this interface we can create, read, update and delete data. By using introspection on the models the admin panel generates forms to do all these tasks. It even manages to populate a list box with the names of our enumeration!

Adding Data in Bulk

If we have quite a bit of information to import then adding it all through the admin panel can become tedious. This is where fixtures come into play.

A fixture is simply a JSON, or YAML, file that maps to a model. Create a fixtures folder within the component and add the following to intial_data.json. Here we’ll add some quests.

[
 
  	{
 
  		"model": "game.quest",
 
  		"pk": 1,
 
  		"fields":
 
  		{
 
  			"name": "Fetch my slippers",
 
  			"code": "FET0001"
 
  		}
 
  	},
 
  	{
 
  		"model": "game.quest",
 
  		"pk": 2,
 
  		"fields":
 
  		{
 
  			"name": "Make me a sammich",
 
  			"code": "FET0002"
 
  		}
 
  	}
 
  ]

When running the syncdb command any data in initial_data.json will be automatically loaded. You may have caught the line “No fixtures found” the last time you ran the command. This file not being present was what it was referring to. Run the command again and you should see the data in the admin panel.

Fixtures can also be used to add some test data. Create a file called player_data.json in the fixtures directory.

[
 
  	{
 
  		"model": "game.player",
 
  		"pk": 1,
 
  		"fields":
 
  		{
 
  			"name": "The Nameless One"
 
  		}
 
  	},
 
  	{
 
  		"model": "game.player",
 
  		"pk": 2,
 
  		"fields":
 
  		{
 
  			"name": "Morte"
 
  		}
 
  	}
 
  ]

This can then be added to the database via manage.py.

 
  python manage.py loaddata player_data
 
  

Up Next

In the next article we’ll add the ability to upload and parse a log file as we continue development of the analytics site.

Coding Music

Original Author: Michael Tedder

After moving into a new apartment just last week, I still have a mountain of unpacked boxes surrounding me, so I’m taking this opportunity to attempt writing my first not-so-programming-related post.  If this sounds like a bad excuse… well, be assured it is!  🙂

David Czarnecki What Makes You “Tick” #2? rather piqued my interest, and so I figured I’d write about what kind of music makes me “tick”.  Pretty much since my high school days back in the early ’90s, I’ve preferred listening to music from video games from that era, as well as music from the demoscene.

I was amazed at how much my 286 PC’s audio changed when I got my first add-in sound card: a Sound Blaster Pro.  I thought it was the coolest thing out there, and all of the PC games at that time sounded incredible with the OPL-2/3 FM synthesis and digital sound.  I also got a Gravis UltraSound when it started becoming the popular sound card for PC demos.  All throughout my teenage years, I’ve really never been much of a fan of any kind of mainstream music (although there is definitely some good stuff out there, of course!), and have just continued to listen to the music from the games and demos I love from the past.  I also have a huge collection of Amiga .mod files, started back from as early as 1991, which I occasionally dust off (digitially-speaking) and listen to.

To get my video game and demo music craving nowadays though, I tune in to various radio stations broadcasting live on the Internet.  Each of these radio stations focus on different areas of game music or the demoscene, and so I change stations as my listening tastes vary.  So without further ado, I’d like to introduce the six radio stations in my playlist…

CVGM

is an abbreviation for Computer & Video Game Music.  CVGM focuses on video game music from over 80 different platforms, such as the ZX81, Commodore 64, Atari ST, Amiga, Amstrad CPC, Sega Genesis, various Arcade systems, and also includes old and new music from the demoscene. Anyone is free to listen to the stream, and songs in the database can also be requested and queued if you register for a free account. CVGM is run by FishGuy876, a fellow member of Brainstorm, and I also help with administration and contribute music to the song database, so this is a bit of a shameless plug for our site.

SceneSat

is run by Ziphoid of Brainstorm.  SceneSat specializes in quality music from the demoscene, with a large number of remixes of older music.

SceneSat is unique from other net radio stations in that Ziphoid himself is the radio personality behind the station, doing live shows with various guests, and most importantly: providing a live audio feed at many European demo parties.

All of SceneSat’s live broadcasts are recorded, and can be played back anytime using their unique reLive web interface.

BitJam

is run by the demoscene portal site BitFellas. BitJam focuses on providing a solid database for demoscene music, with information regarding the demo the song was used in, as well as the past history on the author and the groups that the author belonged to.

SLAY Radio

is run by Slaygon, and focuses on remixes and remakes of Commodore 64/SID game music.

There are also live shows with guest DJs at various times during the week as well.

Nectarine

has been around for quite a while, originally being run by Yes/Nectarine back in 2003 (or so?  I don’t remember the exact date).  It remains true to its roots by providing a large range of just demoscene music. Demovibes platform as CVGM (which FishGuy876 assists in developing), and songs can also be requested and queued if you register for a free account.

Kohina

has been around for a while as well, and focuses on only old school game and demo music.  There is no realtime request system, so the rotational playlist is built for quality music over quantity.

Do you have any favorite radio stations you enjoy listening to while coding?  Please let me know in the comments!

Pros and Cons of Online Degree Programs

Original Author: Heather M Decker-Davis

Being as I’ve taken online classes for over four years now, I figured I may be able to offer some perspective to those considering online degree programs. I’ve taken online classes from a total of three different colleges over the course of my academic journey, completed my BS entirely online, and currently have about a year left on my MFA, which is also exclusively online. The following points are some common factors I’ve identified in online education that any student considering an online degree program should at least take into consideration.

Pros

No Need to Relocate

This one is enormous. Instead of moving away to college, then moving again after graduation when you find a job, you can simple complete your degree from wherever you’re at. This is an attractive prospect to people with families and other situations that make going away to school pretty much impossible.

On a related note, due to their location independence, online classes also blend fairly well with traveling. If you’ll be away from home, a laptop may be all you need to stay current with your studies.

Flexible Schedule

Online classes are also great in that you can work around other obligations, effectively shuffling your schedule however it works best. There generally isn’t a hard-set date and time slot you have to be present for weekly, though there are specific deadlines for assignments and discussion participation.

On a couple of rare occasions, classes I’ve taken have required periodic meetings with instructors or peers. In some cases, you have a choice in scheduling, while in other cases, a time slot is given to you. Generally speaking, scheduled meetings are typically offered as additional (optional) resources for students, but keep in mind there may still be some occasions in which you’re required to “show up” at a certain time.

No Commute

Getting to class is as easy as rolling out of bed and sitting down at your computer. With transportation out of the picture, you save time and money you would otherwise be spending on gas or bus fare.

Wear Whatever

Speaking of rolling out of bed, online classes are also great because you could theoretically spend the entire duration of the course in your pajamas. In fact, I may or may not be writing this post while wearing pajamas. Personally, my general “working from home” attitude is that there’s no reason to spend extra time getting dolled up, unless you need to go out into the world for something. Time you’re not spending fussing over your appearance for the day is better applied to being productive!

Interesting Networking

Being an online student does not mean isolation. Despite being physically disconnected from the campus, I’ve had great success with networking throughout my online education. The key is to be social and get to know people. Regularly communicate with your instructors through email. Some even prefer phone calls. Use your lines of communication to build a constructive rapport. Make friends with classmates you indentify with, add them to social networks, and stay connected. Form or join online student groups. Then, when you go to conferences or events, you can introduce yourself to everyone in person!

Cons

Availability of Classes

While many schools offer a nice variety of classes online, it’s inevitable that there will be some classes you’re interested in that simply aren’t offered online. There is often a variety of reasons for this. For instance, some classes require equipment that is only on-campus. Sometimes there simply isn’t enough demand for certain courses to be offered online.

The only thing you can do with a situation like this is make the best of it. You may not be able to take Class X, but you could certainly learn something relevant from Class Y. Additionally, if there are certain skills that you know you’ll need for your career, but you’re unable to take a class for, those things may become your unofficial independent studies.

Spotty Communication

One of the most frustrating things about online classes is that it can sometimes be hard to make contact with instructors, depending on how busy they are. As opposed to the traditional classroom, where you can tap someone for immediate help, email will be your primary way of asking for assistance in the online setting, and email never tends to have an instant turnaround. Last-minute problems can be particularly stressful because it’s not likely you’ll receive a response in time.

As an online student, one major tip for survival is to become an independent problem-solver. Learn to troubleshoot your own issues and search for answers. Certainly keep the lines of communication open with your instructors and make sure they’re aware of any issues you’re having, but be ready to help yourself.

Out-dated Materials

Another specific downfall for online classes is that the content tends to end up a bit outdated. I’ve had classes that revolve around a particular program, with lessons referring to Version C of the program when we’re actually using Version G. It’s likely this is caused by a combination of issues. Firstly, software companies release new versions quite frequently. Secondly, colleges can’t just rewrite courses on a whim. There’s generally a long process filled with paperwork and approvals.

Overall, it’s a disadvantage to some degree, but it’s not the kiss of death to your education. Again, you might be forced to do some extra studying outside of the course materials, but the flow of the class should otherwise be relatively unharmed.

Missing Resources and Events

When you aren’t on campus, you typically don’t have access to things like the library and you can’t attend special events like art festivals. Fortunately, some schools do compensate for this a bit. In my current program, I can check out books from the library and they’ll mail them to me. Some schools also offer online video coverage of guest speakers or events. Many schools still offer support services via phone, tutoring online, writing groups, tutorials, etc.

Peer Participation

Even in real life, it can sometimes be hard to get constructive feedback from your peers, but the online classroom tends to have a special variety of useless feedback. “I like it!” may be a nice thing to say about my project, but it doesn’t provide me with any constructive information that I can use to improve it. While most colleges have policies on participation and substantive feedback, not all students will participate equally. I’ve been in classes full of really awesome and helpful students, but also situations where the discussion boards have been barren.

Group projects may also be problematic at times. Certainly this reflects on physical classrooms as well, but in an online classroom, you can’t exactly shake someone down for their contribution.

Conclusions

As a fairly non-traditional student, I’m very thankful for the opportunities online education has given me to pursue exactly the type of degree program I’m interested in. There are obviously various benefits and drawbacks to pursuing a degree online, but that can be said of any learning platform.

Hopefully this post has been helpful to you, but I’ve probably only scratched the surface. Please feel free to share your experiences in the comments section below!

Writing Android Apps using Visual Studio

Original Author: Erwin Coumans

Google has made it unnecessarily complicated to write Android apps under Windows for C++ developers who are used to Visual Studio. Hopefully this posting makes it easier.

This article is about setting up your Android development environment in combination with Visual Studio and WinDBG for mobile systems beta. The result is that you can create and debug Android projects from within Visual Studio on emulator and the actual device (that doesn’t need to rooted). Those project files are kept in sync with the original NDK build files (Android.mk etc) so they are compatible with the command-line tools. In other words, you can still use ndk-build and ant. If you are a happy Eclipse user, this posting isn’t for you.

There is an open source project called vs-android that integrates Android with Visual Studio, but it doesn’t support debugging as far as I know.

Before we can install WinGDB we need to have the NDK in working order. Google don’t provide a single installer for their NDK. Instead they ask developers to gather all information and installers from various websites. Many things can go wrong this way. On top of that, their 64bit NDK installer has a bug that doesn’t find the Java installation path until you hit “back/next”. Steps 1 to 6 below deals with installing the NDK.

If you already have a working recent NDK environment you can skip to step 7 for WinGDB.

1) Download the JDK from the Oracle website after accepting the agreement, the current version is jdk-6u26-windows-x64.exe

Install the JDK to C:Program FilesJavajdk1.6.0_26 and install JRE to C:Program FilesJavajre6 and make sure java.exe is in your path.

2) Download Apache Ant apache-ant-1.8.2-bin.zip from the http://ant.apache.org/ website and

unzip it to c:androidapache-ant-1.8.2-bin

3) Download Android SDK from http://developer.android.com/sdk/index.html, for example this recent installer installer_r12-windows.exe

Run the installer.

It might complain that the JDK is not found:

Just hit the Back button and Next:

Hit next and choose your destination path. I changed it from

C:Program Files (x86)Androidandroid-sdk to C:Androidandroid-sdk to keep the SDKs together.

4) Start the SDK manager

Your choice of packages depends which Android versions you target for your App. You can just select the default set, it might take a while to download though.

5) Download the Android NDK android-ndk-r6-windows.zip and unzip it in c:android.

6) Install Cygwin from http://cygwin.com/install.html using setup.exe

Install Cygwin to the default location, c:cygwin and select a mirror

Make sure to select the ‘make’ tool by searching for ‘make’ and enabling ‘install’ for the ‘Devel’ packages:

7) Download WinGDB from http://www.wingdb.com/wgMobileEdition.htm, currently the beta version is WinGDB-2.0-b1006-mse.msi

8)Run the WinDBG installer

Then configure WinGDB using the WinGDB preferences tab in Visual Studio

and set the directories where you install/unzipped the packages in previous steps:

9) Create a new Android project in Visual Studio

and choose the name and target

Once the project is created, change some project properties

and change the debug target to device. You can also leave it to use the emulator, but I find it too sluggish.

10) Connect your Android device and make sure the USB drivers are installed. For my Asus TF101 the USB drivers were automatically installed

Enable USB debugging on your Android device, put some breakpoint in your main.cpp and hit F7 or F5 within Visual Studio and if all goes well:

If the connection doesn’t work, you could try disabling your firewall and/or anti-virus scanner. Another option is to enable the Pipe method instead of TCP/IP:

WinGDB also supports import of existing Android projects, but your mileage might vary. If it works for you (or not), please leave a comment.

Note that WinGDB mobile edition is still in beta, so please report problems to forums. I ran into a few issues that hopefully get sorted in the final version of WinGDB, but I find the free beta already useful enough to try it out.


The Mechanics of Convention

Original Author: Claire Blackshaw

Our profession develops, we form conventions and a toolbox of useful solutions. These tools make us faster, and more efficient. Conventions are not only developer driven but player driven as we define the language of games. The real question is when to break convention?

Before you know the answer, you must know the Question

Define the problem clearly with all parties, locate the true source problem and eliminate symptoms. Do you want a sticky goo gun which sticks to walls; or do you want an indirect weapon?

The most common mistake with a convention is to blindly apply it, without knowing the problems it’s designed to solve. You need to delve past the symptoms into the root causes and motivations. For example what may seem like an issue with your jumping dynamics may actually be a visual feedback issue.

Study not only the present state but the history of a Convention

Every day more people more intelligent than you are pouring collective hours into solving the problem you have just started thinking about. The convention you so readily reach for, or dismiss, did not pop into existence fully formed but instead grew through the years of gaming history from title to title.

Seeing the path of development allows you to better understand the components that build the convention, and the parts which were thrown away. Often choices were made, limitations imposed or situation demanded and the path of development was altered. Sometimes a convention might not be the best fit for your game, or even a good starting point but an earlier version of the convention could be ideal building block or tool to use.

Invention is Expensive

The key benefit of a convention is it’s a known element, with known quantities. In many cases with known relationships to other conventions. The development time is predictable and many of the edge cases are known.

Implementing a convention in an environment will introduce some new edge cases and relationships but they will be tiny in scope when compared to a new invention.

A new invention or variation must be explored for all edge cases, establish relationships with all other elements of your project, and be iterated upon to reach a stable state.

If you do not have the budget to invent a new convention, don’t start. Find an existing convention that roughly fits and use that instead. A loose-fitting convention will be ten times better than a half-baked idea.

A little invention goes a long way, but too much will Alienate

While some conventions are entirely developer facing, such as coding conventions, many design conventions are outwards facing to the customer. If a player buys your game which has been marketed as a first person action shooter, there are certain conventions they expect.

Altering convention or surprising your player will often pleasantly and enhance their experience, but only if your solution is clearly superior. Though too many surprises will frustrate or alienate your player, even if your conventions are better than those previously established.

When to break Convention?

Every artistic endeavour must seek to achieve something new, or improve upon the old. The question of when to break convention is simple.

You should always break at least one established convention, though the less you break the more likely you are to succeed. Break too many and failure is assured, break none and success will never be yours.