Archive for 'Crimson'
Im still alive
cubed2D
November 06th, 2007.
Still alive, still makeing progress! i started a rewite on Crimson Engine last month. Wanted to reimplement my object system and other things i thought wernt flexible enough. Just finished re implementing animated sprites last night, so its high time for an ‘im still alive’ post. I plan to write up some new tutorials and engine design posts over the next few weeks, and clean up the site abit!
The current state of crimson
cubed2D
July 23rd, 2007.
Two months ago i last posted about my progress with my game engine, Crimson. Things have changed since then. As I’ve previously mentioned, not done much coding has been done on the engine since because of real life and hardware problems (t minus 10 days till laptop returns!). Because of that, most of the progress has been in design. Here is what my class layout looked like back at that last update (all these classes were coded up when i posted this originally)
Well, as you can see, I’ve crossed off everything that doesn’t exist in my current design. That’s not to say this old functionality is being removed, just that its being moved around and redesigned to be a lot more powerful that it ever was before. I’m also trying to decouple the game simulation from the world view, a trick that i learned from reading Game Coding Complete 
 So, “how does it look now!?!” i hear you shout, well like this.
Each icon represents a different core area of the engine. Authority is the game rules, its where the simulation takes place. This will include a physics engine, the information on the current level, the data structures containing all the current entities in the world and things like that. You could almost think of it as a server (infact, this architecture is very good for extending your game to be multi-player). It also contains the command interpreter, which is very important! (shall all become clear soon)
The view is not a single piece of code like the authority, There is actually loads of em. Im implementing a base view which can be extended for more specialized purposes. They are basically filters on the game state(held in the authority). The most obvious example on one would be the player view. It has all the code in it for drawing the world to the screen, converting button presses in to commands, making music play and stuff like that. You could also make one to command a team of A.I players. It wouldn’t need any drawing code, but it would need to be able to sense whats happening in the area of world-space it can see (filtering everything it cant out)and then sending commands to the authority for the next step in simulation.
That’s where it comes exciting for me. The game I’m designing this engine to build will rely alot on A.I… good A.I that doesnt cheat. This system lets the A.I only get the same information a human player would, and use the exact same methods to interact with the game world a human is. For me, that’s big!
 So whats that last bit all about? have a closer look!
 
Please remember this is still far from done, its in a kind of half way state between class layout and program flow diagram! Whats important is that the class CrimsonEng is the engines entry point, create an instance and throw it a start-up script and the game shall load! Its basically a massive collection on managers which will be available for the other systems to use (via the interfaces and core libs). My current plan is to not use the default game class that xna ships with, as it wont fit very well with my engines design (maby more on this next time). Some interesting things here are things like eventMan and MessengerMan. Messages are going to be from entity to entity, good for A.I characters or triggers. Events will be for wider reaching things, like state changes or button presses. I think its important to separate and specialises these kind of messaging functionalities. Well, Thats it for this installment! Cant wait to get my laptob back to start building this thing!
Crimson Update: Vasculitis (v0.0.2.24380)
cubed2D
May 10th, 2007.
 So heres the layout of my engine at the momentÂ
Without any diagrams, things get messy quickly. I had the thing planned out in my head, i had no paper in my room, my windows were too small to write on (at home i design programs on my windows with dry wipe markers) so i decided to go ahead anyway, and not so surprisingly it got messy. I then decided to use blue J (a java ide we use in university) to draw down what id written so far. Now i know how things connect and i can visualize it better. Id say a visual program designer is a good tool, you can pull things and its cool, but not as cool as using a window!
 Animated sprites have been a fun feature to add, my implementation hangs around the concept of an animation sheet. my orc test sprite has some animations in separate.png files and some bunched together on the same .png. So how do i handle them? every animation gets a animation sheet, which contains its start frame, end frame and a reference to its texture. these are held in a dictionary as a value, the key to that dictionary is a CompassDirection (north, NorthEast ect). I have a load of these in a list, and i keep there indexes in another dictionary with a AnimationState(move, idle, jump etc). To get the correct animation sheet you just need to know what direction and animation you currently in and pull em out. More difficult problems were finding out the current direction and grabbing the current frame from a texture. At the moment i only support the xbox controller, so i needed a way to turn the vector2 returned from the thumb stick in to a cardinal direction. I did this using the magic of dot product. The dot product between two vectors will give you the angle between them. All i needed to do was to have a list of all the directions i wanted to test, try the dot product between them all and then use the animation with the smallest dot product (which would be the closet to the angle of the stick) Heres some code for you!
public class DirectionSet // the 8 compass directions represented in vectors
 {
 public Dictionary
 public DirectionSet()
 {
 directions.Add(0, new Vector2(0f, 1f));
 directions.Add(1, new Vector2(0.5f, 0.5f));
 directions.Add(2, new Vector2(1f, 0f));
 directions.Add(3, new Vector2(0.5f, -0.5f));
 directions.Add(4, new Vector2(0f, -1f));
 directions.Add(5, new Vector2(-0.5f, -1f));
 directions.Add(6, new Vector2(-1f, 0f));
 directions.Add(7, new Vector2(-1f, 1f));
 }
 }
