Grey: The Lost Technology

About the Game

Grey: The Lost Technology is the first project for Team Aurora, the independent game studio a few friends and I co-founded. Grey was successfully Kick-started in May of 2012. We were able to travel to PAX East and meet with a lot of fellow developers and met some really cool people. The game is an action RPG that explores the possibility of an overpopulated Earth and the humans who leave to find a new planet to call home.


The game is programmed in C# using the XNA Framework. The game does not use external libraries, and instead uses the game engine we have programmed called “Aurora2D”.


The game is primarily Quest/Narrative driven. What this means is that you need to speak to someone, who will give you a quest. Once this quest is completed you will be awarded with another quest, or you will tasked to talk to a person who will give you quest. The dialogue system is something that I spent some time working on to make sure it functioned just right. Imagine the dialogue mechanic like any RPG, or text-based action game: The text shows up in a box and then continues to show up in chunks until a response is required. Each response can link to certain objects in the game. Talking to someone can give you:

  • Quests
  • Money
  • Health
  • Experience
  • Items

Alternatively, it can direct you to more dialog. Implementing this is primarily about a good structure and design of the dialogue objects themselves. A Talker, when spoken to, evaluates each dialogue that is tied to them. They accept commands and react accordingly.

Another large contribution of mine is the design and implementation of the map system. A map is designed like so:

  • Map
    • Levels (Can be viewed as subsections of a map)
      • Layers
        • Tiles
      • Group Objects
      • Spawners
      • In-location markers
      • Characters

A map is broken down into levels (read: sections), then a level is broken down to handle each component that is drawable from the tabs in the editor (See below). So the structure is simple, each type of object has their own list, and when the maps are saved, they are serialized in an overridden XmlWrite that structures each object list as a group. However the most revolutionary part about the serialization is about saving the tiles. When serializing the tiles, there is a dictionary that holds a dictionary, kind of like this: Dictionary<int, Dictionary<int, Tile>>. This can be seen as [x][y] = tile. You might be thinking that it should be stored as an array, but when saving an array it saves all the empty positions, and we don’t want that. So I wrote a loop that writes out each tile within an <X> element and a <Y> element. The <Y> element holds the tile position in the texture, and then also holds an index to a texture that it uses. The ending result looks kind of like this:


This saves us a tremendous amount of space and is a lifesaver in terms of distribution of the final product (because there are less files to transfer, it’s much easier to share). To read more about my theory and logic behind this serialization concept, check it out here: Problems of Storing Maps


Since we created the game with a framework, and did not use an existing game engine, we needed to create a game editor. The game editor is something of my own creation with the exception of the Navigation Mesh Editor written by our other programmer, Jacob Jackson. The editor is an XNA project that is supplemented by Windows Forms. When the game launches is creates the Control Panel that the designers will be using to manage game assets and map textures.

Control Panel

Grey Editor: Control Panel
Grey Editor: Control Panel

The control panel offers all the flexibility and options that a game designer needs to fill in a level and create everything that is going to be in the level. On the surface you can see that you have the ability to manage:

  • Texture Placement/Selection
    • Animated
    • Static
  • Objects
    • Map Links
    • Characters
    • Enemy Spawners
    • Location Marker/Zones
  • Particles
  • In-Game Items

By adjusting the Edit Mode, you will have access to different functionality offered by the editor. For example switching from TILE (which allows you to place all of the items offered in the tabs) to PATROL_EDITOR, you will be able to draw patrol path lists that and have the ability to customize them. There is also an Edit Mode for drawing the Navigation Mesh on a map. Lastly, there is another edit mode for drawing world-space collision geometry.

The Draw Mode combo box allows a designer to change between:

  • Drawing – Draw an object in the scene
  • Deleting – Delete an object in the scene
  • Editing – If drawing collision, use to add vertices to a shape
  • Transforming – If drawing collision, use to grab and move vertices of a shape


Collision Editor

animationeditorSome of the coolest parts of the editor are in the Tools Menu. The tools menu provide a designer with the ability to add collision geometry to each and every character model/animation that exists in the game. Using the Collision editor is simple. A list is populated with all the animations from the spritesheets and then the selected spritesheet is drawn and all that is required is to click and drag to draw a collision box. Rotating the collision box is done by holding space after you dragged the box out to it’s appropriate size.

Data Editor

The Data Editor gets into the nitty gritty of the actual game itself and allows the designer to

  • Create all items in the game
  • Create all the quests of the game
  • Create magic effects
  • Alter “New Game” configuration options

questeditorThe quest creation system is a portion of the editor that I had a lot of fun working with and was able to really break down a solid questing architecture.  The quest system is broken down like so:

  • Quest
    • Quest Steps
      • Continue Requirements
      • Failure Conditions
      • Rewards
      • Items to Remove
    • Rewards
    • Items to Remove

A quest must have steps to be completable. Think of a game like The Elder Scrolls: Skyrim where a quest often times has a few parts that must be completed to complete the overall goal. To evaluate each of the Continue Requirements, I hook events for each running quest and then when anything in the game happens and fires an event, each quest you are completing will be updated concurrently. This event driven implementation is the core of the quest system. As a supplement, I created what I like to call an action list. The action list is a rolling list of every action that our hero, Oren, performs in the game, whether it’s killing an enemy, clearing a spawner, or changing maps, it all gets recorded as separate actions. This implementation solves the problem of a player exploring the map and killing a boss or character that spawns once in a game, then getting the quest tells you to defeat him, and not being able to complete it. A quest checks the action list in parallel to the events that it handles.

