Section Transitions

You may have noticed that all of my demos so far involve a single level (I call them Sections in code). Of course, this won't do for a real game, so I implemented a few things so that we can trigger changes from one level to another.

1. Introduced the Section Registry to the Asset Editor program. The section registry is more or less a list of all the sections in the game. Its primary purpose, for the time being, is to bind file names to section titles, so this screenshot is a bit bare:

So, I've used the level editor to create two maps, and then I've registered them as sections in the asset editor--and titled them Level 1 and Level 2.

2. Added a method hook on the Game Interface that can be called from scripts, called 'ChangeSection.' See the screenshot on how this is used:

What this says is that when the player collides with this entity (seen in the screenshot as one of those invisible triggers, placed right outside the border of the section), a message is sent to the game to change sections, with a few parameters:

• The level name, seen above as Level 2. The section registry is used to find the corresponding level file to load.
• The tag of an entity representing the target location (where the player will be standing), seen above as 'right'. Oh, I added a 'tag' field to entities and re-purposed the collision categories screen as a general 'entity properties' screen. See screenshot below to see how an entity on Level 2 was tagged.

• The last parameter is a description of a well-known transition type. In this case, we're moving left a section, so the parameter value is 'left'. 

For now, up/down/left/right are supported, as you'll see in the video, but I wanted to make this abstract enough for other transition types. For example, when entering a cave, much of the logic is the same: we need a target section and a place to put the player when they enter, but we'll probably want to fade to black and then fade in from black, or do a screen wipe, or something like that. Same with going up stairs and down stairs, or falling in a pit, or whatever else the game requires.

Anyway, enough writing, on with the video! Here's me running around two very similar levels as a demo. Note that because level transitions can go anywhere, we can even have a level transition into itself, as shown near the end of the video! And because transitions are controlled via script, we can write levels with strange transitions (for example, a door that takes you to a different level or target position depending on whether a switch is hit, or if you have less than 1 heart left, etc).

Recreating a Familiar Scene... With a Twist

I did a few things which allowed me to produce a cool demo.

Step 1: Introduce a circular model (and a new texture to use it on).

Implementation detail: While collision between polygons and circles is pretty trivial, the ability to stretch and rotate entities freely means that 'circle' is really 'ellipse'. And collision between two arbitrary ellipses, while not unsolvable, is more computationally complex than standard polygon collision. Therefore, circles are approximated as 16-sided polygons ('hexadecagon', the internet suggests, and my spell checker complains of).

Step 2: For entities that act as triggers, spawn points, etc: allow us to set 'no texture' to the entity and exclude it from the rendering process in-game (but not in the editor). This is what they look like:

These triggers are always rendered on the top layer. They have every other property that entities have, namely script events, which enables us to make something happen when the user collides with the trigger zone, or...

Step 3: Introduced an 'update' script event that can be attached to entities. The 'update' script runs every logical frame of the game, or at an interval specified.

Step 4: Added a 'BounceVeloicty' parameter to the arguments passed through to the entity collision event. This could actually be calculated in the script, but it seems that using it will be so common that it's probably more efficient to calculate it from the engine and pass it through every time. The 'bounce velocity' is just what it sounds like--the direction an entity would travel if it were to bounce off of the entity it collide with (like a wall, or another ball).

Step 5: Add a little script, make a video. Enjoy!

Next up: Linking multiple sections (levels) to each other and transitioning between them.

When Entities Collide

I implemented an event that fires when an entity collides with another entity. When setting up a demo for this event, I quickly realized I'd need to set up a system of conditional collisions--known as collision categories--to produce the desired behavior.

This is best demonstrated with a simple example. I have a brazier that can spawn moving fireballs. I want the fireballs to be destroyed when they touch a wall. But I also want the fireballs to pass over other braziers (and the brazier that it comes out of, if it spawns directly in the middle!)

Refer to the following video when reading the rest of this post, as it's much easier to explain in video format.