Use this function to get the sticks direction:
public int GrabAnimationDirection(Vector2 stick)
 {
 float bestDot = -100;
 int bestAnim = 0;
 for (int i = 0; i < 8; i++)
 {
 Vector2 normal = Vector2.Normalize(directionSet.directions[i]);//normalise the directions
 float dot = Vector2.Dot(velocity, normal); //find the angle
 if (dot >= bestDot) //if its smaller, save it
 {
 bestDot = dot;
 bestAnim = i;
 }
 }
 return besttAnim;
 }
Then i just cast the returned int to my CompassDirection enum for use!
The other problem is alot easier, how do we choose the tile? First, we need a frame counter to increment. I increment it every 33ms (30fps). we also need to know the number of columns in the sprite sheet and the height and width of each sprite. with this info we can find the top left corner of each frame
int x = (frame % column) * width;
int y = (frame / column) * height;
Its really simple when you think about it, just grab a sprite sheet, and try these for a frame in the middle, I’m sure your understand how it works straight away!
The other useful thing i learned is how to cast a string in to a enum. Which is really useful when reading info out of an xml file.
(CompassDirection)Enum.Parse(typeof(CompassDirection), “North”);
remember to test its going to work first!
Enum.IsDefined(typeof(CompassDirection),”apples”);
would return false, because apples just arn’t directions no matter how hard they try.
anyways, Crimson 0.0.2.24380 new features!
Features:
- Better, more flexible animation system, which supports:
- Idle animations
- Movement
- Shooting
- Death
- and flexible to add others!
- Loading XML files which describe an animation, and serializing them in to actual animation sprites.
- early prototype of the input manager.
- updates to my content manager
also, for anyone who is interested, heres a short demo. It only works with an xbox controller at the moment. left stick moves you around, B jumps and A kills you. If anyone can run it and tell me how it runs on there pc id be grateful!
Crimson Update: Vasculitis (v0.0.1.423)
cubed2D
May 08th, 2007.
And now for an update on my Crimson engine! I’ve been working on the fist minor milestone, codenamed Vasculitis over the passed few days. The plan is for Vasculitis path to take Crimson all the way up to v0.2, and by the end its lifespan to have all the basic features (apart from scripting) implemented.
So far, ive completely rebuilt the screen system. Ive looked through Microsoft’s game state management sample and i loved the way they implemented some things (especially the transitions!). After playing with it a bit, it was clear id have to do a bit of retooling on my screen system, which ended up with me ripping out the whole screen system and starting from scratch.
 After that, i added in basic support for menu screens, worlds and UI popups. Then built a basic entity system, that currently supports static and animated sprites! been a busy few days! still needs allot of work and clean up, but its cool so far!
My animated sprites support single or multiple animation sprite sheets, and multiple animations. Heres a short video of an orc running around my test level. He’ only using the running animation (small bug at the moment with switching through different animations) but does show that sprite sheet switching does work, as each direction is on its own sheet.
Crimson build name Vasculitis (v0.0.1.423)
Welcome to the NekoCake
cubed2D
April 20th, 2007.
Hello,
first, an introduction, I’m Tim James, owner of NekoCake.com. I’m a Computer Science student, someday i shall own the earth. In the mean time, i amuse myself with games ‘n programming, and XNA is the latest coolest thing ever.
I’ve got a number of projects going at the moment, but I’m only going to show one off for now. Its called CrimsonEng and its my first attempt at a game engine, and it shall power my second attempt at a game (which i’ll blog about on a later date).
CrimsonEng is my own attempt at implementing a screen system like the one implemented in the marblets starter kit.
I have a screen manager that contains a list of screens, bundled up nicely in a drawable game component. My screens, have the normal stuff, like visible true/false and update true/false, and some basic stuff like a drawing method. it allso has a list for entitys.
Entities are everything inside the screen, from the world map to the players. at the moment, entities can just have a simple sprite, but I’m going to add an animated version, and possibly support for paperdol style characters.
Entities themselves contain a brain manager, which holds a list of small, highly flexible behaure modules. these can be anything from full blown A.I systems to being responsive to a button press, or a simple as shaking left and right (the first behavior I implemented). SCREENSHOT TIME!
  and here it is running, ok, its really basic! but tis a start. i have 2 active screens here, and each set of 3 entities running a different behavior (the pink ones vibrating and the purple ones bouncing around the screen).
 The next test app did a bit more, one screen, thousands of entities! I’ve added a short video, i thought it looked quite coolÂ
(when video capture isn’t running, it stays at 60fps, honest! and wow, that video compression is horribly at the end!)
I relay like how its looking so far, especially the brain stuff! I’m planning on implementing a scripting language, so i can describe the whole game in an script and have the engine pull all the screens and entities up, brains should allow for complex npcs and player characters to be easily put together, anyways, thats the theory.