createitemThe Item Editor is also really cool because to complete this I implemented a class parser using C# reflection to handle populating the editor. There is a main recursive function that handles the population aspect. This function takes the object and uses reflection to evaluate each public property and generate a component that best fits the type of property it’s evaluating.


The engine is a set of utility classes and objects that offer a full suite of functionality and easily pluggable into different situations. Some of the tools offered include:

  • Texture Parsing for Animations
    • Texture Atlases
    • Grouped Textures
    • Single sprite sheets
  • XML Serialization
  • Quad Trees
  • Separating Axis Theorem (SAT) Collision Detection
  • Baseline Menu Creation
    • Including Buttons and Sliders
  • Lots of Extensions for Primitive Classes
  • Input Management
  • Resolution Management
  • Event Management

The library is fully featured and provides us with a very solid base to build Grey with.

Understanding C# 2D XNA HLSL – Part 2

Read the first part here

I know a lot of you loved the first part of this breakdown, and now I’m back to continue the explaining!

Breakdown of Effect Parameter

Continuing from the end of the first part: What the effect parameter does here is that it takes our effect and then applies it to all of the textures that you draw then on. This is effective for coloration effects such as black and white, or inverting colors, but if you have an effect that works based on certain coordinates or is constricted similarly, then you need to be  very careful! To avoid issues like that, there is a rather simple solution when you want to apply an aforementioned size/position constricted effect to the screen.

Further Implementation

Adjusting the Effect parameter of the SpriteBatch.Begin() function is not the only way to use HLSL effects in your projects. Another method that you can do is draw all of your textures to one RenderTarget2D (Think of this as an empty texture, or a blank canvas). After you’ve drawn all your textures to that, it’s really easy to apply your effect to “the screen”.

RenderTarget2D MainTexture;

//In the Initialize function set up the rendertarget:
PresentationParameters pp = GraphicsDevice.PresentationParameters;
MainTexture = new RenderTarget2D(GraphicsDevice, pp.BackBufferWidth, pp.BackBufferHeight);

        //Then create a function to draw your game textures to, and draw it all up       

        private void DrawGame(GameTime gameTime)


            spriteBatch.Draw(bg, GraphicsDevice.Viewport.Bounds, Color.White);
            spriteBatch.Draw(player, new Vector2(200, 300), new Rectangle(0, 0, 128, 128), Color.White);



        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Draw(GameTime gameTime)


            // Use Immediate mode and our effect to draw the scene again, using our pixel shader.
            spriteBatch.Begin(SpriteSortMode.Immediate, BlendState.AlphaBlend);

            mainEffect.CurrentTechnique.Passes[0].Apply(); // for every pass that you have you can apply
                                                           // all them to the texture if you want.
            spriteBatch.Draw(MainTexture, Vector2.Zero, Color.White);



Alternatively, you can use the effect parameter in the spriteBatch.Begin() function when drawing MainTexture, because remember: The effect is applied to the texture in every Draw() function call. If you only have to draw one texture and want all the passes applied when drawn, then you can use the Effect parameter.

Why do this?

In a project I was working on I really wanted to have an INFINITE amount of 2D lights in my game, and after countless attempts at getting a high number lights (higher than 5) from all HLSL effects, I found that by drawing a my lights to a texture, and then my game to another, I could then use an HLSL effect to blend my lights together.


I hope this helped.


Understanding C# 2D XNA HLSL


Firstly, what is HLSL? What can we use it for? HLSL is an acronym for High-Level Shader Language, and because it is a shader language, it runs on the GPU of the computer. With HLSL you can perform many post-processing effects, such as: blur, point lights, black and white, bloom, and pretty much any filter you can think of that can be done in Adobe Photoshop.

When working with HLSL on the Xbox 360, you are limited to using Pixel Shader 2.0 (This way you can support all Xbox’s) rather than 3.0, which isn’t terribly bad, but it could be so much better. You can do a lot with pixel shader 2.0 with up to 64 mathematical operations per-pixel. Because it is a pixel shader, the code that you write will be executed on every single pixel that is on the texture you’re working with. If your game resolution is 720×360, totalling to 259200 pixels, and if you have 3 mathematical operations per pixel (for example you are using sin, cos, and +), totalling to 777600 mathematical operations done for every time this shader code is ran (typically the total amount of times you draw the effect to the screen).



Nearly any filter that can be done in photoshop can be done with a shader. So, check out an example (more to come):

Radial Blur Example
fig. 1.0: Radial Blur

Continue reading “Understanding C# 2D XNA HLSL”

Zong, pong for the Zune

Well, this is a little pong game for the Zune that I whipped up. There’s probably a better way of doing this, but I just ported it from this guy’s source code:

Flaim – PONG in AS3 in ~ 1KB

Now, here is the source code for Zong (you need visual C# and xna 3.0 beta to open and run it):

[ – Source Code]

Have fun, and if you can fix the enemy paddle’s shakyness, post a comment!