Ready, Set, Allocate! (Part 2)

Original Author: Paul Laska

Links to other parts:

In this part I will begin to discuss the method and assumptions used to rewrite malloc.

 First comes the huge non-secret, secret.  Aligned memory is easier to allocate than un-aligned memory, because the addresses work nicely within this system.  Since it can be assumed that allocations will always be made along the alignment boundary, there is no requirement to divide and track sub-alignment size blocks, which saves time in operations and space in tracking. The downside is the allocations potentially waste space and fragment memory.  With some careful planning and usage of design patterns such as the Object Pool, the wasted space and fragmentation can be minimized.

One of the dirty little secrets about the tracking system mentioned in Part 1 is it only tracks whether a page of memory is in use or not, which doesn’t inform the free method about how much memory was previously allocated when malloc was called.  So all malloc calls should mark the memory being returned with some sort of header to denote how much memory was allocated, so the corresponding free call will have the information it needs to release the memory and update the tracking information.  In my code I use a simple header that tracks the size and the alignment.

typedef struct _TAllocationHeader
 
  {
 
        size_t      uSize;
 
        u32         uAlignment;
 
  } TALLOCATION_HEADER;

I should mention a few typedefs I use: 

u8        - unsigned char
 
  u16      - unsigned short
 
  u32      - unsigned integer
 
  l64       - long long

 Now, technically, a size_t, or 32-bit unsigned integer, for the uSize member is overkill for a 32MB memory heap (2^25 would suffice), but trying to go smaller isn’t possible with the current data types; the next data type down, a u16 only goes to 65,535.  Even if a data type existed between u16 and u32, it would remove the generalization to be able to easily switch to 512MB or larger.  The 32-bit unsigned integer can denote up to a 4GB allocation, which hopefully should be more than will be needed in one allocation; if not, adjust accordingly for your needs.

The u32, 32-bit unsigned integer, for the Alignment is also overkill, but instead of trying to conserve space using a u8, 8-bit unsigned char, the u32 is chosen because it keeps the address at the end of the header aligned within the 32-bit system.  Something to keep in mind when modifying the allocation header to suit your needs is that the size of the header should be a multiple of the alignment size (e.g. in this system, on a 32-bit platform, headers should be a multiple of 4-bytes (32-bits = 4 bytes)), this provides the benefit that memory addresses returned will be useable with operations that require memory alignment (such as those used in SIMD).

The malloc function signature looks like so:

void* my_malloc( size_t uSize, u32 uAlignment )

uSize is the amount of memory in bytes being requested, and uAlignment is the size in bytes to use for calculating address boundaries.  Calls to malloc can be redirected to use my_malloc by first ensuring malloc.h is not included, then providing a define that replaces malloc with my_malloc during the pre-processor phase of compilation, and swapping the malloc calls for the define. 

#define MYMALLOC( uSize ) my_malloc( uSize, 4 )

So here’s what malloc needs to do… 

  1. Add padding to compensate for alignment of the allocation.
  2. Align the header so the beginning address of the memory will be aligned.
  3. Add the size of the header to the allocation.
  4. Check the request to make sure it will fit in the memory being tracked.
  5. Find enough contiguous pages of memory to satisfy the allocation.
    1. Find a starting point of available pages within a tracking unit.
    2. Find whole tracking units where all pages are available and required in fulfilling the request.
    3. Find the remaining pages needed to fulfill the request.
  6. Return the memory, if enough available memory was found, otherwise return NULL.

 The first four steps feel mostly like housekeeping steps to me, so I’ve kept the explanations mostly to just a word description of what is done in code.  If more explanation is needed, please post questions.

 

1. Add padding to compensate for alignment of the allocation.

If the allocation request doesn’t match the alignment requirement, it’s simple enough to fix.  The additional space is calculated by taking the modulus of the size by the alignment, subtracting the remainder from the alignment, and adding the result back into the size.

uSize += (((uSize % uAlignment) > 0) ? uAlignment - (uSize % uAlignment) : 0);

2. Align the header so the beginning address of the memory will be aligned.

As an optimization, this step can be skipped, if you know that your allocation header will always take enough memory to leave the next available byte on an alignment boundary.  However, if someone calls my_malloc with an alignment size greater than the size of the allocation header, the result will be an unaligned address boundary.  The size in bytes to pad the allocation header can be obtained using a similar method to what was used to pad the allocation itself.  The final size of the allocation header is also saved so it can be used to calculate the return address.

u32 uAllocationHeaderPaddingSize = ((sizeof(TALLOCATION_HEADER) % uAlignment) > 0) ? uAlignment - sizeof(TALLOCATION_HEADER) % uAlignment : 0;
 
  u32 uAllocationHeaderSize = sizeof(TALLOCATION_HEADER) + uAllocationHeaderPaddingSize; 

3.  Add the size of the header to the allocation.

Nothing big here, just keeping track of how much memory will be required.

uSize += uAllocationHeaderSize;