The first brazier has the following script:


local entity = section:CreateEntity(t);
entity:SetModel("Solid");
entity:Attach("selfCollideEntity", function() entity:Destroy() end)

This ends up creating an entity that passes through everything. Why? Because the entity has no collision targets. To fix this, we need to add the following script, which is on the second brazier:

entity:AddCollisionTarget("wall");

(Note that by default, all 'walls' are tagged with the collision category 'wall'. It's a special collision category which has the property of blocking the player's movement when the player collides. Setting a model to 'Solid' in the editor automatically adds the collision category 'wall'.)

Now the entity is destroyed at a wall. Unfortunately, the brazier is also tagged with 'wall', so that's where the fireball disappears. Our third brazier has the same script, but the brazier next to it has its 'wall' tag removed. In the video, you can see that the fireballs pass through the brazier, but so does the player.

The solution: tag the brazier as 'wall' and 'brazier'...

... and add the following to the fireball creation script:

entity:AddCollisionExclude("brazier");

In summary, this means the fireball collides with anything marked 'wall', as long as that thing isn't marked 'brazier'.

That's all for now!

My Sword Does Damage Now

My blade has been infused with an ancient power...

A force found only in ancient legends, striking fear into the hearts of enemies inanimate bushes...

The power of....

section:TriggerAt("playerDamageSelf", { swordPolygon });

Okay, so there's a bunch of stuff that I did recently. I'll get to the damage trigger in a minute. First things first, major changes:

Removed 'Tiles' from the game and replaced them with entities. There was a missing abstraction here--Tiles and Entities were close to identical except for a few properties, so I merged them into one object. Of course, from the editor's point of view, there's still tiles, since it's incredibly convenient to edit layered, axis-aligned stacks of tiles for the level geometry. However, when the game loads these from data, it simply converts them to regular old entities.

Updated the script editor. Here's what it looks like right now:

Most notable is the 'test' button, which compiles and attempts to run the script. Since there's no game context and scripts make use of a number of parameters passed in, the editor uses mock objects that implement those interfaces. At the very least, this ensures two things: that the code compiles, and that the methods called on those interfaces exist, and that the parameters are correct. A limitation of this, however, is that I can't ensure that all branches are executed. In the script above (which turns a light on and off when the player slashes it), the method entity:GetState always returns null, so the 'else' clause won't ever run in the test script.

Also note the label above the method body which tells you the implicit function signature of the event. A future enhancement would be some sort of browser that shows you the available methods on those objects. Intellisense would be great, but that's way out of scope.

Another minor but useful update: added a launch button to the editor. Fourth item on the toolbar (play). Runs the game with whatever section you're editing.

Okay, now for the demos.

This first video illustrates the new trigger 'playerDamageSelf'. This is an event handler for entities, so the 'self' in the name refers to the entity. That is, when you define 'playerDamageSelf', you are declaring what happens to an entity when the player damages it.

There are four sets of bushes, each with a slightly more advanced feature than the last:

1. The leftmost bushes simply change texture when slashed.
2. The script clears the collision model out so the player can walk over it after it's slashed.
3. A single leaf entity is spawned in the middle of the bush.
4. Multiple leaf entities with randomized positions and velocities are spawned.

Next up: Making entities collide. Remember the video with the fireballs coming out of the braziers? Well, let's make them disappear when they hit a wall.

Back from a short hiatus

Was on vacation for the better part of the week, so no updates. Working on getting the scripting architecture exactly where I want it before updating, which is mostly just code restructuring. Look for an update soon!

Enhancing scripts

In my last post, I mentioned a problem I had where I had to specify the 'source texture' when changing a tile's texture from a script. My proposed solution was to move scripts out of the 'TileStack' level and into the 'Tile' level. I went ahead and did this, worked great!

So now, the 'change texture' and 'change animation' script methods are simpler and easier to use.

