Jump to content
  • Advertisement
  • entries
  • comments
  • views

About this blog

A modern epic about the struggle to create three dimensional games. Based on a true story.

Entries in this blog


XML in UDK using DLLBind

Hello everyone,

A while ago I started on a dll to process XML in UDK using DLLBind and C#. I have been extremely busy lately, so I decided to take what I had and throw it up on the internet. It is not 100% (It probably has bugs and can't generate xml yet), but it might help someone. I take no responsibility for it, and it is very in development code, but enjoy!


This is the stuff I talked about in a previous journal entry but a practical example.




Using C# Managed DLL's in UDK (or exposing managed dlls in an unmanaged application)

Hello everyone,

Today I would like to share a technique I researched in order to allow DLL files created in C# to be used in the Unreal Development Kit. I posted a very similar tutorial to the one I am going to post today on my blog on the UDK forums, however since not everyone frequents that site I will post a more detailed version here for the GameDev community.

Note: The steps outlined here might be a bit advanced if you are just starting out. If you get stuck feel free to ask questions, however you may also wish to learn more about what you are doing before attempting this.

The problem

So you want to use the DLLBind feature of UDK in order to add capabilities that you need for your particular project. However what if you are not a C guru or are more comfortable with using a managed language? Well you could say "I will simply create my DLL in C#!" however that will prove problematic as the C# dll will be using managed code which is far different from an unmanaged DLL (managed code is not a direct binary file but gets turned into IL and then there are issues with export tables and all sorts of other fun technical bits that you can read in a number of much better worded articles).

Possible solutions

If we had access to the C++ code of UDK we could use various schemes to interopt with our DLL like PInvoke or Com interop, however we are stuck with the DLLBind mechanism that UDK provides to us. We need to work within the confines of what it expects and so we are left with a few options.

The first is to write two DLL files. One that is our managed DLL and then write a C/C++ wrapper DLL that allows it to interact with DLLBind. This solution is a big pain because then we are forced to use C/C++ anyway! It makes writing the DLL in C# very unappetizing.