4. Check the request to make sure it will fit in the memory being tracked.

The number of pages being requested is calculated and saved.  First the number of whole pages is obtained by dividing the allocation size by the size of a page of memory.  Then any remaining memory that is required will fit into one page, so one page will be added if the allocation size modulus by the size of a page of memory is anything other than zero.

const u32 uNumPagesRequested = uSize / kMemPageSize + ((uSize % kMemPageSize) ? 1 : 0);

Next the number of tracking units requested is calculated and saved in similar fashion.  The number of whole tracking units is the number of pages requested divided by the number of pages per tracking unit.  Then any remaining pages will fit into one tracking unit, so one tracking unit will be added if the number of pages requested modulus by the number of pages per tracking unit is anything other than zero.

const u32 uNumTrackingUnitsRequested = uNumPagesRequested / kMemNumPagesPerUnit + ((uNumPagesRequested % kMemNumPagesPerUnit) ? 1 : 0);

Last the number of tracking units requested is compared to the total number of tracking units.  If there are more tracking units being requested than the total number of tracking units, the allocation failure is reported by returning NULL.

if( uNumTrackingUnitsRequested > kMemNumTrackingUnits )
 
  {
 
        return NULL;
 
  }

5. Find enough contiguous pages of memory to satisfy the allocation.

The search for pages is broken up into three stages, starting point, whole tracking units, and remaining pages.  The starting point looks for a tracking unit that either resolves the entire request or has pages available at the end and is contiguous to the next tracking unit.  The whole tracking units consist of 32 pages, at 4KB each, and by searching for available whole tracking units, the search is sped up by not having to do an individual search for each page internally.  The remaining pages stage aims to fulfill the remainder of the request by checking the tracking unit that is contiguous to either the tracking unit used for the starting point, or the last whole tracking unit, depending on which was last used.

In the next part the three stages of the search for pages will be covered.  To be continued…


My First Two Weeks at a Startup

Original Author: Shervin Ghazazani

My First Two Weeks at a Startup

Disclaimer:Sorry for the short post. As you can tell by the title, I have picked up a new job and it’s currently taking up a lot of my time. Will post a more technical article next time!

Recently, I had picked up a new contract doing some iPhone work for a well known startup in my city. I was originally hesitant about taking the job due to it not being a job in game development but after spending a day or two thinking it over, I decided to accept the offer. It has turned out to be a great decision. Working at a small startup has taught me a lot about what “work” should really be and it has thus significantly affected my own game dev projects.

 

Startup Mentality

local hackathon and came out with some great experiences,ideas and just had a bunch of fun overall. On the gamedev side, do any of the big studios hosting any internal gamejams? I recently watched It seems like a perfect way for a studio to experiment with new game concepts or even come up with some DLC for an existing game. As long as creative ownership is ironed out beforehand, I am sure that this would be a great idea.

 

It’s all about enriching the culture

The point of all this is that these ideas,activities do more than just create happier developers. It also helps foster a company culture that values creativity among all of its developers and that is the most important/valuable asset of a studio/business. Good studio culture attracts good developers which makes for great games.

More Collision detection for Dummies

Original Author: Paul Firth

Hello and welcome to my bit on #altdevblogaday!

This one is just a short introductory post for an article on the basics of Collision Detection that I posted on my own blog, which you can read here…

 

Circle vs Capsule

Rather than just leave you with a link, I wanted to explore one simple test that I didn’t get time to describe in my own blog post, which is Circle vs Capsule (or sphere vs capsule in 3d).

This one relies on a certain amount of understanding about dot product operator. What we actually want to calculate is the clostest distance between the centre of the circle and the line which represents the axis of the capsule. We can do this by projecting the centre of the circle onto the axis and then checking this distance to see if its smaller than the sum of the radii of the two shapes:

Capsule defined by its centre point C, unit axis A, length m and radius r1. Circle defined by its centre H and radius r2.


Firstly, we must form the capsule end-points:

P0 = C – A*(m/2)

P1 = C + A*(m/2)

 

Get vector from end-point to circle:

D = H – P0

Project vector onto axis:

b = D . A

 

Figure 1

 

In Figure 1 you can see the progress so far, we’re nearly there, but the projection b needs to be clamped against the extents of the axis: 0 and m.

b = clamp(b, 0, m)

 

Get point on axis:

R = P0 + A*b

 

Distance from point on axis to circle:

d = ||H-R||

 

Figure 2

 

You might now recognise this as the plain circle vs circle test. The test for intersection is therefore:

||H-R|| < (r1+r2)


We can find the measure of penetration in the same way:

p = ||H-R|| – (r1+r2)


The circle and capsule penetrate by p units and we can find the contact normal:

N = (H-R) / ||H-R||

 

Conclusion

This test is actually quite useful and extends into 3d directly with no extra work. For more common collision detection tests and descriptions, please have a look at my blog article where you will find such gems as the first interactive, on-line tutorial covering the conservative advancement technique for detecting collision between moving/rotating polygons.

