Coming in to Port, the C# way

So the past couple of days I have been looking in to C# as a programming language. I was amazed at how similar it is to C++, and still how much easier it is to use. I decided that C# would be a better suit for the game engine that I am building right now. It will also help me get to know C# very well, and will be a great learning experience.

So for the past couple of days I have ported my Component-Context code over to C#, with great results. I C++, I had many problems with including headers from other classes. In C++, the order in which the compiler finds the declared classes allows you to use those class in defining others. This was a big problem because many of my engine classes depended on each other. I had to resort to using prototyping, which I think is ugly. In C#, this order does not matter, making cross-dependency much cleaner and easier.

However, C# is much less flexible in terms of templates (or Generics as C# calls them). This made me rethink my structure for managing the components and contexts. This restructuring was good, and made the structure much more powerful. When you attach a component onto an entity, the component itself is responsible for registering itself with the respective Context. This gives it more flexibly, while simple as well.

So far I have been very pleased with C# flexibility and power. Along with Mono, I am able to keep an openness for different platforms. I also find MonoDevelop a very well designed IDE for C#.

A Quick Update

Hey Everyone, these past couple of weeks have been a little slow in terms of development of my 2D engine. However, I have made so notable progress. This Component-Context solution is working out wonderfully. It is easily expandable, and easy to use. I have added in the ability to use text and images in my engine. Take a look:

Recently I have also been researching Behavior Trees. Expect a post on those soon...

First Look

This week I have made good progress on my game engine. Last post I was working on the base of my component system. I have finished that up and made some other minor modifications. So far my game engine has three contexts, graphics, selector, and events. The graphics context takes care of everything drawn to the screen. The events contexts handles messages from the system to entities, and in between entities. The selector context allows me to define regions that are "selectable" to see if the user has click in a specific region.

So far this concept of Context-Component structure is going very well. It gives the flexibility, simplicity, and power that I need. Here is an example of creating an entity:

Entity* entitiy = createEntity("BOX",Transform(Vector2(0,0)) );
entity->attachComponent(new BoxSelector(150, 150));
entity->attachComponent(new SquareShape(150));

This will simply create a box in the middle of the screen 300 pixels wide, that when the user clicks on it, an event will be fired.

In order to test my game engine, I figured that it was time to make an actual game. I less than a day, I was able to make a simple Tic Tac Toe clone, called CircleSquare:

You can download the program here

GameStates, Contexts, and Entities.... OH MY!!

Ok, so as indicated by my last post, I am now working on the basic design of my new component engine. I have made good progress so far. I have been able to set up the basic structure, and recreate my previous GraphViewer application. So far my component engine has these elements:

GameState - This is pretty much the main game class for now. It holds everything that the main part of the game needs. Later on I will build a state manager that will manage different states of the application (Intro, game menu, credits, game, etc...)

Contexts - Every context manages a different part of the game (Graphics, physics, input, sound, etc...) These contexts allow the different sub-system code to be drawn out of the different Components

Entity - A basic game object that ties together various components.

Components - This is an individual part of an entity that is responsible for a specific task. For Example there is a graphics component that handles what mesh to draw, or what color to draw it. You can mix and match components in an entity depending on what you want to do with the game object.

Ok, thats about it for now. I will expect a demo of what I am doing sometime this week...

The Next Step

I have the opportunity now that GraphViewer is nearing completion, to start planning out my next step. My next objective is to create more of a simple prototype of my game. This involves creating a basic game class to base the game off of. I have seen many ways of setting up a base game class, but the one that I find is most effective is the component model. Here is pretty simple explanation by Robert Nystrom. Pretty much it splits up the roles of a single object in a game. There is a separate graphics component, that draws everything to the screen, a physics component, that handles everything physical, etc. You can plug and play different components depending on how you want the object to act. I have sketched up simple plan for my game:

As you can see, the GameState object has several contexts (which handle the graphics/input/audio API), and and "Object pool" of entities. An entity is simply a "thing" in the game. It could be anything, a star ship, a laser, or even a timer. It is merely made up of components. Every context also has a pointer to each separate component. This is where it differs from Robert Nystom's model, allowing each context know about each entity's components. This allows for optimization within each context. 

The GraphViewer Application

I have mostly finished up my Graph Viewer Application. It now reads a file with an extension ".graph" and dynamically displays it. Here is an example of such a file:

Graph.graph:

v(100,0)
v(-100,0)
v(0,100)
v(0,-100)
v(200,200)
v(200,-200)
v(0,0)
v(-100,-200)
e(6,0)
e(6,1)
e(6,2)
e(6,3)
e(6,4)
e(4,5)
e(1,2)
e(6,5)
e(1,7)
e(3,7)

As you can see, Vertices in the graph are denoted by v(x,y), and an edge connecting two vertices is denoted by e(v1,v2). The GraphViewer application then reads this file and displays it:

Now that I have this prototype up and running, I can start thinking about the mechanics of my RTS game. Imagine that each of these circles is a planet or star system, and that each line is a trade route. Every circle only has resources available that it generates on its own, or is "traded" from a neighboring planet. Thus (5) has resources generated from its own planet, and some from the planets (4), and (6). This is no "global" resource pool.

This will introduce a new level of strategy. An Enemy could "cut off" another world's resource by attacking a neighboring planet. The "capital" planet (which usually has the most resource usage) must be in center with the most neighboring planets just to sustain the capital planet. 

The First Steps

So after a few hours looking at various 2D graphics libraries, and trying to get them all set up, I found SFML. SFML is a very good and simple 2D media library, and so much more. Think of SDL, but modern. After a quick 10 minutes I was up and running.

As shown here, SFML is drawing a custom Graph class that I created (which is pretty much a list of points, and a list of the lines connection each point). This is a very good start for my GraphVeiwer application, which will help with future development of the RTS that I am planning.