Baaack

Yay, exams are over.

Anyways, a small update. Mainly been doing behind the scenes stuff, but I feel that I can now motor along with the juice of the program. I built a little program to "make" me build the networking section of Game.DLL (Now 1.0.0.9!) its getting there, and it's good enough for me to start doing some stuff with it.

Anyways, particles is coming along nicely. I'll have a playable game (helpfully) by the end of the weeked. Just got to finish building the vector art manager... ^,^

Networking : Part 3

So... after much deliberation about what I had inplace... I scrapped it. Mainly because the code that I had was rather clumsy and did not do anything in reality. So here's what happens now.

1. A seperate thread will place the messages into a queue that is generic for the Client and the Server.

2. A seperate function can then access this and read what it needs, this is where the objects are spit up into their areas.

• Any packet that has SYSTEM as the target location are not passes to listeners that are listenig for packets. They are passed to internal functions that can use them (So things like Connects, Disconnects and Server Commands are an example of this)
• Classes can place listeners that will listen for packets that have a specific target location (Except for SYSTEM) (So a map manager could register for anything with MAP in it)

With this improved system, messages can be directed to where they are needed, and messages can be sent to certain areas of the system to allow for a simpler management of network sessions. By using identifiers that tell the program where to target the messages that it sends, it allows classes that need the data to get it, and to prevent other classes that could be trying to "listen in" from accessing the data. (Once inside the program)

Also, Game.DLL provides methods for decoding and encoding the data in a certain way, so that clients can read the data on the other side. Other types of data that the client sends need to have their methods for encoding and decoding the data placed into them as so that they can be sent across the network.

So yeah, nothing much. Mainly rewriting the code, and placing this system in place.

Particle Emitters : Part 3 & Networking : Part 2

Okay, part 3...

Particle emitters are coming along nicely, most of the key features behind it are working. And nearly completed, however. There are still a few little hurdles to overcome.

Networking Particles
While in most cases this is never really needed, when you are building a game that uses particles as a resource you kinda do need to keep them rather accurate across the network. So this needs to be implemented. But I can have thousands of particles spread out across the map, so this gets a bit interesting. My inital solution is to do something like this:

public struct PixelNet {

public bool multi = true;
public System.Collections.Generic.Dictionary location;

}

Or something along these lines, this way, I do not have to send thousands of packets to update all of the particle positions, plus it allows me to send the data in one shot. The clients would have a special class of the pixel emitter going, as so they do not do any of the calculations, all they do is draw that they are told to do... (But that could get interesting).

Which brings me to my next topic: Networking.

Networking in the game is getting there (As I said before), and it is nearly at the point where I can say that it is usable. But I am still trying to determine how to keep the framerates in sync. As with each frame I want to make sure that they are updating at the right speed. So I think I will do something like this.

Each 1000 milliseconds is split into 4 frames (With the server being the clock setter in a way). And the clients, upon connecting, start to manage their framerate. The network manager will most likely create an event inside the timer manager that will go off every 250 milliseconds, to make it update the frame. But there is always a bit of lag, no matter what you do, so I still need to ensure that there is a little bit of leeway when it come to this. So: I will most likely make it so that it will still accept the frame if it is 2-3 frames later than what the current frame is. But it needs to be able to keep up with it. (It will most likely be running on a seperate thread, feeding the data to an accessable storage list that can be accessed by whatever needs it.)

I would also need to take into account for the delay that there is when we are encoding and decoding the data. While it should be fast, there is always the chance that there could be alot of data in the queue to process, so I still need to watch out for this. But it should not be much of a problem. I hope!

Anyways, networking and particles are my biggy for this week. Along with finishing off my Vector Art manager.

Tool's, Tool's and more Tool's!

So, I've been busily working away at my solutions for the SwinGame 08 comp, and I may have been sidetracked just a little bit with my Particles game, but it helps me in a way. Since I am writing Particles, I am building my API (Which provides abstraction to SwinGame and a few other modules) so that when I come to write the meat of the code for my solutions, I will actually be ready for that.

Since I am working in 2 different groups who have 2 completely different game types, I need to ensure that they way that I code my API is working, and that I can resuse the code between both of them. This also means that I can build tools that work for both of them, like my Resource Pack Manager.

But I'm getting to the point where there are more tools than there are for samples, but that's good in a way, as this shows that my code is somewhat progressing since I first started this little project. (And when I say little, think big)

Right now, I am working on a vector art creator, as I want to be able to create vector art without having to code it. So this is my latest little project. :P

Core Management : Part 1

Okay, while this is not a real issue with the games, they do provide critical services to the classes and functions that are used for the game.

So let's talk about each of them and what they do.

There is an accessibility manager, which has the job of managing accessability for the games, while the game does not have direct access to this (Since the resource manager acts on their behalf), it allows me to make text and fonts bigger, and provide some more special features. (More about them later!)

The cameraManager, as the name suggests allows me to manage cameras that can be all over the place, and I can jump around from one camera to another. So its good.

The console is a way in which I can 'tinker' with the game world, I will most likely program the console to work in 2 states, debugging and release modes. Where release does not have diretct access to objects in the game world. But yeah, a console!

There are 2 main event callback systems in place at the moment, and they are the event and guiEvent managers. Basically they provide methods for me to preform callback events to objects that have requested them each frame cycle, allowing me to dynamically add objects without having to add them manually (Which would be very hard!)

But thats all for now, there are alot more... but they are coming!

Objects : Part 1

Its probabaly about time that I started to talk about this concept with my games, as they are basically the backbone of the entire game. (With some exception)