Collision Detection for Dummies

 

Until next time, have fun!

Cheers, Paul.


JS1K Oregon Trail. Games & Demos in 1k of Javascript

Original Author: Paul Evans

Oregon Trail computer game.  It was a good exercise in scoping something small, iterating on it a few times and learning a little more about the language.

I am most familiar with Perforce for source control these days because that is what we use for a lot of the code at the studio, so I also took this as an opportunity to try and host something on github: excellent article about the process), the interpreted source code has to be 1024 bytes or less.  As JavaScript has 16bit character strings, submissions had to take care they were within the byte limit rather than just counting characters.

Design

First of all I have to admit it, I never played the Oregon Trail game on the Apple II.  I was born and grew up in the UK where I used great 8-bit machines like the Oric-1, Acorn Electron, BBC Micro (at school), Spectrum and C64.  Apparently there was a version for the C64 but I missed out.  Helpfully the demo organizers linked to a play-through on YouTube (just to warn you, there’s some raw language in there).  So one Saturday morning when I got up way too early for my own good, I decided to watch it.

Apparently people often die of Dysentery (eek!) while playing, though that did not happen on the play-through I watched.  I thought of trying to do a simple inventory management trade game, but the sheer volume of text and inputs made me think again.  I then thought I could do something about crossing the river but some people had already made something similar to what I was thinking.

Finally I settled on the idea of traveling down the trail itself.  There was already a nice wagon graphics demo there but with no game play, so the idea was unique enough.  A lot of the game during the play-through seemed to center around a wagon travelling down a trail and stopping at landmarks and rivers.  Crossing rivers involved complex decisions that would take me down the complex text simulation route again.  I decided that my wagon in 1848 had a crazy inventor that fitted the wagon with excellent suspension and a spring wound so tight that it provided a KITT like turbo boost to jump rivers.  It was my little game, I could have some creative license!

Implementation

I started out by looking at tutorials at the this tutorial.

Next up I wanted to draw a wagon, I decided to keep it simple and use rectangles and circles to keep the source code simple.  After that I wanted to show movement, so next up was drawing a tree moving along the landscape.  The drawing shapes tutorial helped me figure out how to create the shapes and I wrote the game update function within an interval set every twenty milliseconds.

So I had a wagon that looked like it was moving, then I wanted a river.  I experimented with a few different shapes but a thickly drawn blue line took up little space and got the feeling across of the river.  I animated this at a slightly different speed to the tree to try and get the feeling across that the tree was in the background and the river was in the foreground.

The game never ended, so collision detection with the river was next – as the wagon never moved along the x axis, it was quite simple.  Then to implement the turbo boost – collision with the river only happened when the wagon was at ground level.  Playing the game at that point there was a way to multiple jump… which was kind of fun but made the game too easy.

When the wagon collides with a river the game comes to an end.  Refreshing the browser auto starts a new game.

I needed to display the score next which made it feel more like a score attack game.  The game seemed too easy to me though, so I made the river slowly grow.

Looking at the file size it was over twice the 1k limit, so time to shrink the file.  First I removed all the comments, then all the whitespace.  Still way over.  Renaming the variables to single or double character names shrunk the file to just under the 1k limit.

Future

  • Use some kind of automated code shrinking tool. packer by Dean Edwards looks like a good place to start.
  • Animate the wheels
  • Have scrolling hills going at slower speed than the tree in the background to add more feeling of depth
  • Use mechanized abbreviation to shrink the code further, as explained by Marijn Haverbeke.
  • Experiment more with git – gitflow look interesting

Conclusion

It was a fun little experiment and a nice project to learn a few new things.  The source code is js1k.com to see the entries for all three of the competitions that have happened so far.  It really is incredible what can be done with so little source code.

Input for Modern PC Games

Original Author: Keith Judge

As I said at the end of my last post, I was going to write an article listing all the little handy utilities/settings that make my life easier as a programmer, but in a change in schedule I’ve decided to postpone that and write about something I’ve been coding this week instead whilst it’s still fresh in my mind.

As I’m writing my own engine, one of the first things that needs to be done is input processing. In the latest DirectX SDK, there are two options listed for input, namely DirectInput8 and XInput. DirectInput8 is long in the tooth, being over a decade old and has localisation issues as I’ll discuss below. XInput is newer and is a cleaner API, but seems to exist entirely for using Xbox 360 controllers (presumably as an aid to porting) and supports nothing else. Neither seemed to be an ideal solution to me.

Twitter to the Rescue

I asked about this on Twitter and got a few replies suggesting I use the Raw Input API which I wasn’t previously aware of. Richard Sim pointed me to this MSDN article comparing the APIs (in this case the example is reading mouse input). As you can see, the code for using Raw Input is a lot cleaner and simpler than DirectInput8. The article also says that DirectInput8 is built on top of the Raw Input API and uses a separate thread to capture the WM_INPUT messages, adding overhead in the process. It felt to me that using Raw Input directly was the better solution.