Having all of this game logic entirely contained in scripts inspired me to move any game-specific logic out of the engine (C#) and into scripts (Lua). So, I migrated the player movement and sword-swinging script (there's barely any code there yet) to a script. There's nothing to show for this, since it's just moving code from one place to another, but it does allow me to change player behavior more dynamically at runtime without rebuilding the code.

Okay, now for the fun stuff. I added a few major things to the scripting infrastructure:

• A 'CreateEntity' method on the Section interface. This does exactly what you'd expect; it creates an entity based on a number of parameters, such as position, rotation, texture, etc.
• Added a 'Motion Controller' component to entities. The first implementation of this is a very simple linear motion controller (you give it a velocity vector and the entity will move in that direction every update).
• Added a ScriptInterface so that scripts can manipulate their own lifetime and other behaviors. This has a few methods, notably the ability to set a 'delay until the script can run again' and 'the number of times a script can run before it is destroyed.'

The following video demonstrates these new features:

Next up: I'll code another event trigger representing 'playerDamage.' That is, the event will be triggered when the player slashes their sword at something.

Bringer of Light

Minor updates before the demo

• Updated the editor to allow rotation of textures on tiles and entities. Added shortcut keys (Ctrl+Left, Ctrl+Right) to rotate 90 degrees in either direction.
• You'll notice a minor change of scenery. Moving indoors for a bit (added a few interior textures).
• Refactored the scripting engine to pre-compile tile/entity scripts at map load time instead of evaluating them during a trigger.

Okay, a short update. Mostly I just wanted to make a script that did something a bit cooler--so that's what I did. Here's a video of a bunch of lights that change texture from off to on when you touch them:

Now, you might have noticed that there's a bit of awkwardness in the script itself: why should I have to specify the 'source' texture (ground_light_off) in order to change it? The reason, for now, is that the script is actually applied to a collection of tiles (a tile stack). When it executes, it doesn't know which layer of the tile to apply the new texture to. Specifying a source texture lets the method figure out a best guess. Here's the code for that:

I don't really like this method, it's sort of hacky. It seems a more elegant structure would be to allow each layer of the tile stack to have its own scripting triggers. So that's what I'm going to do next.

Baby's First Script

I added very basic scripting capabilities! Most of the work here was getting Lua integrated and setting up a data model for saving and executing scripts.

First, set up a tile with some sort of collision model. For now, the engine uses the same collision model to block the player and to detect collision for script execution. This might need to change--what if I want the player to be able to walk over a tile, but have the tile still execute a script?

Okay, as you can see, I've added a new flyout menu for managing scripts. If there's none there already, 'New' is the only option--if scripts exist, there's options for 'Edit' and 'Delete'. Let's create a new script...

Here's the Script Editor form. Pretty basic for now. Pick the function you want to define--I only have two right now, one that's triggered when the player collides with the model ('playerCollide') and one when the player does damage ('playerDamage') to the model. I'm going to choose playerCollide...

...and here's where I write my very first script. As you can guess, this script claims to move the player 80 units right and 30 units down.

Okay, I saved the section and ran the game. It works!

So, there's a very simple script integrated into the game. From here, it'll be easier to add more powerful scripts that act on a variety of game objects. Some examples of the first few things I'll add to the interface to implement the 'player slashes his sword at a shrub'

• Change the texture of any of the layers of a tile or entity
• Change the collision model of a tile or entity (you can freely walk over a shrub that's been slashed)

More advanced scripts for the same scenario might involve something like:

• Spawn several debris entities (leaves)
• Run scripts on those leaf entities to make them move in a certain way
• Destroy the leaf entities after they hit the ground
• Play a sound (I haven't set sound up yet, though)
• Spawn an object or enemy that was hidden in the shrub.

Adding collision to entities

As demonstrated in an earlier post, the level editor allows me to edit the collision model of a tile independent of the actual graphic. Before I jumped into scripting, I realized it may be wise to go ahead and implement the same logic for entities (entities are freely positioned, scaled, and rotated objects). This was fairly simple, since the collision detection algorithm was coded to operate on arbitrary polygon models, not just axis-aligned tiles.

Video! Here's some footage of me actually using the editor to show how I set these things up. I create some entities, transform them a bit, set some different collision models on them, and then demonstrate the results in-game.

The prototypes for collision models (you can see them in the video as 'solid', 'half triangle', etc.) are defined as polygons in the unit square space (x and y coordinates between -.5 and .5). I thought it might be neat to show how easy it is for me to add more of them, from start to finish, including the programming. The only thing I've done ahead of time is make the editor graphical representation of the model, which you can see me copying into the texture atlas at the beginning of the video. This one's probably better in highest quality since the code blurry otherwise.

A bunch of boring stuff

What you'd be missing if you skipped this post: nothing. Game development isn't always exciting, there's definitely boring stuff mixed in with the fun. I'm choosing to tackle some of those issues early, since I'm sure they're not fun near the end of a development cycle when you're all stressed out anyway.

So, a couple of minor technical things:

• Switched from the manual filling of a dynamic vertex buffer (and subsequently calling DrawPrimitives) to just calling DrawUserPrimitives every frame. I fill my vertex buffer every frame since I don't really have any static content (tiles may seem static, but the programming model allows me to manipulate every sprite for every frame). Performance is about the same, as expected.
• Since everything is a quad right now, it made sense to use DrawUserIndexedPrimitives instead. Slight performance boost.
• And here's the stuff I really hate doing: handling 'lost device' exceptions (from ctrl+alt+del, for example), properly releasing and re-allocating all device-dependent resources, etc. Anyway, it works now, so that's out of the way. Full screen alt+tab is still a little messed up, but I'll save that one for another night.

Next up is some really fun stuff that I'm looking forward to implementing: scripting.

Camera Clipping

A short, simple task: make it so the camera doesn't travel outside of the bounds of the section. I'm not going to miss that ugly grey color of the void. 

Animating tiles and entities

Okay, here's a short video of tiles and entities being animated. The lights are tiles. The stuff at the bottom of the section are entities. As shown, any animation can be used on entities (entities are objects that can be freely rotated, positioned, and scaled). Even things that don't really make any sense, like player animation, as you can see in the video. I'm starting to get the craving to find some real art.

More sword animations, animation speed, minor tool updates

Just a few minor updates.

• Made a more useful display (seen in big ugly, but convenient, red text) on the texture editor. Shows the size of the current selection (or proposed selection if you're highlighting an area0.

• Made animation speed configurable. I'm betting this will get more complex in the future (i.e. individual frames that take longer than others), but for now a flat animation speed will suffice. Editor seen below--here you can see I've set the sword speed to '4'.  Any positive floating point number is valid.

• Added the rest of the basic sword swinging animations (left, right, up) in addition to the one shown before. Although this isn't particularly interesting work from a development perspective, doing this kind of stuff highlights inefficiencies in the process, so I can fix those for a (hopefully) future artist who will use the tools. Quick video of the animations:

Alright, now I'm set to implement what I said I would last time: animations on tiles and sprites.

Adding texture model information to the asset editor

Here's a problem that surfaced as soon as I tried to animate something remotely interesting--namely, the character swinging a sword. Check out this video which illustrates the problem:

The problem here is that the animation frames for the character standing and moving are something like 16x22 pixels. The frames for the sword swinging are larger--and every frame is a different size since the sword extends in an arc. However, animation and player models are decoupled--no matter what the character's doing, it's defined in in-game units as 32x44 (the fact that it's double the pixel size is arbitrary; the same problem would occur, and be solved by my solution, if the player was 50x50). So, what you're seeing is a larger image being jammed into that 32x44 box, which looks messed up.

The solution was to add metadata to each texture to define a 'model-box', or model-relative coordinates, to 'anchor' that sprite such that the in-game model will fit into that area. Here's a quick video of me lazily setting up a few of these boxes. Some of them are probably off by a pixel, but whatever.

The blue boxes, therefore, represent the entire graphical image that will be displayed. The yellow box corresponds to the model. And here's what we get when we run the game again with the updated data:

Also added and not shown (because it's just code): basic logic to handle switching between player states from an input processing perspective. That is, different states allow the user to process different combinations of commands--you can move, change direction, and start swinging your sword while you're walking around, but not while your sword is swinging. But you can pause the game (once I implement that) during just about any state. Right now there's only two (basic) states (swinging and not swinging), so it's implemented with an if/else block, but I can see each player processing state being its own class in the future.

Next up: Configuring tiles and sprites to reference animation data rather than just texture data.

Asset Editor, Animation

I had a really basic 'Texture Editor' program which allowed me to manage the textures used by the game. However, the need for something a little more sophisticated emerged after a few requirements. First of all, selecting source texture coodinates by typing in pixels is extremely tedious. Here's a shot of the new utility:

On the left is a tree of 'assets'--so far just Textures and Animations. Selecting a node in the tree brings up the editor for that node. In the above screenshot, I've selected a texture. From the editor, I can then draw a box around the part of the image I want to use to set the texture coordinates. I don't know if the final game will make use of sprite sheets (texture atlases, whatever) or not, but it certainly makes development with temporary graphics a little bit faster. I can also change the source image and title from the editor.

Worth noting is the folder structure on the left. This is purely a development construct--folder data most likely won't be used in-game. But it will definitely be used in the editor build the dynamic fly-out menus to help find certain textures more quickly, and it's useful in the asset management tool too as a way to keep things organized.

Here's a shot of the animation editor:

The image preview actually animates so you can see what you're building, not that you can tell from a screenshot. The list box of frames is populated simply by dragging nodes from the tree into the box. Unlike textures (which are referenced by id), the names of animations are important, as that's how they're set by code.

In addition to the editors above, this asset utility allows the creation and deletion of folders, textures, and animations. You can also rename folders and drag items between folders. Changes are saved explicitly by clicking the save button.

And, for something a bit more interesting, here's a short video of the character running around using 4 simply animations.

Oh, I also hooked up a gamepad (some old Logitech rumblepad) and wrote the code to parse input. Even controlling a character that can't do anything but move around yet is more fun when you're holding a proper controller.

Tools

Been working on tools--namely, asset (texture, animation) management. More to come in the next few days.

Back to work!

I've had barely any time to work over the last week. The last thing I did was implement right-click context menu items that you could toggle by right clicking (this was surprisingly annoying and not directly supported by the WinForms API). To make the editor interface a bit slicker, I removed the right-side 'selected item' editor--all actions are currently performed via the context menu (just right click a tile or entity to modify its properties).

Next I'm going to implement some basic animation for the character.

Tile Models

When I implemented my basic collision detection algorithm, I had no good way of determining which tiles were blocked and which were free. So, as a temporary hack, I used the existence of one of the layers being marked 'on' to indicate that the player should not be able to move through the tile.  Of course, this is a bad idea because it couples layer configuration to model configuration--it doesn't let me put anything in that layer without that tile becoming blocked.

An alternate solution would be to instead figure out the model based on the graphics used for the tiles. For example, grass would be marked as non-blocking while rock walls would be 'blocking'. However, this is still too much coupling, since it makes things like invisible barriers--or perhaps walls you can walk through--impossible.

So, I decided to completely decouple tile models from graphics. I added a separate Model property to Tiles, which is controlled via a context menu (and copy-paste) in the editor. Currently there are only 3 model types--Empty, Solid, and Triangle (any of which can be rotated, but currently it only makes sense for Triangle).

The following video shows me walking around with no models, running the editor and adding some models, and finally walking around with the models properly set for the rock structure on the left.

Collision Detection Fix, Editor Tile Preview Update

Updated the collision detection algorithm to fix the bug I mentioned before. Now the player can freely slide across tiles without getting stuck. Also, a video preview!

Also fixed a bug in the editor where tile previews weren't using their proper texture coordinates, so any tile/entity that was specified as a sub-section of a sprite sheet would be rendered incorrectly in GDI. Here's a video of my playing around with the editor.

Character, Camera, Collision

Added a character that moves around with keyboard input. Soon I'll figure out how to hook up gamepad input since that's what the game is being designed for, but for now arrows will suffice. Here's a screenshot of the temp art for the character. 

I guess I'll need to start using some sort of video capture since screenshots can't really display movement. Anyway, I've also implemented very basic camera functionality that automatically moves around when the character is a certain distance from the center of the screen.

Finally, I added the most rudimentary collision detection. Since I have no data representation of a Tile's physical model (just the graphics), I used the existence of a certain layer ('Ground Layer 3', which the rocks in the screenshot are on) as a temporary indication that the tile is 'filled'. It is a very simple collision resolution algorithm, and as such has the ever-so-common bug of the player getting 'stick' at tile creases. I'll fix it shortly!

Bootstrapping the game

Not too much to show since the changes were mostly at the infrastructure level.

• Fixed a bug with matrix transformation where the View (camera) was double the size it should have been. 
• Bootstrapped the actual game executable, which more or less just loads the map and displays it with code similar to how the editor runs. However, instead of working directly with the data objects, they are first transformed to models. This should make things easier down the road when implementing moving entities, animation, etc.
• Modified the texture data to specify a pair of texture coordinates and updated the texture set editor so that these values can be modified. This was necessary for dealing with image sources where the source file has been enlarged such that both dimensions are powers of two, but the image doesn't fill the entire canvas. This will also come in handy for sprite sheets, should I choose to use them.

Anyway, a screenshot of the actual game. Nothing new here, except a temp sprite that represents the player's position.

View Layers configuration

Abstracted the same class that controls the 'copy layers' configuration for 'view layers'. This lets you toggle what layers to display. There's a similar submenu under 'View' that lets you toggle layers on and off.

I also added a right-click handler to these menu items since re-opening the menu is tedious if you want to toggle several layers.

Tile updates, advanced copy and paste

Because the tile properties were going to get rather busy when introducing horizontal flip / vertical flip / opacity (in addition to texture and color), I created a form for modifying these properties.

I added some temp graphics from Link to the Past to make development a little easier on the eyes. Anyway, this form is pretty self-explanatory, it allows you to change the graphical properties of a tile.

Because an extra form means extra clicks and I wanted to preserve efficiency for basic cases (simple colors, 0/25/50/75/100 opacity, etc), I created a convenient right-click context menu on the texture selector to let you quickly pick and apply properties to the tile instead of opening the form. Currently the 'texture' submenu loads (lazily, at least) all textures, shown below. When the list of textures gets larger, I'm thinking of implementing some sort of 'path' organization to the texture set editor, and that path will drive a submenu structure (for example, Textures -> Outdoor -> Grasses -> Grass 1). For now, the flat list will do.

Since I'm working with layers, I figured it might be convenient if I were to be able to use the 'drag-style' copy and paste to quickly fill an area with, say, grass. The problem is that currently copy-paste (and 'drag', which uses the same paste implementation) was copying all tiles, so if you wanted to change one of your ground layers quickly (say, from dirt to grass), all of the other decorations would get wiped out. To solve this, I implemented the 'Copy Layers' menu, shown below, which toggles individual layers to be considered part of the paste operation for tiles.

I also implemented the display of transparency, horizontal flip, and vertical flip. Added 'custom' to the background and grid color selectors on the view menu.

Modifying the size of a section

Added the ability to resize sections. By default, tiles are added to the right (if you extend the width) and top (if you extend the height). Similarly, shrinking width or height will truncate tiles from this direction. I've added check boxes so that this behavior can be inverted such that the left or bottom is extended/cropped instead.

The resizing is done through the section properties form, which can be accessed through the Section menu.

Adding some color

Updated the Tile Stack Editor. I realized quickly that the existence of a selected texture was not a good way to differentiate whether or not a Tile on a certain layer existed. So, it's now controlled with a check box next to the name of the layer. Checking the box adds the tile to the stack, unchecking the box removes it and clears the data out.

I also added a color picker next to the texture picker. Once you turn a layer on, the default color is white. Here you can see I've made the bottom tiles red.

Other minor updates:

• Implemented copy and paste of tile stacks, same as entities
• Implemented 'drag' copy of tiles, holding Ctrl and dragging a tile copies it as you drag the mouse around.
• Implemented 'fine control' drag of entities, holding Ctrl while dragging ignores snap-to-grid entirely.

Entities and other editor options

Entities can be created by clicking the plus icon in the upper left corner.

Similar to Tiles, the entity editor on the right allows you to change the texture of the entity with the same selector. Entities can be moved, resized, and rotated by using the handles directly in the editor. Entities can be duplicated, copied, and pasted.

Entities snap to the grid when moved and resized. The grid can be increased and decreased in size by using the plus and minus keys.

The background color of the editor, as well as the color of the grid, can be changed from the View menu. The File menu has New / Open / Save / Save As.

Introduction

What is this?

Super Obelisk is a game I'm creating. It's partly inspired by the style of older Zelda games--most notably, Link to the Past--but also by the difficulty of games from that era. Ideally, I'd love to play a game with the difficulty of  Demon's Souls but the layout and progression scheme of Zelda games. Since I don't know of any games that satisfy these criteria, I've decided to make it myself.

Who am I?

I am Eric. I love playing and designing games, and I love programming. I plan on using temporary art (from Link to the Past!) for the period of initial development, and eventually working with professional artists to start bringing my game world to life.

What's the story of the game?

I don't have one just yet, but it won't be the focal point of the game. I truly believe in gameplay first--a story should never get in the way of the game. I have half a mind to intentionally leave the story minimal. One of my favorite games of all time, Super Metroid, gives the player about 3 minutes of 'story' at the beginning of the game and proceeds to immerse the player in a beautifully crafted world, creating a notable experience not through plot, but through solid gameplay, memorable locations, and great music.

What technology are you using to create the game?

• C# for the game engine and tools
• SlimDX for rendering
• Lua for scripting (most game logic in is Lua)
• C# for behavior programming (previously Lua, I've instead adapted a plugin architecture in C#)
• JSON for serialization of levels and other data

I'll add other technology as needed (I haven't investigated the best tool for audio yet).

So what's with the blog?

I'd like to document the process of creating this game from start to finish. Although I've put a few days of work in already, there's not much there yet, so a single post should be sufficient to bring the documentation up-to-date. So, without further ado, let's start!

So far the code consists of:

• Four projects. The game, the world editor, the texture set editor, and a utilities project.
• Map structure is simple a list of Entities and a two-dimensional array of TileStacks
• A TileStack represents an (x,y) location on the map and consists of a list of Tiles.
• A Tile has a texture and a layer.
• An Entity has a position, size, rotation, texture, and layer. Entities represent objects not bound to a particular indexed location and will be used for decorations, moving objects, enemies, items, etc.

Here's the editor when we launch it:

Now we go to File -> New to create a new Section.

The default map configuration is a section of 10x10 tile stacks. As you can see, each of these stacks is empty.

Clicking on one of the tiles while in Tile Selection Mode (top left icon) brings up the tile editor. The tile editor simply shows each layer (pre-defined) and allows us to change the graphic for that particular layer.

From here we can click on a gray box (which represents no tile selected for that layer). This launches a file browser. Selecting an image will set the Texture of that tile, assuming the selected image exists in the Texture Set (managed by the texture set editor).

We can also clear any tile by clicking the 'X' button for any layer.