Basically, all game objects are derived from the Object class (Not the System.Object, it's one that I built) But it provides root functionality, from things like net events all the way up to rotation management. Its it. Since all objects rely on it, I can easily program maps and networks to work based on this model, and over the network a decoder and encoder are used to get the message into the correct form on both sides.

I'll put this into an example for you.

I have an object class called Player, which as the name suggests, provides a means for having a character on the game world. It manages events like collisions with the player and allows the player/ai/netplayer to manage it through its input devices. It disables keys that it needs to prevent other objects from using those keys, and it uses the base object system to manage the animations and rotations. The player is holding onto 2 weapons which provide functionality to the shooting side of the game, these bind to another set of keys and disable those keys so that only they are using them. Weapons have ammo which doesn't really do much, but its there. Technically it does not rely on the object class, but it is in the heirachy of things.
So heres the chain:

• Object
• Player
• Weapon
• Ammo

It gets quite complex after a while, but thats how it will work in the end.

Particle Emitters : Part 1 & 2

Okay, so I have done a fair bit of work on this, so I will say that this is 2 posts worth of data for this topic, so here it goes!

Particle Emitters : Part 1
This area is a critical area of my programming, as this allows me to create "special effects" like things like explosions, fog, auroras and stuff like that. So I started with creating just the particle emitter that spits out particles in random directions, which was fine. It doesn't really require much code for it to work, so it was easy. But then I needed to move onto things that allowed me to effect the path of the particles and change their course (Things like wind for example). So this required a fair bit more coding over top of what already existed to allow me to effect them. (I already had the framework in place, I just needed to add the code that did that for me) So after about 2 hours of tinkering on this I eventually got something that worked (The solution was to rewrite the algorithm that calculated the effectors realtive power with respect to the particles position) (#1). But the end result was worth it, and while it is still rather strict with its control over the particles, it does actually work (Which is the main thing)

Particle Emitters : Part 2
So now we move into the area of asthetics of the particles, while they were just fine as dots for testing (And still are fine as that), it is probabaly a good idea that I add the option that allows pixel particles to have a "glowing" effect, so that they look nicer, and people with faster PC's can get this little asthetical feature out of it. There are a few problems that arise from this, and they require solutions that provide reasonable speed and accuracy. So lets start by talking about them.

1. Drawing a glow effect around an existing particle directly to the screen does not work, as the particle is in float form, and when the particle moves onto a .34334 number for example, the surrounding pixels are not drawn correctly and a gap is visible. So my initial solution to this problem is to make it so that the entire pixels data is built into a table that can be accessed by other particles to fetch a pixel that has already had its color built and stored, so it will make drawing faster (Provided that the image has already been built)

But yeah, that's all for now. Next, I'll talk about making particles the same across networks and finish this section off.
#1 - SwinGame Topic Regarding Emitters (Link)

Armageddon - The Basics

Okay, so I have started to work on my races concepts and pictures. While they will end up at the main site eventually, I thought that I might give a quick rundown of what I expect to get from this.

Firstly, the game will most likely be designed so that your team has a leader and the leader is responsible for managing your team. While you do not have to stick with this role, it allows teams to be better coordinated against the enemy, and to build plans for attacking.

The map itself can provide challenges for the players and certain types of items and veichles will work in certain environments. Ie. A gas leak prevents you from using things like flamethrowers and plasma guns, so you are required to use other weapons if you want to stay alive. But if the enemy is surrounded by the gas, it provides you with the upper hand (So to speak).

There will be veichles, and depending on the map they can play an important role in the round you are playing. The size of each veichle varies and their abilities varies as well. Each veichle has its abilities and downfalls, but they provide a challenge to teams. Not sure about flying veichles though, as the game is a top down shooter, but could make maps where veichles can fly over certain terrain types...

Multiplayer will be fully functional, with the game supporting LAN games fully. Internet games may be a possibility, but it would most likely be through the form of Direct IP addresses...

The game will also sport a "Quick-Play" button, to allow you to jump into the game straight away.

The campaign will provide challenges for the player as well, with the campaign having (In my case) a "action - reaction" type scenario. Providing actions from their actions.

And, of course, there will be a tutorial.

But yeah, theres a bit about the game.

Networking : Part 1

So to start me multiplayer side of the game, I have gone with using an API (Of Sorts) and creating a network game, which has introduced a few interesting design considerations. But the most important of them all was this:

How do I get the data back into the appropriate form on the other side?

So, I've been thinking about this for a while, and the solution to this problem I think is to write functions that "decode" the data on behalf of the reciever and give the client the data needed. While this works in concept, using this in practise provides interesting things...

But since it requires a decode method, it requires an encoding method to put the data in the correct form for decoding. No biggy. But the program also sends data relating to things such as the packet type and its intended destionation... but simple when compared to the rest of it.

Transferring files with this API is realtively simple, so sending clients data that they don't have is easy enough!

Coming Up Next: Armageddon - Basics...

Shadows : Part 1

As I said in a previous post, drawing the shadows was going to be a real challenge, as there are so many angles and variables that come into it now. But never fear! The solution is always possible! It just involves alot of thinking and time.

Firstly, we know 2 points. The light source and the point at which there is a change in the terrain. So we start with that. These are in Vector3 format (x, y, z) so we don't lose the height of them. But this could be at any old angle, and we still need to get the tile that the light collides with, so there are a few considerations there as well. But basically it all boils down to some simple math.

Basically, all this comes down to a simple triangle and calculating the gradient. But that is just for getting the height. We also have to remember the terrain height as well, and we need to fetch this as we go. (To make the program a bit quicker in doing this, I do rather quick checks first until the height is below the terrain at that tile (Using the aggregate height of that tile).

After this, we finetune that number and get the exact (Or close, depending on the level of detail) position of where it is zero. And then return that Vector3 to the game to build the shadow.

It's all really fussy stuff doing this :)