Using Raw Input

The MSDN documentation for the Raw Input API is missing a few things which I’ve had to dig around and find out for myself, so I’ll explain what I’ve found out here. The basic process is that in your initialisation code you register the devices you’d like input from using RegisterRawInputDevices(), and then you receive WM_INPUT messages from the device in the Windows message loop from which you extract the actual keys/mouse input/etc. If you want to register for input from the keyboard, you would use the following code.

1
2
3
4
5
6
7
RAWINPUTDEVICE keyboard_device;
keyboard_device.usUsagePage = 0x01;
keyboard_device.usUsage = 0x06;
keyboard_device.hwndTarget = hWnd;
keyboard_device.dwFlags = 0;
 
BOOL ret = RegisterRawInputDevices(&keyboard_device, 1, sizeof(RAWINPUTDEVICE));

The question is – where on Earth do those UsagePage and Usage numbers come from? The MSDN documentation doesn’t explain, but after a bit of digging I found out that they’re part of the USB HID standard (pdf). On page 26 is table 1 for generic desktop devices, and the keyboard is device number 6, hence the numbers passed to the code above. For the mouse you would use page 1, usage 2. In fact, the Raw Input API lets you register multiple device at once as shown here.

1
2
3
4
5
6
7
8
9
10
11
RAWINPUTDEVICE keyboard_and_mouse_devices[2];
keyboard_and_mouse_devices[0].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[0].usUsage = 0x06;     // Keyboard
keyboard_and_mouse_devices[0].hwndTarget = hWnd;
keyboard_and_mouse_devices[0].dwFlags = 0;
keyboard_and_mouse_devices[1].usUsagePage = 0x01; // Generic desktop page
keyboard_and_mouse_devices[1].usUsage = 0x02;     // Mouse
keyboard_and_mouse_devices[1].hwndTarget = hWnd;
keyboard_and_mouse_devices[1].dwFlags = 0;
 
BOOL ret = RegisterRawInputDevices(keyboard_and_mouse_devices, 2, sizeof(RAWINPUTDEVICE));

I have no idea why the API insists you pass the size of the RAWINPUTDEVICE struct as the final parameter, though it seems to be a common trait for Win32 API functions.

I think the MSDN docs explain actually getting the data well enough, so I won’t repeat that here.

Once your application is registered to recieve WM_INPUT messages, it will also receive WM_INPUT_DEVICE_CHANGE messages whenever a device is added/removed from the system so you can print up “Controller Removed” messages, or switch to an alternate controller as your game requires.

Wrapping Up

I mentioned above that DirectInput8 has localisation issues. What I mean by this is that often in games you need to show the name of the key on screen in control select screens or tutorials. To do this you would use GetKeyNameText() which will return a string from a scan code. Unfortunately, DirectInput8 uses its own DIK_ enums for the keys, which don’t exactly map onto scan codes. On previous games I’ve worked on, we’ve ended up with a large remapping table, with a few exceptions for various locales. The Raw Input API gives you the scan code directly as well as the virtual VK_ enum, so in theory this problem disappears (I still need to confirm this).

I want ugly

Original Author: Eddie Cameron

I want ugly

One problem I’ve found with working with games all the time, is that I’ve become jaded and even bored by many releases. My brain is so tired of seeing screenshots I don’t even register them anymore. Here’s a picture from Skyrim of a lovely young lady in a shop. Then a picture from Oblivion of a lovely young lady in a shop. I’m not complaining (in this post anyway) about the subjects being more than similar, I’m complaining because they’re both pretty.

grapefruitgames.com

Google Spreadsheets as a Data Editor

Original Author: Forrest Smith

Hello, this is my first post on #AltDevBlogADay so a quick introduction is in order. My name is Forrest Smith and I’m a software engineer at Uber Entertainment. Uber is a small studio so my work is all over the place. Hit detection, boss fights, steamworks, inventory, skills, weapons, etc. I’ve also been working on an iphone side project since roughly the dawn of time. One of my main goals in blogging is to share information that I’ve found useful in a concrete, easily applicable manner. We’ll see how that turns out.

Today I’m going to talk about the data for my iphone project and how I edited it. My project isn’t even a game, it’s a cocktail recipe book. It has over 1200 mostly unique recipes using almost 400 different ingredients. This is a lot of data to wrangle. There are already plenty of articles discussing how to store data – xml, json, binary, etc. However fewer articles discuss how to edit that data. Xml and json are both human readable, but not easy to edit at scale. A C# tool could be written from scratch to edit the data, but that seems heavy handed and wasteful for a side project.