The second is to dissemble the DLL into IL code and manually add a VTable/VTable Fixups. This is possible but a ton of work and can be a bit nerve racking (for instance now you must learn IL and hope you don't screw something up).

The third (and the option I will present in this tutorial) is to use a template to allow unmanaged DLL exports from C# (using an MSBuild task that automates a lot of the work for us).

Unmanaged Exports Template

The very first step that we will need to do is to acquire the Unmanaged Exports Template from Robert Giesecek. His template will automate a lot of the work necessary for allowing our C# dll to be used in UDK. Essentially it will provide unmanaged exports that we can then call in DLLBind!

Follow the steps the site outlines to install the template. It just took putting the entire zip file in the ProjectTemplates directory. One thing that sort of tripped me up is that you locate the required folders through the My Documents folder and not Program Files (I guess I should have read it a bit more carefully!)

Then we can create a project based off of his template.

A Simple Example

I started with a very simple test DLL to test the capabilities of the approach. Here is the C# code I used:

using System;
using System.Runtime.InteropServices;
using System.Collections.Generic;
using System.Text;
using RGiesecke.DllExport;

namespace UDKManagedTestDLL
internal static class UnmanagedExports
[DllExport("GetGreeting", CallingConvention = CallingConvention.StdCall]
[return: MarshalAs(UnmanagedType.LPWStr)]
static String GetGreeting()
return "Happy Managed Coding!";


I compiled this DLL and put it in the User Code folder. I am using Windows XP so I built my DLL as a 32 bit dll, however if you are running a 64 bit operating system then you will want to change the steps appropriately. The MarshalAs is a way to tell C# how to marshal the return string to the unmanaged code. This allows us to control how the managed types are transfered to the unmanaged types of UDK.

Then I created a class in UnrealScript (Which was named TestManagedDll.uc (which should be obvious as that is the class name, but I thought I would point it out).
) that contained the following:

class TestManagedDLL extends Object

dllimport final function string GetGreeting();


Which I could call from my cheat manager like:

exec function testdll()
local TestManagedDLL dllTest;
local PlayerController PC;
dllTest = new class'PFGame.TestManagedDLL';
foreach WorldInfo.AllControllers(class'PlayerController',PC)

So then I ran it and saw in my results:

Passing Parameters

Right then we also would like the ability to pass parameters and we can do that like so:

[DllExport("GetGreetingName", CallingConvention = CallingConvention.StdCalll)]
[return: MarshalAs(UnmanagedType.LPWStr)]
static String GetGreetingName([MarshalAs(UnmanagedType.LPWStr)] String name)
return "Happy Managed Coding " + name + "!";


dllimport final function string GetGreetingName(string name);


exec function testdll(string greetName)
local TestManagedDLL dllTest;
local PlayerController PC;
dllTest = new class'PFGame.TestManagedDLL';
foreach WorldInfo.AllControllers(class'PlayerController',PC)


Reading Files

I assume a lot of people will want to use this technique to write C# DLL's that use .NET for working with files, since the UDK support for reading various file formats is so low. In order to do that we need to get the directory that the DLL is in, so that we can locate our files appropriately. We can do this using Reflection.

public static String GetAssemblyPath()
string codeBase = Assembly.GetExecutingAssembly().CodeBase;
UriBuilder uri = new UriBuilder(codeBase);
string path = Uri.UnescapeDataString(uri.Path);
return Path.GetDirectoryName(path);

[DllExport("ReadTxtFile", CallingConvention = CallingConvention.StdCall)]
[return: MarshalAs(UnmanagedType.LPWStr)]
static String ReadTxtFile([MarshalAs(UnmanagedType.LPWStr)] String name)
string retVal = "";
StreamReader test = null;
test = new StreamReader(Path.Combine(GetAssemblyPath(), name));
retVal = test.ReadToEnd();
catch (Exception ex)
retVal = ex.Message;
if (test != null)
return retVal;

You should then be able to put a file in the same folder as the dll and then load it up and get the contents.

It also needs:

using System.IO;
using System.Reflection;

So it should be perfectly possible with some rudimentary knowledge to make dlls that make use of XML, files, ect.

Returning and Passing structures

NOTE: The following content may or may not be the best way to approach this problem. I will share what I have so far as a starting point, however you may wish to investigate this matter further. The use of IntPtr can be error prone and buggy but sometimes custom marshalling is the only way to solve particular problem domains when doing this sort of work. I have done some use of using "ref" and letting it handle this sort of marshaling for me, however it does not appear to work in all circumstances.

private static IntPtr MarshalToPointer(object data)
IntPtr buf = Marshal.AllocHGlobal(
buf, false);
return buf;

struct MyVector
public float x, y, z;

[DllExport("ReturnStruct", CallingConvention = CallingConvention.StdCall)]
static IntPtr ReturnStruct()
MyVector v = new MyVector();
v.x = 0.45f;
v.y = 0.56f;
v.z = 0.24f;

IntPtr lpstruct = MarshalToPointer(v);
return lpstruct;


dllimport final function vector ReturnStruct();


exec function testdll()
local TestManagedDLL dllTest;
local PlayerController PC;
local Vector v;
dllTest = new class'PFGame.TestManagedDLL';
foreach WorldInfo.AllControllers(class'PlayerController',PC)
v = dllTest.ReturnStruct();

we get:

The other direction is also possible:

private static object MarshalToStruct(IntPtr buf, Type t)
return Marshal.PtrToStructure(buf, t);

[DllExport("SumVector", CallingConvention = CallingConvention.StdCall)]
static float SumVector(IntPtr vec)
MyVector v = (MyVector)MarshalToStruct(vec, typeof(MyVector));
return v.x+v.y+v.z;


dllimport final function float SumVector(Vector vec);


exec function testdll()
local TestManagedDLL dllTest;
local PlayerController PC;
local Vector v;
v.X = 2;
v.Y = 3;
v.Z = 5;
dllTest = new class'PFGame.TestManagedDLL';
foreach WorldInfo.AllControllers(class'PlayerController',PC)

(outputs 10).

When passing a structure as an out parameter you can do the following, however I have not been able to get the whole strings inside structs thing to work without crashing and if someone figures out how, that would be an awesome addition to this. I am willing to bet the problem is nested structs are not being marshaled correctly and you will need to do a custom marshaling to get it to work properly (which means using IntPtr and other magic).

struct TestStruct
public int val;

[DllExport("OutTestStruct", CallingConvention = CallingConvention.StdCall)]
static void OutTestStruct(ref TestStruct testStruct)
testStruct.val = 7;


dllimport final function OutTestStruct(out TestStruct test);

and your struct defined in UnrealScript like:

struct TestStruct
var int val;

FINAL NOTE: This method may have serious drawbacks and limitations. One huge problem is that you risk leaking memory like the titanic. I am not sure how well everything is getting freed... I urge caution. I am merely providing a technical basis but it will be up to you to assume the risks of the implementation for your particular project. I take no responsibility for the use or misuse of this information for any reason whatsoever.


Mastering Structs in C#
Getting Assembly Path

I hope this provides someone some assistance!




Starting a game in HTML5

So recently I have become interested in HTML5 and the new Canvas tag from a development perspective. Browser adoption is starting to catch up to the standard (although Firefox's Canvas element is still slow compares to IE9 and Chrome which is a bit lame) and HTML5 is starting to look like an attractive game/simulation development option.

My plan is to build a top down, tile based game with A* pathfinding and smooth tile scrolling. I want it to have all mouse driven interactions (following the golden rule of casual development), simple vector based graphics (created in Inkscape), and simple and laid back game play.

Starting development in such an early technology can be a bit of a dark alley. Sure there are some enterprising developers creating some game libraries for HTML5 development (such as MelonJS) and some examples/tutorials on the subject, but over all the whole thing feels a bit mysterious.

My intention is to create my own simple game framework built directly on HTML5 without using an existing game library for HTML5 and without resorting to any conversion technologies. The idea behind this is that I am not making a game for the sake of creating a game, but for the sake of learning the technology of HTML5 for multiple potential applications.

My current progress has looked at how to structure the game and what sort of IDE to use to comfortably write HTML5 content. I have settled upon Netbeans 7 as my IDE of choice. It supports HTML5 editing and has all of the tools that I need. I simply created a php project and removed any files it generated/configured my ftp settings to automatically upload the files to my webserver. It allows me to remain organized in my coding!

The only external library I am using as of late is jQuery. This is simply too helpful to pass up as it really simplifies a great number of javascript tasks such as trying to include external js files in js files (I was looking for a way to do include style statements to make the code more manageable, but some structural changes needed to be made because the call is asynchronous).

Here is a wip shot from the current title screen that I am using for testing. The game centers around a smiley face (simple art assets) on a quest to gain happiness after losing the love of its life in an IM conversation.

Here is some of the very basic and potentially horrible html5 im using:

Journey of a Grin

Journey of a Grin

Unfortunately your browser does not support the HTML5 canvas element!




Game updates: Title screen, menu, bug fixes

I thought I would post a quick blog entry to showcase the latest progress on my game: Attack of the Dapper Gerbils. It is a Game Maker 8 (LE compatible even though I have pro) game created as an example for my middle school students (and because I want to).

Here are some of the current screen-shots:

I really like the menu screen. I added some switches that get activated when the current entry is selected and some lights that illuminate to show the current choice. The entire thing is really over the top but that is perfectly fine.

To add to the over the top nature of the menu, I made it so that the MENU text "explodes" when enter is hit. This was accomplished using the following script in GML:

delta_x = x - bomb_obj.x;
delta_y = y - bomb_obj.y;
dist = power(delta_x,2) + power(delta_y,2);
bomb_force = 150000.0/dist;
vx = bomb_force * (delta_x/(abs(delta_x)+0.0));
vy = bomb_force * (delta_y/(abs(delta_y)+0.0));
exploded = 1;

The distance between the two objects here is squared and by finding the "bomb_force" we are using a 1/r^2 force law. 150,000 in this case is just a "magic number" that gave an appropriate effect and is the result of constant absorption (Technically bomb_force in this case is more of an acceleration and the mass has been absorbed into the constant). I find a normalized vector (broken into components) between the bomb and the letters and then multiply this vector times the explosion. Also my code is setting this acceleration to the velocity x,y components but this is just taking advantage of the fact that the letters are for the most part stationary... I should probably adjust it to add to the vx and vy variables but I will do that when I get around to refactoring the code.

I like the wizard/mage guy here. I drew a really crude animation for him where his hands open and close and he blinks and moves his mouth. I want to make some ominous clouds roll in and then have him summon a zombie gerbil (a well dressed zombie gerbil).

In this update I removed my previous crudely drawn background in favor of a solid color. I find it less distracting.

Here we see the camera effect of centering on the door when the last orb is collected. This was accomplished using timelines in Game Maker.

Here I am riding on a cloud. To implement this I created a second x velocity component. When we are on a moving platform this velocity component is set to the velocity of the platform and when we are not on a moving platform this term is set to 0. Treating it this way allows us to still move around on top of the platform.

Want the source?

Get it here! If you want to use anything from it, please be my guest. You are welcome to use any of the "artwork" in the game. The music is all from Incomptech . The sounds were retrieved from the internet although I edited a few of them in Audacity to get more of the effect that I wanted. I do warn that the code is a bit of a mess.. I used scripts where I found it too tedious to use the visual action system but I did not use exclusively script because I wanted it to be relatable to my middle school students (I wanted them to be able to see the relation between what we were doing in the class and my game).

If you don't have game maker and you want a playble exe demo clicky.

Thank you for reading!




Faking It: Platform Game Ai

Today's blog post is going to start talking about game AI for my untitled in progress game using Game Maker. I have come to the point in my game where I need to start making enemies that behave somewhat more intelligently than a sack of potatoes.

To start with I realized that there is a commonality between my player and the enemies when it comes to interacting with platform elements. Both the player and the enemies need to be able to respond to gravity and have similar interactions with platforms in the game. Furthermore all enemies regardless of type will also need this behavior. The approach in some languages might be to create an "entity" class and have both the player and all entities inherit from this base class. I decided though that this might be a bit of overkill (after all while enemies and the player are similar, they are also very different) so instead I am opting to create a set of common routines to check platform collisions to share between the player and enemies. I am also creating a base enemy class which all enemies will use as a parent (Game Maker uses the term Parent, but this is the same concept as inheritance in other languages).

Here is check_platform_collision:

test_obj = argument0;
return collision_rectangle(test_obj.x + test_obj.sprite_width/4,
argument1+test_obj.sprite_height+(argument2-1),test_obj.x + (test_obj.sprite_width*0.75),argument1+test_obj.sprite_height+argument2,platform_base,false,true);

and check_platform:

test_obj = argument0;
temp_y = test_obj.y;
col_id = check_platform_collision(test_obj,temp_y,1);

if(col_id >= 0 && test_obj.vy > 0)
test_obj.vy = 0;
temp_y = temp_y - 1;
test_obj.jump = 0;

return temp_y;

Basically the code is simply to return the new y coordinate of the player after the collision checking is done. I am still working on writing a common routine for ladder collisions which currently is duplicated and looks like this:

col2_id = collision_rectangle(x,y,x+sprite_width,y+1,ladder_bottom_obj,false,true);
if(col2_id >=0 && climb)
climb = false;
ypos = ypos -2;

So we currently have a base enemy "object" and an enemy type that inherits from that base called gerbil. In my game the enemies are going to be gerbils with top hats... Currently though I have an ugly stand in programmer graphic of a box.

Alright so I have set the stage for how I am creating a base enemy to start programming my AI with. I have a common set of routines between my hero and enemies to not repeat code and I am inheriting from my enemy base class for all enemy types.

But what AI do I use??

The heart of the question now is HOW do I add enemy AI. For my player the logic goes that I respond to player interaction and adjust variables (in my case vector velocity components... fancy math speak for saying I take my velocity vector as represented by vx and vy variables, performing euler integration by adding acceleration to my velocity and then adding my velocity to my position... Or even simpler I made a platform engine type thingy).

If I was creating a networked game then I could create custom events that are triggered instead of direct user interaction and then create a queue of "actions" much like you would do in a time management game... So my enemies could do the same and I could call events that move the character instead of responding to input! but then I am left with the problem of when do I call these events? Is it worth doing this or is direct manipulation of the variables a more valid approach? Both have advantages and the designer is left to answer such questions.. I am going to experiment with the user defined events in Game maker that are called, and then my scheme must call these events to cause the enemy to move. The logic is then to "control" the enemy in much the same way the player is being controlled by the player.

Neural Networks and Genetic Algorithms!

So we need to do AI and anyone who has a casual interest in the subject but no real experience with actually making a game, might be inclined to say something along the lines of "I will use a neural network, fuzzy logic, and genetic algorithms for my game!" which is really a pointless combination of buzzwords designed to make anyone who says it seem somewhat intelligent.

The problem with this approach is beyond being utterly complicated it will not yield a fun and playable AI. The real way that most if not all game AI is done is by finite state machines which sound like some really complex and abstract concept! Let's quickly create a state class and a bunch of other fun states to be inherited from it and then use a dynamic array to manage all of our fun states! and then let's create a state transition table and do all sorts of fun stuff while we try to figure out how we actually "use" this mess we just created!

Or... perhaps not. In my mind the main approach to take when creating an AI in this situation is to layer behaviors. What I mean is that I am going to create a combination of behaviors and responses to conditions that the enemy can encounter and by crafting enough responses to enough conditions I will eventually arrive at something that looks intelligent. This can be comfortably done using various if/else statements and there is no real reason with proper abstraction to do more unless your creating a massive project.

I can also choose to perform certain behaviors are random intervals... but probably not COMPLETELY random intervals. Everything when it comes to such behaviors is best talked about in terms of weighted probabilities. For instance the probability of my next action to be continuing to type this blog post is higher than the probability of my next action to be to break out in an elaborate dance routine. To implement this we can use a random number generator that provides equal weight to each numerical outcome and then look for various ranges of values when we check to see which state to use.

State in this case is not really referring to an object (although I am sure people will disagree, we must make simplifications sometimes) but an abstract concept... State is the current values of all variables in the enemy object and to transition states is to change one or more variables to cause some new action (changing our x velocity to go right instead of left, or zeroing out the velocity to stop.). State transitions are the if statements that govern which enemy states to use.

The rules from transitioning to one state for another are either going to be based on random events or based on met conditions (such as the enemy is in range of the player).

Also I am going to introduce some variables to the enemy to represent certain physical properties. For instance I could have a variable indicating the enemies stamina. If the stamina gets too low then the enemy will go to a resting state. Once the stamina is regained then we can choose to perform a random weighted state transition OR if the enemy is close we can attack, ect.

The next blog post I write is going to talk about how I go about implementing these concepts in my game. I am currently working on routines to check if an enemy is about to leave a platform, if an enemy is over a ladder, and other routines to gain information about the game level. This will allow me to implement a form of steering behaviors for my enemies as well.

Thank you for reading!




The New Gamedev And Slew Of Journals

Hello everyone, I woke up this morning to see snow and the brand new GameDev.net site! The entire site is taking me some time to get familiar with and I am still trying to get to grips with the updated user ratings.

It appears as if all GameDev users have blogs... which may be a mixed blessing. I appreciate the fact that giving everyone the opportunity to post a blog will perhaps provide new content and more interesting articles to read, potentially by people who did not have a subscription to GameDev in the past, however I really do wish that people would put more thought into their posts.

Today I actually saw a journal entry containing the word "ok"! I am not singling out a particular user, however such entries will eventually diminish the value of the developer journals... It is not that I think every entry is going to be a sentence, but if every new user decides to experiment with the fact they have a blog then we could quickly see a lot of first blog posts... Before this would not have been an issue due to the relative small subset of users subscribing to GameDev, but now it could completely dominate all of the latest journal posts. I for one have found the journals in the past to be filled with wonderful information... and I think paying monthly for a journal helped to keep the journals in the realm of people interested in actually posting meaningful content (I did not purchase a GameDev subscription until having been around the forums for a number of years for instance).

On the other hand there could be an increase in the number of good journal entries now that there is an increased number of journals and I definitely look forward to reading those!

I guess time will tell... maybe everyone just wanted to post a journal entry to try it out and eventually things will become more "normal". Potential fixes if it does become a problem might be to create a minimum word count for an entry!

One feature I am liking of the new journal system is the ability to attach files to my entries. This will hopefully enable me to share files with you all (such as the source in my last journal entry) without having to worry about bandwidth issues. I am also looking forward to playing around with the formatting options for the journal entries and the themes. I do wish the long title of my journal didn't appear broken under FireFox... For now I am going to leave it alone and maybe it is just a bug that needs to be fixed (the journal title was fine under the old GameDev).

Thank you for reading. My next journal entry is going to cover AI for my side scrolling platform game. In the mean time I hope everyone has fun exploring what the new GameDev.net has to offer!




Going backwards - Digital adventures of the second dimension


Hello! It has been a long time since my last journal entry here on GameDev. I have been extremely busy, but I hope everyone has had a great Christmas/New Year/Other Holidays!

Newton's Enigma is still under active development. I recently downloaded the December UDK and I am excited to begin playing around with some of the new features.

Today's post is going to focus on a different project of mine. As part of my research project I happen to work with middle school students in order to teach them game creation. We accomplish this task by using the Game Maker program by YoYo games. The challenge that we present to the middle school students is during a school year they are to develop their very own Game Maker game in teams after having been taught basic game design/programming concepts.

While I have game development experience in other languages, and Game Maker experience, I have never developed a full game in Game Maker. I decided that if I was to ask my students to create a game in Game Maker, I must create a game of my own. In my mind confidence in an instructors abilities must be demonstrated and not assumed.

The project

So I decided that I needed a game project to develop and I settled on creating a generic two dimensional side scrolling platform game. This type of game demonstrates a number of valuable concepts such as scrolling, enemy AI, and variables without a lot of other potentially more complicated issues such as layering and coordinate transformations (which would be present in top down/isometric perspectives).

The goal is to create the entire set of graphics, animations, and programming code (in game maker) myself. I am using royalty free music and sound effects from the internet (properly credited) because such things are beyond my scope of both time and experience.

I am a huge fan of Dos games such as Commander Keen, and Hocus Pocus, and so I decided that I would like to involve some similar elements but under my own style. In terms of design principles the entire game is to be made up as I go along but I want the game to grow organically. What this means is that every feature is to be heavily tested and prototypes and nothing is to be added for the sake of adding it, but because it is directly needed by the game. For instance I would not add springs soley because another game has springs. I would only add such elements if I had a level or a design that required them.

The game is designed and created in Game Maker 8 Pro, using the sprite editor for all graphics and designed with a 320x240 view.



When possible the Game Maker visual scripting system is being used for the game. However there are some situations in which this system becomes unwieldy to use. In this situation we make use of the GML script ability.

One script that was written was to display helpful messages to the user. This piece of script is draw_info_box.

sign_x = argument0;
sign_y = argument1;
sign_txt = argument2;


border_size = 2;
sign_width = string_width(sign_txt) + border_size * 2;
sign_height = string_height(sign_txt) + border_size * 2;

draw_rectangle(sign_x - sign_width / 2,sign_y,sign_x + sign_width/2, sign_y + sign_height,false);
draw_rectangle(sign_x - sign_width/2 ,sign_y,sign_x + sign_width/2, sign_y + sign_height, true);

draw_text(sign_x + border_size ,sign_y + border_size, sign_txt);


Another script that was used is when it comes to getting the player out of a platform. We check for collision with a platform base (making use of the parent system of Game Maker which is a lot like Inheritance in other languages) and we move the player up a pixel until we are no longer overlapping the platform.

ypos = y;
col_id = collision_rectangle(x + sprite_width/4,y+sprite_height,x + (sprite_width*0.75),y+sprite_height+1,platform_base,false,true);
if(col_id >= 0 && vy > 0)
vy = 0;
while(collision_rectangle(x + sprite_width/4,ypos+sprite_height-2,x + (sprite_width*0.75),ypos+sprite_height-2,platform_base,false,true)>=0)
ypos = ypos -1;
jump = 0;

col2_id = collision_rectangle(x,y,x+sprite_width,y+1,ladder_bottom_obj,false,true);
if(col2_id >=0 && climb)
climb = false;
ypos = ypos -2;
y = ypos;

if(x+vx 0 || x+sprite_width + vx > room_width)
vx = 0;

The Orb count is dynamically drawn like so:

x1 = view_xview[0] + view_wview[0] - 20;
y1 = view_yview[0] +2;
orb_txt = string(orb_cnt-instance_number(orb_obj))+'/'+string(orb_cnt);
if(orb_cnt - instance_number(orb_obj) == orb_cnt)
draw_text(x1,y1, orb_txt);

The orbs above the door rotate around and increase every time an orb is collected. This is also done using a script:

total_orbs = hero_obj.orb_cnt-instance_number(orb_obj);
orb_ang = 0;
if(total_orbs > 0)
orb_ang = 360.0 / total_orbs;

for(orbIdx = 0 ; orbIdx 1)
orb_x = x +8+cos((rotate+orbIdx*orb_ang)*(3.14159/180))*20;
orb_y = y - 20- sin((rotate+orbIdx*orb_ang)*(3.14159/180))*6;

What I have learned so far

One thing that I have been enjoying about this project is the fun of creating a random game. It is nice to create a game in a stress free manner and my game development experience in other languages/technologies has helped me make good use of Game Maker features. I also feel more confident in my ability to use the Game Maker technology to teach Game Programming.

While the game is still under development, you are all welcome to download the full Game Maker 8 Pro files and a demo exe from my website: CGame Demo.

My only restriction on using the file is that if you use anything from it, please credit me for the use. You are welcome to use the graphics, borrow pieces of the code, or whatever you would like to do, so long as I get a mention. The graphics are not great but I know that even programmer art can be difficult to come by.

Thank you for reading!





This is a screenshot from a demo level I made using UDK for a symposium I recently attended. The purpose of this level was to build my skills in the level editor program, to experiment with a modded HUD, and to learn Kismet/Matinee.

The picture to the left of the image is a model I have previously shown that was created in Blender. The doors to the right have a logo of my school's mascot on the doors.

As I approach the doors, the doors open. This was done using two triggers placed on in front of the doors. If I overlap the trigger, I have a kismet script that plays a matinee animation to open the doors. For the animation the first frame is the doors closed, and the second frame is the doors open. This animation is composed of two separate movement tracks for the right and left doors respectively.

For this level I wanted to experiment with an outdoor scene, and specifically I wanted to be able to transition from an interior level to an exterior scene. I did not want it to be obvious that this level had an outside component and so I hid the only escape to the outside level behind a machine that I can move out of the way with the physics "manipulator" (a.k.a gun).

I also wanted to experiment with the vehicle system and terrain and so I combined those two things together in order to play around with vehicles driving around. I wanted to also play with speedtree as well, but I ran out of time before the symposium.

To the far left is the start of a spiral staircase which leads to the second floor. Straight ahead is a switch on the wall that when triggered causes a UI scene to be displayed (just an image).

Here we are going up the spiral staircase to the second floor. It was a real pain to get the number of steps/radius correct! and then building up the second floor geometry took a while.

We can manipulate these objects with the gravity manipulator.

More manipulations of the physics objects.

This is a shot of the editor and what the building looks like on the outside when you leave the building and enter a vehicle.

From here the next steps are to add more "manipulators" for finding the distance between objects and other data, add a journal for recording information about the world, and start testing ideas for some demonstrations. I also would like to display the forces acting on physics objects, and I would like to modify the vehicles so they do not fire projectiles.




Ground rules

Today I spent a little time and fixed the UV's on my microscope statue as well as cleaned up the geometry for the Microscope a little bit (made the base look a bit more level).

This level showed in the above screenshot is the Foyer level which serves as the hub for all environments. The hope is that if this world were to be expanded that different rooms could be added to this hub level (If say I added biology, chemistry, or mathematics to the mix).

I have also been watching more and more of the video tutorials for UDK and I have decided that my game is going to use unreal script for anything pertaining to more than one level (anything "engine" specific) and will use Kismet for any scripts that pertain to things that only happen on one level. So if I need a dialog system throughout the game, that will be in Unreal script and if I need a button to turn on a light or a door that opens that will be coded using the Kismet system.

The reasons for doing this are that the hope is that people will be able to edit the work easier. Also if a script is only ran very infrequently than speed is not really that much of an issue. I would rather not invest time on doing everything in Unreal script if it can be implemented "quicker" in the visual kismet system with no real speed loss.

My next journal entry is going to go into some information on UV texturing. I would like to describe the process I am going to use to add a series of opening lab doors which will work similar to one of my first journal entries where I described something similar in my former code base. The difference is this time we are doing it in full 3d, we are going to be doing it in UDK, and we are going to be animating it using the Matinee animation system, opening it via a UDK trigger, and implementing the door open using the Kismet system. This lab door will lead to another room where we will begin an introduction level for the physics lab.





I am back! I would like to start this journal entry with an apology, I am sorry for not updating my journal on a regular basis! This project has not fallen off the map, I just got a bit busy with both school work and on doing some hardcore research for the project.

So since we last spoke I have been evaluating technologies. I loved working in Python Ogre but the simple truth is that working at that level was becoming a bit of a time sink. Having to implement a full "game engine" and editors is a lot of work that eats up the majority of my research budget. I had hoped to be further along but the implementation of scripts and loaders and all sorts of other systems was starting to really drag on and I did not feel that I was getting to the "meat" of what I was aiming to accomplish.

With that being said I started than evaluating what technologies would be a better host for the project. Since I was using Blender for a lot of my pipeline I thought that making use of the Blender game engine might be a good call (it is also Python) but I found it to have a bit of a steep learning curve (like a lot of blender) but unfortunately there were not a large amount of resources to get started with the Blender Game Engine and I did not have months to learning an entirely new Python api.

What I really needed than was some kind of base to get my project off the ground that would provide more than I had for less time investment. When you make a move as big as the one I was planning in terms of tech, you have to go back and re-evaluate all your options including options you had previously abandoned for various reasons. It is also important to "narrow down" your requirements.

In my case I started to look at UDK. UDK has a lot of desirable attributes. It has a great editor, a strong first person base (which I decided would be the perspective for my game), and very good physics integration.

While Unity would also be a good choice for creating a game, I felt that the "free" version had some strong limitations that discouraged me from using it. While UDK also has limitations I felt that it was already close to the type of game I wanted to make and it is well battle tested. Overall I simply liked working with UDK better after playing around with both Unity and UDK, and so I decided to use UDK over Unity. Another huge factor were the video tutorials for UDK which I have found incredibly helpful in getting comfortable with the toolset.

Unfortunately the choice to use UDK has left me with a bit of a cut to my desired criteria in the fact that I have lost my cross platform support. However in my projects current iteration and with the timescale that I have available, I decided that this was a sacrifice that had to be made in order to get my idea off the ground and to start making progress in the time that I have left after tech changes.

Here is a current screenshot of what I have done in UDK:

As you can see from this screenshot I have created a level with a picture of Albert Einstein on the wall and a giant "golden" microscope statue in the center of the level. The video tutorials I watched helped me understand the process of level design in a 3d space a bit better and I have been working to improve my 3d modeling skills. The textures for this environment were created exclusively in Genetica 3.5 (The only software I currently use that is not free for use).

I am currently learning Unreal scripting which is exciting. While some might dislike being forced to work in the unreal way of doing things, I like the constraints as it forces me to make decisions. Having a blank canvas in which to work is sometimes very daunting! If you have infinite possibilities than moving forward can be a challenging task because you do not wish to box yourself in. However if you have those constraints than it is easy to continue because you know what you can and can't do. It to me helps me create a design because it narrows the way I can do things. To some this might sound counter intuitive and might make no sense but to me it works.

The next step from here is to customize the HUD and start creating my lab game. I need to work on a dialog system, learn how to manage an inventory, and all sorts of other things! I can see strong uses for both Kismet and Matinee and so I will be writing journal entries about all of those subjects in the near future.

I would like to take my blog on a new direction to providing some of my UDK progress and to provide some resources I learn along the way to help you all who are also starting out with this cool tool. There are several other blogs out there that cover the process of creating a project far better than I could ever hope to achieve, but the aim of this journal will be to do it all using free (or in Genetica's case affordable) tools and from a perspective of creating an edutainment type game (IE non violent and actually teaching stuff). I will aim to provide full assets that I use to create the content in my upcoming journal entries as well as potentially some video tutorials (if time permits).

Thank you for reading what has turned out to be a long blog post, but I guess I have a lot to say after a month or so of not updating my journal! I hope to talk to you all again soon.




Newton's Enigma Export

Today I have been working on an export script for Blender based on the Collada exporter. A lot of the code up until this point has been a straight port/simplification and I am in the process of refactoring the code to match my coding style. I am reducing the complexity of the plugin quite a bit because I don't need many fancy options. I will add more complexity later if I need it!

Here is the code I am working on currently:


Name: 'Newtons Enigma Physics (.nep) ... '
Blender: 249
Group: 'Export'
Tooltip: 'Export physics from Blender to Newtons Enigma Physics format (.nep)'

__author__ = "Donald May"
__url__ = ("Project homepage, http://www.m2-t2.com")
__version__ = "0.1.0"
__email__ = "donald@m2-t2.com"
__bpydoc__ ="""
Description: Exports Blender Physics to Newtons Enigma Physics format.

Usage: Run the script from the menu or inside Blender.

# --------------------------------------------------------------------------
# Newton's Enigma Physics plugin for Blender
# --------------------------------------------------------------------------
# Copyright (C) 2010: Donald May
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
# --------------------------------------------------------------------------

import sys
import Blender

class NEPhysExporter:
def __init__(self):
self.file_button = None
self.file_name = ""
Blender.Draw.Register(self.draw_gui, self.gui_event, self.button_event)

def draw_gui(self):
size = Blender.Window.GetAreaSize()
Blender.BGL.glRasterPos2i(45, size[1]-30)
Blender.Draw.Text("Newton's Enigma Physics Export Plugin for Blender", "large")
Blender.BGL.glRasterPos2i(45, size[1]-40)
Blender.Draw.Text("Version: %s"%(__version__),"small")

def draw_file_selector(self, size):
Blender.BGL.glRasterPos2i(45, size[1]-95)
Blender.Draw.Text("Export", "normal")


# Create File path input
yval = size[1] - 130
Blender.BGL.glRasterPos2i(45, yval)
if self.file_button is None or self.file_button.val == '':
self.file_name = ""
self.file_name = self.fileButton.val

Blender.Draw.Text('Export file:',"normal")
max_width = 400
if size[0] - (105 + 35) > max_width:
file_width = max_width
file_width = size[0] - (105 + 35)

self.file_button = Blender.Draw.String('', 5, 105, yval-5, file_width, 20, self.file_name, 255)
Blender.Draw.PushButton('...', 2, 105 + file_width, yval-5, 30, 20, 'browse file')

Blender.Draw.PushButton("Cancel", 3, 45, yval-35, 55, 20, "Cancel")
Blender.Draw.PushButton('Export and Close', 4, 45+55+35, yval-35, 100, 20, 'Export and close this screen')

def gui_event(self, evt, val):

def button_event(self, evt):

phys_exporter = NEPhysExporter()




A box is a box

So just when I felt like becoming productive Texas got a TON of snow Thursday and Friday that made getting work done impossible. Really this was the most snow that I had ever seen before!

Today I finally managed to get some real work done. I am using a new version of Ogitor that changes how scene files are exported and naturally that meant I had to do a bit of a recode on my scene loader. The good news is that now the scene loader is more standardized than it was so it should be the last time that I have to change it too much. Still to be on the safe side I would like to refactor the code some to make it easier to change.

Additionally in today's screenshot you will see a crate that I was playing with a few journal entries ago. This crate is actually going to be a standin "actor". I am going to be using this crate and it's interaction with the level to implement physics. The first goal is to get the crate moving and interacting with the scene and then I want to make the camera as the crate instead. Essentially it is breaking the problem down and eliminating potential problems. By focusing on making a crate move with physics I can focus on a small subset of issues and then work on a physics based first person camera implementation.

Speaking of physics, I keep bouncing back and forth between ideas of which physics engine to use. The natural inclination is to use whichever one has the working demos in my current release of Python Ogre, but from a sanity point of view the best choice is probably going to be Bullet. Bullet is a popular physics engine, it supports the Collada format (a big plus), and it is all around the physics engine that I am most impressed with upon looking at ODE, Bullet, and Newton. However the problem is that the Bullet demos for Python Ogre are broken... It is a bit of a risk because I like using libraries that have working demos but I am going to go ahead and try Bullet.

In terms of implementing the physics libraries the plan is to write a class where all of the physics binding is done and that the program calls whenever it needs to do anything related to physics... It is just going to be a bunch of methods that I build up over time and that the class will have the responsibility to implement. The plan is to make a base class and then inherit a class based on whatever physics engine I am using... This will allow me in theory to change physics engines if needed without requiring a ton of hard work and tracing through tons of code.

I also need to do some research into Blender and Collada. As appealing as trying to write a physics plugin for Ogitor is, I would rather avoid that whole mess if possible... I am sure with a bit of research I might be able to save a ton of time for myself and this project... But the first step is to get the crate in that picture to fall down with gravity and hit the "floor". That is my goal... It is my mission...and it will be accomplished!





The last few days have been busy but unfortunately I have had little time to work on the first person camera system that I was aiming to implement.

Between fixing computers that are running important physics experiments to helping to sell t-shirts to raise money for Haiti relief efforts, I have been a bit short on time.

I plan to get back to work tomorrow and catch up in work over the next few days so I might be posting more than one update as I am intending to work quite a few hours soon.

Why post if I have nothing to post? Well keeping this journal active is important to me for keeping my motivation on this project. If I let the journal become too inactive than I feel that my project is moving the same way!

I did do some more research on FPS camera systems and I believe that I have a design in my head that will work. I also had the revelation that the physics abstraction layer that I intend to write should merely be a bridge between Newton's Enigma and the physics engine... There is little need to write a generic abstraction layer for all of the physics engine's features, only write methods when I actually need work done and leave it up to the implementation to figure out how to call the engine.

I have also been thinking of how to handle collision geometry and I am hoping to implement that in Blender... I had originally planned to have the collision geometry editable in Ogitor but that might not be an effective use of time.





Sometimes when working on a complicated project such as a game, it is very easy to become overwhelmed by the amount of work that has to be done. That is why keeping a log of your activities can be very helpful! Whenever I feel like there is too much work left to do, I look back at how much I have accomplished up until this point and it keeps me motivated.

I have done some thinking as to my next few steps on this project:

1. I need to implement a way point system for the camera. Each quest marker will link to a way point. The way point will determine the camera position and the camera will look in the direction of the quest marker. I would like to implement a tweening effect to make the camera follow a nice arc to it's destination.

2. I have decided to have WASD keyboard movements for the camera because I determined that a click to move system would be more work than it is work. The quest system will position the camera in the direction I want it, and then the user will be able to control the camera from there (at least that is the theory).

3. I have done some research today into making an FPS camera system, however the Ogre wiki's fps camera code seems overcomplicated... I do not understand why so many scene nodes are needed to manage rotations and to "avoid gimble lock" when I thought that was the whole reason for using a quaternion or a matrix to begin with as opposed to just straight euler angles. Also I ponder if I need to look up some sort of camera controller and what would happen when I add physics to the mix. I imagine I would need to visualize the camera as a ellipsoid where the camera is positioned at the head of the ellipsoid and the ellipsoid itself handles collision detection with the game world. I am not sure how all of this will work yet, but I do know that I need to do some heavy camera work.

4. Speaking of physics I realized that I can implement the physics engine and work on camera movement, ect without the need to have all of it controllable via the Ogitor editor yet. This means that I have a lot of stuff to focus on without needing to handle terrain or any sort of plugins for Ogitor....

5. The addition of the physics can also be met with the addition of a revised menu screen system and the addition of an options dialog. Any sort of options dialog would imply the need for a profile system and so I would need to implement profiles, name dialogs, a profile selection screen, ect... It is probably wise to handle profiles soon so that I can work my code and the game mechanics around the profiles and save the appropriate values as needed.

6. I need to implement the tutorial system which will handle the actual physics part of this whole game. I am planning to call this system the "Lab Manual" although I am not sure when all of that is going to happen..

Ok so from this writting you can see that there is a good amount of work to do! Lots of little issues to fix, lots of major features to implement.... it becomes overwhelming at times, but then I look back at what I have done. I have managed to create a full scene system with transitions, implement a title screen and a menu, load a scene from Ogitor into my engine, build Ogitor from source, start my own plugin to handle physics, I have implemented CEGUI layouts, and I have implemented mouse picking... and I have done all of this work in a little over a month... So even though the amount of work that lies ahead is great, I will continue to move forward with the knowledge that I have already made a lot of progress and that I just need to break these problems down and tackle them one at a time.

I think the first order of buisness is going to be focusing on the camera controls and the FPS camera system. Right now I am tired of not being able to walk around my nice 3d world and so I am going to aim to fix that problem. I will also start the tedious process of implementing the physics which I plan to do via an abstraction layer.

This journal entry is probably a bit long so I will share with you all some more stuff tomorrow!





Today I worked on mouse picking. I can click the exclamation mark using query masks and I have enabled a bounding box around the quest marker when I click it so that the selection is visible. Also I have a camera look working with the right mouse button but that is temporary until I get some camera movement implemented.

Here is the selection code:

def select_object(self, evt):
scene_manager = self.screenMgr.getSceneMgr()
mouse_pos = CEGUI.MouseCursor.getSingleton().getPosition()

mouse_x = mouse_pos.d_x
mouse_y = mouse_pos.d_y

trans_x = float(mouse_x/self.screenMgr.getViewPort().actualWidth)
trans_y = float(mouse_y/self.screenMgr.getViewPort().actualHeight)

mouse_ray = self.game_camera.getCameraToViewportRay(trans_x, trans_y)

if self.ray_scene_query:
self.ray_scene_query = scene_manager.createRayQuery(mouse_ray)


result = self.ray_scene_query.execute()

if len(result) > 0:
for item in result:
if item.movable:
print item.movable.getName()
CEGUI.WindowManager.getSingleton().getWindow("desptxt").setText(item.movable.getName()+" selected")






Today I spent time evaluating various physics engines and so far I am leaning towards ODE for physics because it seems to most supported by Python Ogre at the moment. I will investigate further and try to determine if there are any other/better options. I would consider using Bullet, however the demos provided with Python Ogre so far do not appear to work, but I will debug those examples soon and see if I can get something working.

I also downloaded the source to Python Ogre today because I am getting impatient and I am thinking of trying to build the latest release from source so I can implement terrain from Ogitor.. The terrain system for Ogre has gone through major revisions between versions and the format that Ogitor exports is not the format I would need to provide to the current stable version of Python Ogre...





It might not be clear from the picture but recently I have been working on the start of a physics manager program for Ogitor so that I can adjust the physics in the game. Right now the plugin is very barebones but I am hoping to build it up over time....




Previously on...

Last saturday I had the unique opportunity as part of the same project in which I am developing Newton's Enigma to teach middle school students how to create computer games.

Over last summer we started using Microsoft XNA but the typing rate of your average middle school student combined with the difficulties of C# led to the majority of the students becoming frustrated. While they were able to comprehend supprising amounts of information and create modifications to my code that I had not thought of (their creativity is inspiring) I felt that their experience to game creation could be better served by a higher level game creation solution.

My solution was to go back to my roots. While when I was first starting out I used KNP, The Game Factory, and Multimedia Fusion (All from Clickteam), I opted for this group to use Game Maker by YoYo games. I had never used GameMaker before but I found the beginner interface was a really great interface for the students and they seemed to comprehend everything much easier. I also liked the fact that I could still discuss important concepts such as the Cartesian coordinate system, variables, and even some basic OOP, all without some of the more tedious typing details.

Over the course of an hour and a half we created a simple game involving a basketball moving using both the arrow keys and the mouse that collected purple balls to gain score and once all the purple balls were gone the next level was reached. It was somewhat refreshing to create the sort of games that are randomly designed and created in a short time period for entertainment! It took the pressure out of the game development and focused on the aspect of bringing an idea to life (however simple).

I guess the point of this entry into my journal is that sometimes it can be a refreshing change of pace to use authorware even if you know low level programming techniques... sometimes it can also be refreshing to just create a simple little game for no real reason... Sure the game that was created last Saturday won't win game of the year, but it was fun and I think that is something that is easy to lose sight of in the intense battleground that modern computer game development has become.

Thank you for reading.




My DotSceneLoader code

Today I am sharing a bit of code. My reasons for doing this are to see if there are any glaring issues in the code that you all might find like "Hey! Don't do that stupid!" and also to help other people who might be looking for resources on a particular topic.

The following code was based on a dotscene loader for Python Ogre I found while browsing on the internet however I coded it differently and used what I hope are more descriptive names. If there are any issues please feel free to let me know because I am not perfect and I am not a guru at Python.

import ogre.renderer.OGRE as ogre
import ogre.io.OIS as OIS
import ogre.gui.CEGUI as CEGUI
import ogre.addons.caelum as caelum
from xml.dom import minidom, Node

class DotScene(object):
def __init__(self, scene_mgr):
self.scene_mgr = scene_mgr
self.nodes = {}

def __setitem__(self, key, value):
self.nodes[key] = value

def __getitem__(self, key):
return self.nodes[key]

class DotSceneLoader(object):
def __init__(self, sceneMgr):
self.sceneMgr = sceneMgr

def load_scene_from_file(self, file_name):
rgm = ogre.ResourceGroupManager.getSingletonPtr()
resource_group = "General"
scene_file_list = rgm.findResourceNames(resource_group,"*.scene")

scene_data = None
for scene_file in scene_file_list:
if scene_file == file_name:
scene_data = rgm.openResource(scene_file, resource_group, searchGroupsIfNotFound=False)
assert isinstance(scene_data,ogre.DataStream)

scene_string = scene_data.getAsString()

document = minidom.parseString(scene_string)
doc_elem = document.documentElement
nodes = self.find_nodes(doc_elem, "nodes")
return self.create_scene(nodes[0].childNodes)

def find_nodes(self, root, name):
node_list = minidom.NodeList()

if root.hasChildNodes:
nodes = root.childNodes
for node in nodes:
if node.nodeType == Node.ELEMENT_NODE and node.nodeName == name:

return node_list;

def parse_coord(self, attribList):
return ogre.Vector3(float(attribList["x"].nodeValue),

def parse_quat(self, attribList):
return ogre.Quaternion(float(attribList["qw"].nodeValue),

def parse_colour(self, attribList):
return ogre.ColourValue(float(attribList["r"].nodeValue),float(attribList["g"].nodeValue),

def get_node_attrib_list(self, root, name):
return self.find_nodes(root, name)[0].attributes

def create_scene(self, root):
dotscene = DotScene(self.sceneMgr)

for node in root:
if node.nodeType == Node.ELEMENT_NODE and node.nodeName == "node":
#Let's create a scene node
new_node = self.sceneMgr.getRootSceneNode().createChildSceneNode()

#scale the node
scale = self.get_node_attrib_list(node, "scale")

#position the node
pos = self.get_node_attrib_list(node,"position")

#rotate the node
rot = self.get_node_attrib_list(node,"rotation")

entity_nodes = self.find_nodes(node, "entity")
#we have entities
if len(entity_nodes) > 0:
entity_attrib_list = entity_nodes[0].attributes
name = str(entity_attrib_list["name"].nodeValue)
mesh = str(entity_attrib_list["meshFile"].nodeValue)
entity = self.sceneMgr.createEntity(name, mesh)
dotscene[name] = entity

if node.nodeType == Node.ELEMENT_NODE and node.nodeName == "light":
light_attrib_list = node.attributes
name = str(light_attrib_list["name"].nodeValue)
light_type = str(light_attrib_list["type"].nodeValue)
shadows = bool(light_attrib_list["castShadows"].nodeValue)

#create a new scene node
new_node = self.sceneMgr.getRootSceneNode().createChildSceneNode()

#get the position of the node
pos = self.get_node_attrib_list(node, "position")

light = self.sceneMgr.createLight(name)

#set type
if light_type == "point":

#get the direction of the light
direction = self.get_node_attrib_list(node, "normal")

#get the diffuse colour
diffuse = self.get_node_attrib_list(node, "colourDiffuse")

#get the specular colour
specular = self.get_node_attrib_list(node, "colourSpecular")

range_nodes = self.find_nodes(node, "lightRange")

if len(range_nodes) > 0 and light.getType() == ogre.Light.LightTypes.LT_SPOTLIGHT:
range_attrib_list = rangeNodes[0].attributes
inner = float(rangeAttribLst["inner"].nodeValue)
outer = float(rangeAttribLst["outer"].nodeValue)
falloff = float(rangeAttribLst["falloff"].nodeValue)
light.setSpotlightRange(inner, outer, falloff)

atten_nodes = self.find_nodes(node, "lightAttenuation")

if len(atten_nodes) > 0 :
atten_attrib_list = atten_nodes[0].attributes
range = float(atten_attrib_list["range"].nodeValue)
constant = float(atten_attrib_list["constant"].nodeValue)
linear = float(atten_attrib_list["linear"].nodeValue)
quadratic = float(atten_attrib_list["quadratic"].nodeValue)
light.setAttenuation(range, constant, linear, quadratic)

if node.nodeType == Node.ELEMENT_NODE and node.nodeName == "camera":
camera_attrib_list = node.attributes
name = str(camera_attrib_list["name"].nodeValue)
fov = float(camera_attrib_list["fov"].nodeValue)
projection_type = str(camera_attrib_list["projectionType"])

#create a new scene node
new_node = self.sceneMgr.getRootSceneNode().createChildSceneNode()

#rotate the node
rot = self.get_node_attrib_list(node, "rotation")

#position the node
pos = self.get_node_attrib_list(node, "position")

clipping_nodes = self.find_nodes(node, "clipping")

near = far = 0

#we have a clipping node
if len(clipping_nodes) > 0:
clip_attrib_list = clipping_nodes[0].attributes
near = float(clip_attrib_list["near"].nodeValue)
far = float(clip_attrib_list["far"].nodeValue)

#create a camera
camera = self.sceneMgr.createCamera(name)
dotscene[name] = camera

return dotscene

I hope that you find the following code useful!

Thank you.




Just killing time

Today was one of those days.... I spent a good bit of time today looking through the Ogitor source and trying to figure out how to export terrain in the dotscene file... so I did some work and ran into problems... I also noticed that the dotscene exporter is writing the xml nodes as plain text and not creating the xml through TinyXML like I would have liked....

Anyway I looked online and I discovered that one of the programmers of Ogitor just today checked in code to export terrain files in the dotscene system and the code now uses TinyXML to create the save files so all of my work today is pretty much redundant....

While I wait on that code to stabilize and also wait what should probably be an impending release of Python Ogre 1.7, I am going to take some time to re factor my code and to implement mouse picking.... I will save terrain and caleum for a while until I run out of other things to do.





So today I played around more with the Ogitor editor. I fixed a bug of popup menus not refreshing properly by upgrading my Qt distribution to 4.6.1. I also explored terrain editing and the Caelum plugin for Ogre.

My current goal is to get the scene you see in the editor into my game engine.




a few crates

Today I set about modeling a simple crate using a crate texture that I generated from Genetica. It didn't take long but I now have a basic crate that I can use for the first actual level of the game.

I am going to be working on editing and generating terrain and adding a skybox soon so that I can have an adequate outdoor scene. Then I want to have a ramp and have a box falling down that ramp using some sort of physics engine. I then want to be able to take the mouse and move the crate around... with the properties for the crate editable from the Ogitor scene editor I am using... This is my goal and I have no illusions about the fact that it could take a month+ to get that done.

I also need to be designing the tutorial system and coming up with the actual game design/mechanics as I go... the problem is I am not sure what will work! but that is not stopping me from continuing to push forward and try something.





Just wanted to let everyone know that due to a readers comments I have edited some of the journal posts a bit to make the journal easier to read for people with smaller screens. The text should scale better so you won't have to scroll as much.

Thanks to Jotaf for the suggestion! I take my readers comments seriously so if there is something that you would like for me to talk about/change about this journal than please just let me know in the comments section.




Lab screen

Today I worked on the lab screen for the game. The artwork/layout are temporary but now I can switch between levels! I also refactored the code quite a bit today.

My next task is to start working on the very first actual physics content! While working on that I will work on mouse picking and adding an abstracted physics engine to the code base.




Some advice

Today I thought I would mix things up a little bit and post some advice for other game programmers out there about how to stay productive and sane when developing a project either commercially or as a hobby.

The first thing that I do on all of my projects is to always look for ways to avoid reinventing the wheel. This is not as easy as you might think! For every project you need to figure out what the requirements for the project are and then from those requirements you have to figure out which set of technologies are the "best" from your choices. Sometimes those choices are easy to make and sometimes they are very difficult!

One of the things we must do as programmers though is to constantly evaluate our requirements as we develop the project and look at what requirements are good requirements and which requirements are bad requirements! This is an important step because it is easy to generate a rather long list of artificial requirements that could cause you to ignore or throw out perfectly valid options.... At the same time however sometimes it is not practical to constantly change technologies and so you have to also learn when to just stick to what you have and suffer through bad choices.

The only real way to figure out if your requirements are valid is through experience... however there are still decisions you can make up front that might save you a lot of headache...

Here is a quick list:

A) Avoid making an engine for the sake of making an engine. The desire to make an engine is great but if you do not make a game in that engine there is no way you can figure out what features are needed to facilitate making a game... Scientific Ninja has a great article on this subject. Many times I read posts on the forums where a new user is out to make an engine from scratch and this choice can put a lot of artificial requirements on a project (and cost a lot of time to put).

B) Don't ignore free tools. If you can find a free and open source tool to help create content for your game then it is usually always a good investment of time to use that existing tool than devoting developing time to create your own tools...

C) Use C++ in the correct context! In my opinion you should use C++ for two reasons: You like the language and are comfortable with it,or you can't do your project in anything else. I realize this point might be controversial but I see a lot of new programmers deciding to use C++ because "everyone else" uses C++ and therefore they feel they should use C++ also... This can cause people to ignore other languages because they feel that C++ is the "only" choice for making a game. There are many other languages that might provide substantial increases in development time over C++ so it is important to consider a wide variety of languages and to pick the right language for the job. Sometimes the choice of language doesn't matter but I would personally recommend considering your options because a lot of times to really get the benefits of C++ you need to work hard on your code.....

D) DO NOT hard code values in your code. Magic numbers (And even strings sometimes) seem like a great idea at first... but if you ever want to change your code later it can become a gigantic pain to modify the code... Instead of magic numbers you should use constants or better yet try to load the data from an external file... Either flat file or XML will work (I personally prefer XML because it is easier to parse).

E) Take breaks... You really need to get up every so often and rest your eyes and your hands... Long programming sessions might seem productive and maybe they are to you, however long periods of sitting/staring at a computer monitor/typing can be detrimental to your health and if you have to stop development on a project for surgery you will find that the time savings are probably not worth ignoring breaks.

F) If stuck on a hard problem it is often better to come back to it later. Sometimes there have been bugs in my programs that have driven me crazy but I find that if I stop and do something else and come back to the code in a few hours/days then I can normally figure out the problems with a fresh perspective.

G) Do not program while exhausted. Sometimes you have no choice but to program while sleepy but most of the time this is an exercise in futility. You will usually not have the mental focus necessary to write good code if you can barely keep your eyes open.

H) Work on your project a little each day rather than trying to do everything in "spurts". I have to admit I used to do my best work in long days every 4th day and the other three days I didn't do much of anything! While this seems like a good idea... it can be damaging if you get stuck on a problem that requires thought... Breaking the work up allows you more time to process tasks. The best way to break your work up is to set small goals every day for yourself and set out to accomplish those goals by the end of the day. If you don't make your goal for the day then the following day scale back the task until you CAN complete something. Once you do then try to do a little bit more than you think you can do every day... The main thing is to always figure out your next step on your project and then to work on implementing that step... Essentially this will help you figure out how much time a task will take to program and it will help you with breaking down problems into small chunks.

Some of this advice might seem obvious and I am sure there are many other good pieces of advice that I have failed to mention... I hope however that you will find at least one decent tip in this journal entry that will inspire you to do more research on that topic. Please browse the wonderful article section here on the GameDev site if you do not already do so and read the advice there! I think the best piece of advice that I can give however is the following... and it is as true today as the day that it was written :




  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!