A friend recommended using Google Spreadsheets as an editor and I could not be happier with the decision to use it. Typing data into a spreedsheet isn’t a particularly unique concept. What makes Google Spreadsheets cool is how trivially easy it is to write a C# tool to pull that data down. If you aren’t familiar with Google Documents service then I suggest you check it out. Any Google account, such as gmail, provides free access to basic MS Office type functionality. Documents (Word), Spreadsheets (Excel), Presentation (Powerpoint), etc. None of the Google offerings are as fully features or powerful as their retail MS counterparts, but they are all free and “in the cloud” for easy access by any internet enabled computer.

Google provides a .NET library (download) and dummy gmail account so anyone can download and run real code. It was compiled in Visual Studio 2010 with .NET 4. It works on my machine and I provide no further guarantees. 🙂

The demo project took me about 10 minutes to complete start to finish. I decided I would make a spreadsheet containing game developers and games and load it into a shiny tree view. Here’s what the data looks like.

Pretty simple and straight forward. A pair of column headers, the developer in column A, and a variable number of games to the right. What is the process to parse this data? Here’s a summary:

  1. Create a new spreadsheet service
  2. Set username and password
  3. Find the correct spreadsheet
  4. Find the correct worksheet
  5. Iterate over cells

And here is the actual code.

1
 
  2
 
  3
 
  4
 
  5
 
  6
 
  7
 
  8
 
  9
 
  10
 
  11
 
  12
 
  13
 
  14
 
  15
 
  16
 
  17
 
  18
 
  19
 
  20
 
  21
 
  22
 
  23
 
  24
 
  25
 
  26
 
  27
 
  28
 
  29
 
  30
 
  31
 
  32
 
  33
 
  34
 
  35
 
  36
 
  37
 
  38
 
  39
 
  40
 
  41
 
  42
 
  43
 
  44
 
  45
 
  46
 
  47
 
  48
 
  49
 
  50
 
  51
 
  52
 
  53
 
  54
 
  55
 
  56
 
  57
 
  58
 
  59
 
  60
 
  61
 
  62
 
  63
 
  64
 
  65
 
  66
 
  67
 
  68
 
  69
 
  70
 
  71
 
  72
 
  73
 
  74
 
  75
 
  76
 
  77
 
  78
 
  79
 
  80
 
  81
 
  82
 
  83
 
  84
 
  85
 
  
private void ImportFromGoogle()
 
  {
 
      // Login/Password to GMail Account
 
      string userName = "username_goes_here";
 
      string password = "password_goes_here";
 
   
 
      // Name of spreadsheet and worksheet to access
 
      string spreadsheetName = "Example Spreadsheet";
 
      string worksheetName = "Example Worksheet";
 
   
 
      // Connect to google's service with login/password
 
      SpreadsheetsService service = new SpreadsheetsService( spreadsheetName );
 
      service.setUserCredentials( userName, password );
 
   
 
      // Query spreadsheets
 
      SpreadsheetQuery spreadsheetQuery = new SpreadsheetQuery();
 
      SpreadsheetFeed spreadsheetFeed = service.Query(spreadsheetQuery);
 
   
 
      // Loop over all spreadsheets
 
      foreach( SpreadsheetEntry spreadsheet in spreadsheetFeed.Entries )
 
      {
 
          // Check if this the spreadsheet we want
 
          if( !spreadsheetName.Equals(spreadsheet.Title.Text, StringComparison.OrdinalIgnoreCase) )
 
              continue;
 
   
 
          // Query worksheets
 
          AtomLink worksheetLink = spreadsheet.Links.FindService(GDataSpreadsheetsNameTable.WorksheetRel, null);
 
          WorksheetQuery worksheetQuery = new WorksheetQuery(worksheetLink.HRef.ToString());
 
          WorksheetFeed worksheetFeed = service.Query(worksheetQuery);
 
   
 
          // Loop over worksheets
 
          foreach( WorksheetEntry worksheet in worksheetFeed.Entries )
 
          {
 
              // Check if this is the worksheet we want
 
              if( !worksheetName.Equals(worksheet.Title.Text, StringComparison.OrdinalIgnoreCase) )
 
                  continue;
 
   
 
              // Get cells
 
              AtomLink cellLink = worksheet.Links.FindService(GDataSpreadsheetsNameTable.CellRel, null);
 
              CellQuery cellQuery = new CellQuery(cellLink.HRef.ToString());
 
              CellFeed cellFeed = service.Query(cellQuery);
 
              AtomEntryCollection cellEntries = cellFeed.Entries;
 
   
 
              // Need to determine what column is what. Hardcoded for example.
 
              int devOffset = 0;
 
              int gameOffset = 1;
 
   
 
              // Loop over all entries finding the first entry on each row
 
              for( int i = 0; i < cellEntries.Count; ++i )
 
              {
 
                  // Continue if this entry is not the first entry of a row (and not the first row)
 
                  CellEntry baseEntry = cellEntries[i] as CellEntry;
 
                  if( baseEntry.Row == 1 || baseEntry.Column != 1 )
 
                      continue;
 
   
 
                  // Cell containing developer name
 
                  CellEntry devCell = cellEntries[i+devOffset] as CellEntry;
 
   
 
                  // Create a node for the tree view for this developer
 
                  TreeNode devNode = new TreeNode(devCell.Value);
 
   
 
                  // Loop over all games associated with this developer
 
                  int gameIndex = (i + gameOffset);
 
                  while( true )
 
                  {
 
                      // Get game cell, if it's on a new row we're done with this developer
 
                      CellEntry gameCell = cellEntries[gameIndex] as CellEntry;
 
                      if( gameCell.Row != devCell.Row )
 
                          break;
 
   
 
                      // Add game to developer tree node
 
                      devNode.Nodes.Add( new TreeNode(gameCell.Value) );
 
   
 
                      // Increment and validate index
 
                      ++gameIndex;
 
                      if( gameIndex >= cellEntries.Count )
 
                          break;
 
                  }
 
   
 
                  // Add developer node to list view
 
                  TV_Devs.Nodes.Add(devNode);
 
              }
 
          }
 
      }
 
  }

What do we get after all that? Something like this.

Tada! Spreadsheet data has successfully been transformed to C# data. This new and convenient data can be further transformed to our heart’s content.

A few things of note here. When you get the CellEntries object it contains a flat list of non-empty cells. This requires data to be properly formatted. It’s not a system I would recommend for AAA development, but for a solo project I’ve found it to be perfectly acceptable. If you want to do this in your own project then there are two special steps to take.

  • Include the three Google dlls – client, extensions, and spreadsheets. These can be found in my demo project or from the Google library.
  • Change your project target framework from “.Net Framework 4 Client Profile” to “.Net Framework 4″ as this enables System.Web framework access which is required to link the dlls.

Keeping with my focus on the real world, here is how I used this concept in my iphone project.  A standard recipe entry looks like this:

It defines a good bit of information including a variable number of recipe steps. Over 1200 of these recipes are loaded in addition to separate lists of glassware, drink types, measurement types, protips, ingredients, and lite edition recipes. After import the data is validated searching for typos, duplicates, and otherwise invalid entries. The data is then crunched converting most string values into integer ids. Finally, the data can be exported into whatever file format I desire to be loaded on the user platform. Here’s a picture of my tool to handle all this.

That’s what I did for my project and I hope at least somebody found this useful. How do you guys edit data for your side or AAA projects? Discuss in the comments below!


Feeling Like Spinal Tap

Original Author: Ed Bartley

FPG LogoHiya! Citrine here. Fish couldn’t make it and asked me to fill in for him. He said to tell you he was recruited as a gunner for an alien defense force, but will be back as soon as he single handedly saves the known universe. ((/me whispers “he’s really just swamped with work, but we’ll let him have his illusions” 🙂 ))

While trying to figure out what to write for this, I got an email that made me think (among other things) “FPG is the Spinal Tap of indie game development”. Only instead of losing drummers, we’re going through artists.

When we were putting together Flowerpot Games, we asked several artists if they wanted to be a part of it. Some were interested but not willing (or able) to take a chance on an indie start up and some just flat out said no. Of the rest, we narrowed it down to one guy (let’s call him M) that had the skills, showed talent, and worked well with the rest of us. Things were going along good until we got the email from M saying he is going to have to leave FPG. Seems there wasn’t enough time to work on the art for FPG and go to Med school.

We got out the contact list and started making inquiries. After a couple of weeks of emails back and forth to different people, we finally convinced M (oh wait, we already used M, let’s call this one P) … we finally convinced P that we could work with his schedule and got busy bringing him up to speed on what was needed. Weeks turned into months waiting for things to get done when we realized we couldn’t work with his schedule.

Next up we have R. Talented, creative, and actually able to produce faster than we had hoped. Things were moving alone well. The ideas were flowing, we were building off each other, and more importantly, things were getting done. That is until they slowed down and the email eventually arrived. We lost R to school work and the need for a steady pay check.

Which brings us to G and the latest email. Super talented, we had worked with G a little on a previous project and after some communicating, G became a part of FPG. In the short time with us, G helped redesign our main web site and started redoing the GUI elements for Canyon of Desolation. But then the email came. This time it wasn’t as simple (or as benign) as school work or a job. G and his family had to flee due to political unrest and military actions in his country of residence. I can’t begin to imagine what that must be like, but we’re all glad that he’s safe and our thoughts and prayers go out to him and all those caught up in the craziness.

And while the needless deaths and devastation to people just trying to live their lives far outweighs any inconvenience we may experience, I’m still left feeling a little like Spinal Tap when it comes to FPG and artists. Time to break out the contact list and see if we can find another drummer .. I mean artist.


Action Figure Fun

Original Author: Mike Jungbluth

Before I had video games, I had action figures. G.I.Joe and He-Man toys were with me wherever I went growing up. The insane battles and adventures I had with them seemed endless. They were the epitome of play.

While checking out some antique stores with my wife, I came across a cache of He-Man toys. After my initial glee, then shock that the memories of my youth are now apparently antique, I rummaged through the paint chipped plastic men looking to see if I could find some of my favorites. And as I did, I was amazed at how I could remember their names and how to work their kung-fu action grip mechanics, as if I had just been playing with them the day before.

My childhood rushed back in waves, which is saying a lot considering the walls of nostalgic figurines and past pop-culture icons that litter the shelves of every game studio I’ve ever worked at. Being around toys is common place. But being around their mechanics of play… well that seems to have been lost as I’ve grown up. The beat up play things have been traded for more expensive, highly detailed statues that you display proudly on your mantle. And while everything about the action figures were truly tactile, these new monuments are often times a very hands off affair.

As my wife and I moved on to the next aisle of antique dust collections, I couldn’t help but draw the parallels between toys and player vs. developer authorship. And while I love nothing more than animating something with a strong, scripted narrative, I began to realize my inner child was screaming out to just play on its own terms.

Standard Action Figures

These are the workhorse of action figures. You’ve got some arms, legs and a head either rubber banded or ball joint snapped onto a torso. You can crudely pose them within the set limits of the toys rig, but it’s more than enough to get across anything you would want. Points, punches, kicks, arms in the air, grabs, flips… they can communicate all the major verbs you need. And whether it’s a main character or some random red shirt, they all capable of the same actions. These are tools for pure imagination, and give just enough personality in their model to lay the ground work for whatever story or roll they need to fulfill. They often had some tacked on accessories, like helmets, weapons or armor, but those were quickly lost if they weren’t able to be firmly snapped onto the core of the figure.

These were also the first to get chipped, broken or lost since they were played with the hardest. But if that happened it just added to the play scenarios. If a character’s leg broke off from the torso, well now he is going to lose his leg in the story. If the paint was gouged off of a characters face, then those were scars of past battles. And if a toy went missing all together, then legends were told of its bravery.

Making a game like this toy is a scary and hard idea. It means giving complete authorship to the player, and building strong enough core systems as tools to allow free play, finding the right balance between too many restrictions and not enough rules . Then you need to make those core systems so much fun, that when something breaks or happens beyond the control of the creator, that the player wants to continue on and actively finds a way to make that potential disaster a personal victory.

And like those weapon accessories, we have to realize that unless a mechanic is able to be easily carried or snapped onto the core of game, the player is going to abandon them. Other wise the mechanic will feel as tacked on as a pizza shooter is on a ninja turtle.

Minecraft, Little Big Planet, Elder Scrolls, Just Cause 2. All of these games allow and even encourage the player to make the world and its characters their own. And it is what sets them apart from the more forgettable open world/sandbox games. They embrace and encourage the player to try and break or test the limits of what they can express within the confines of the game. This can actually allow the player to look past a lower visual fidelity or more stylized visual fidelity. In fact, that can often allow the player to project themselves into the world more, without too many developer authored details conflicting with the player’s imagination. In fact, adding a story to these can be a double edge sword, often times not matching the player’s actual actions even if they can nudge a player into finding new ways of using the mechanics.

Yes, player control and creation means you will get plenty of penis monsters, but that’s not new. These were also the toys that would be posed in the raciest of positions for a cheap laugh. Its just part of what comes with embracing the player’s authorship. If you have more to offer than a cheap laugh, they will move past that in due time.

Single Action Figures

These took the standard action figures, and added some sort of physical mechanic to the toy. Your kung-fu action grip if you will. Sure, you sacrificed some poseability but often times you could work around that easily enough because if done right, what that single action brought to the table could strengthen a slew of other play options.

Take for instance Ram Man. At first blush, he isn’t very poseable. In fact, he just stands there. But the magic comes from him being able to squash his legs into his body. Then, with a small switch on the back of his foot, you could spring him forward, ramming anyone who stood in front of him.

This simple feature blew me away. I could have him knock down enemies in a tactile way I hadn’t done before, with domino like effects. When he got smacked on the head, he would recoil and squash. The way those two options strengthened any scenario I had with him allowed me to get into his interactions on a deeper level than any of my standard figures. I was able to transfer my unique action to his, identifying with his specific character. And because this action fit in with his character’s personality and purpose, it didn’t come across as a gimmick.

But if his squash/stretch would malfunction, I was quickly ripped out of the experience, cursing whatever jammed up the works. Adding that function meant a giant disconnect if it didn’t work as promised.

Much as with the toys, games of this nature are the ones that I have had the deepest connection to. Mario Bros, Braid, Tetris, Portal. All have one major mechanic that they have distilled down to such an elegant manner that allows both the player and designer to develop deep, rewarding experiences. When both sides are intimately aware of the language and pieces used in completing a task, a real sense of personal attachment is inherited by both sides, and true player/designer communication is taking place.

But that mechanic must be flawless to have so much hanging on it. When it is only half thought out, half functioning, an obvious gimmick or poorly implemented into the play space, the player will turn away faster than if something is broken in an open world game. There, if something isn’t at its best, there are other options to turn to, so the player can forget about the action that isn’t working. But with a single action game, if it malfunctions or doesn’t operate as promised, the player is instantly ripped out of the experience.

Starting this type of single action game can be pretty easy. It doesn’t require a lot of inputs, you can get it up and running fairly quickly and the initial in game challenges are almost instantly devised. But it takes a fair amount of time to dig down deeper. What makes that mechanic work? Is it compelling enough to be the single action of the game? How far can you push and polish it? Is it capable of having any paradigm shifts? That is what makes the difference between a cookie cutter game and a trend setter in the single action genre.

Non Action Figures

 

It would be easy to say McFarlane toys started this trend, but Army Men are in the same boat. Either posed or modeled in a static yet expressively detailed manner, these were always big on the initial wow factor, but quickly became that toy that just sits on the side until you need it for that one thing it does. But boy did it do it well. Its stern gun point, death scream, or heroic uppercuts were second to none. But just don’t ask it to do anything else. If you do it will either break the toy or your imaginative narrative rather quickly when it rigidly holds to its pose.

These are the heavily scripted, quick time event gameplay experiences. They are pretty, they are over the top, they grab you instantly and make the commercials and gameplay reels of everyone involved. And as long as you do exactly what is intended of them, you will be rewarded with satisfaction. When done well, you won’t even notice the fact that they are holding your hand, keeping you in the trolley towards exactly where they want you to go. But if you try to break free, or play them again, you will quickly notice where the polish and intent stops, which will quickly end the two way conversation between designer and player.

Call of Duty: Black Ops is a perfect example of this type of gameplay. Its first mission, set in Cuba, is so deftly scripted that while most players actively participated in the action, they didn’t even realize or care that they weren’t really driving it. And while that may infuriate a lot of game purists, until the player tries to jump the rails, it is certainly immersive and successful in capturing the imagination of players around the world.

Considering the amount of people who love or marvel over beautifully rendered statues that are proudly displayed on desks, coupled with the rare chance to polish the art to the closest we have come to film yet, it is easy to see why publishers, developers and players alike flock to these games. And as time goes on, everyone will realize, like those statues, they are fun to look at, but just be careful not to use them in an unintended way.

Everyone has their favorite toys growing up, same as everyone has their favorite games now. To say that one type of game is any more valid than another is to say He-Man is better than Transformers. Everyone will have their favorites and specific tastes at different moments in their life. What’s important is taking our experiences from those childhood play things, what we liked about them, and what we didn’t, and use those in the games we make today. It validates all those toys we still have around now and all those times we clung to them in the past. Even when we were “too old” to be doing so.

The World is What We See

Original Author: Geraldo Nascimento

The World is What We See

First, Steve Jobs created the User Interface by thinking with portals, looked at his desk and realized it would be an excellent metaphor for the art of computing, i.e., the knowledge of what a computer is and knowing how to work with it.

He imagined a day when computers would be used as bicycles, learning it once and never forgetting. And so he built the modern desktop computer.

Second, Shigeru Myamoto created the game by looking at the world and realizing that all we do in life is fool ourselves and each other constantly, attempting to dodge bullets, dodge enemies, dodge friends. That we are always on the defense, hence the turtles.

He imagined a world where one day everyone would be free of this separation anxiety.

Third, Steve Ballmer yelled DEVELOPERS, DEVELOPERS, DEVELOPERS. And he was right.

We who saw these events with our eyes, and kept hoping for the dream to become real, never saw ourselves in the mirror. We are constantly giving excuses for not doing what we really want: code, eat pizza, and play with friends.

We sign contracts, we always tie ourselves in the future, for things we don’t really want. We get girlfriends who don’t understand what we do but tell us our goals.
We tell them we want a Mass Effect t-shirt and they don’t know what we are talking about. We show them Portal 2 but they can’t even play a first person shooter.

Science is beautiful. Not randomness.

If you don’t own a console with an HDMI television and a kick-ass HDMI monitor, you’ll never see the graphics of Red Dead Redemption, Mass Effect 2 or Dragon Age 2 the way they were meant to be seen. You’ll be annoyed at pixels, at aliasing, because you don’t know how it is done. Just because you don’t know how it is done doesn’t mean you can’t learn, in time.

Why is the world enraptured with Mortal Kombat? The game is a great improvement and successfully captures the struggle that the previous games exhibit.

This weekend, PSN was down. And it might still be, I did not check. I imagine millions of players either hating Sony, hating themselves, going out, or coming to a sad realization.

The world sees gamers and game developers as fools fiddling with controls, as if what what we did was magic.

Suddenly, the metaphors of Baldur’s Gate 2 and the Dragon Age series make sense.
The common people will always attempt to detain, control, and arrest those they see as greater than them.

But we know the truth: we are just kids having fun, designing our own rules, learning about the world and transposing that knowledge to the games we build, in order to further inspire people.

I’ll end this with was printed in the boxes of Spectrum games all those years ago: