Component & Property/Attribute design

[Guest Red Ocktober]

i'll really be interested to see a medium to large game you've made using this as a basis for the logic...

 

seriously... i would be...

 

just because i have no use for it, doesn't mean anything to anyone but me...

 

good luck... lemme know when ya have something...

 

 

--Mike

[Rick]

It might be a fun project to have some community members create components. Since the idea of this design is separation it should be possible and pretty easy to do this without people having to know much, if anything, about the other components. Plus most components shouldn't be that hard or long to write since they should be smaller.

 

I'll put the component class in a library and write some basic components and see if anyone else wants to give it a go.

[Guest Red Ocktober]

ya see.. this is exactly what i was referring to above... you're proving what i just said... it's a fun excercise for those who have time to play with it...

 

something to learn from... to discuss the merits of... and that's cool and all...

 

but... as far as developers who want to get something done... this is a waste of time...

 

--Mike

[Rick]

Actually I was more thinking a library of components could be written which make it easier to make a game by plugging in components that people have created. Like someone could create a first person movement/camera component and someone else could make a third person etc. Then people could plug in what one they wish to use for their player game object. People could create weapon components that we could plug into game objects etc. I know, it sounds like a fairly land with rainbows and such, but oh well.

[Guest Red Ocktober]

then by all means, do it!

 

like i said, i'd be interested in seeing something like this actually working...

 

 

--Mike

[Pixel Perfect]

I already have thousands of lines of code in my project now but I'm not finding it too difficult to manage, but then I'm used to dealing with large code bases as our main product at work has over a million lines of code. However, I do find the component methodologies being discussed here of interest but don't currently have the time to look into it and experiment. Maybe once I've achieved what I set out to and have some more time on my hands I'll take a look at this in more detail. At that point I'll also have a much better idea of what’s needed to make a complete game which might give me a better insight for a redesign using other methods.

 

Good luck to all of you looking to implement this type of design though, I'll watch with interest!

[Davaris]

while this is an interesting topic... i find it has little practical value... sorta like theoretical metaphysics...

 

 

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy

 

EXPECT RESISTANCE

 

The first problem I encountered was in trying to explain the system to other programmers. If you are not particularly familiar with the idea of object composition and aggregation, then it can strike you as pointless, needlessly complex, and unnecessary extra work. Programmers who have worked with the traditional system of object hierarchies for many years become very used to working that way. They even become very good at working that way, and manage to work around the problems as they arise.

 

Selling the idea to management is also a difficult. You need to be able to explain in plain words exactly how this is going to help get the game done faster. Something along the lines of:

 

"Whenever we add new stuff to the game now, it takes a long time to do, and there are lots of bugs. If we do this new component object thing, it will let us add new stuff a lot quicker, and have fewer bugs."

 

My approach was to introduce it in a stealth manner. I first discussed the idea with a couple of programmers individually, and eventually convinced them it was a good idea. I then implemented the basic framework for generic components, and implemented one small aspect of game object functionality as a component.

 

I then presented this to the rest of the programmers. There was some confusion and resistance, but since it was implemented and working there was not much argument.

 

[Davaris]

 

Good luck to all of you looking to implement this type of design though, I'll watch with interest!

 

 

Thanks!

 

I'll be using the techniques from the last two articles I linked on Object-Oriented Game Design, to refactor my huge inheritance based RPG engine, to the action-entity-data model, which really is a data driven Object Component model.

 

My first goal will be to get it outputting its commands and results entirely in text and then I'll use the other techniques discussed in the articles to rapidly swap in Leadwerks, a 2D engine or almost any other 3D engine, if I wanted to do so.

 

I also expect this structure to make it trivial, to add networking.

 

So yeah, this will probably take a while...

 

I'll post again on this subject, when I get the text version working.

[Guest Red Ocktober]

EXPECT RESISTANCE

 

The first problem I encountered was in trying to explain the system to other programmers.

 

hey D... dya think all those other programmers he was trying to explain it to... the ones he mentioned above... dya ya think they had a good reason to be a lil dubious about what was being proposed to em...

 

also... do ya think this is the first time i've heard of this stuff...

 

hey, i got no resistance to it... it'll work... go ahead and implement it... i'd love to see you do it...

 

i'll be waiting to hear of your successful implementation...

 

in the meantime... i offer you this to ponder...

 

 

Rube Goldberg Inventions

 

A Rube Goldberg Invention is an incredibly complex machine (built from simple machines) that is used to complete a simple task. Rube Goldberg was an engineer and an artist. He found that most people find the hardest way to do the simplest things. His machines like the one below to make fun of this!

 

 

 

 

--Mike

[Davaris]

hey D... dya think all those other programmers he was trying to explain it to...

 

--Mike

 

Since you're trolling now. Here's a link just for you:

 

The Flat Earth Society

http://www.alaska.net/~clund/e_djublonskopf/Flatearthsociety.htm

 

 

[Guest Red Ocktober]

cute pic of a Davaris Doll...

 

me trolling... noooo, ya got me all wrong... i'm on your side...

i'm wishin' ya all the best... givin ya all the luv...

 

what sa matter... did that rube goldberg guy touch a sore nerve or something...

 

hey... do it... implement your component based thingeee... show me (and rube) that the world is not flat...

 

hahahahahaaaaa...

 

 

--Mike

[Davaris]

cute pic of a Davaris Doll...

 

me trolling... noooo, ya got me all wrong... i'm on your side...

 

 

 

--Mike

 

[Guest Red Ocktober]

carefull... don't get any of that in your eyes...

 

you really should be starting on your component based game system instead of wasting time searching for cute lil images...

 

you've got a awful lot of work ahead of you if you intend to implement even half of what you propose...

 

ya see... you don't know how to take a lil humourous ribbing... it should motivate you to show me how wrong me (and the rest of the world) can be... it should motivate you to succeeding in what you say you can accomplish...

 

instead, it has motivated you to call me names... and to post cute lil images...

 

i dunno... but it doesn't seem as if you're gonna suceed by doing those things...

 

like i said... i'm on your side in this...

 

now, ya better get crackin' young man... the world waitin' this...

 

 

 

 

--Mike

[ZioRed]

Well I have to say that Rick's excitation let me wait a moment to think about this design and he has inspired me to go deeply in this argument, so now after some huge (not too much indeed) design and code and revamp, I have begun my own new C# gamelib based on components idea (which I could share if interested) with which now I'm able to execute the following code:

 

public static void InitializeGame()
{
_game = new Game();
_game.Initialize(Configuration);

zrGamelib.Components.GUI.GUI gui = _game.CreateComponent<zrGamelib.Components.GUI.GUI>();
gui.DefaultFont = Font.Load("abstract::Arial12Shadow").Pointer;

// Create a new image button
zrGamelib.Components.GUI.Button btNewGame = new zrGamelib.Components.GUI.Button(gui);
btNewGame.Position = new Vector2(20, 50);
btNewGame.Size = new Vector2(200, 30);
btNewGame.BorderSize = 0;
btNewGame.Image = Texture.Load("abstract::ui_new1.dds").Pointer;
btNewGame.ImageFocus = btNewGame.ImageClicked = Texture.Load("abstract::ui_new2.dds").Pointer;

// Create a new text button
zrGamelib.Components.GUI.Button btMultiplayer = new zrGamelib.Components.GUI.Button(gui);
btMultiplayer.Position = new Vector2(20, 100);
btMultiplayer.Size = new Vector2(200, 30);
btMultiplayer.Text = "Multiplayer";
btNewGame.BorderSize = 2;

// Create a new component GameLiving for our player
zrGamelib.Components.GameObjects.GameLiving player = new zrGamelib.Components.GameObjects.GameLiving();
player.Name = "player1";
player.Initialize();
player.Health = 100;
player.MaxHealth = 100;

// Create a bar to see our health points
HealthBar hpBar = new HealthBar(gui);
hpBar.Owner = player;
hpBar.ShowValue = true;
hpBar.ShowPercentage = true;
hpBar.Size = new Vector2(150, 60);
hpBar.Position = new Vector2(400, 0);
hpBar.Font = Font.Load("incbin::Arial9").Pointer;

_game.AddComponent(player);
}

/// <summary>
/// Avvia la sessione di gioco
/// </summary>
public static void StartGame(FormGames splashScreen = null)
{
if (splashScreen != null)
	splashScreen.Close();

GameLiving player = (GameLiving)_game.GetComponent("player1");
while (!Keyboard.KeyHit(Key.Escape) && !Window.HasRequestedClose())
{
	if (player != null)
	{
		if (Keyboard.KeyHit(Key.NumpadSubstract))
		{
			player.TakeDamage(5);
		}
		else if (Keyboard.KeyHit(Key.NumpadAdd))
		{
			player.RecoverHealth(5);
		}
	}

	_game.Update();
	_game.Render();

	Graphics.Flip();
}
// Free the engine resources
Engine.Terminate();
}

 

This is a sample classes:

 

class HealthBar : zrGamelib.Components.GUI.ValueBar
{
   public HealthBar(zrGamelib.Components.GUI.GUI gui)
       : base(gui)
   {
   }

   public override void Update()
   {
       base.Update();
       Value = (int)Owner.GetPropertyValue(zrGamelib.Components.GameObjects.GameLiving.HEALTH);
       MaxValue = (int)Owner.GetPropertyValue(zrGamelib.Components.GameObjects.GameLiving.MAXHEALTH);
   }
}

public class GameLiving : GameObject3D, IGameObjectLiving
{
   #region Properties definition

   public const string HEALTH = "Health";
   public const string MAXHEALTH = "MaxHealth";

   #endregion

   #region Properties declaration

   public int Health
   {
       get { return (int)GetProperty(HEALTH).Value; }
       set { GetProperty(HEALTH).Value = value; }
   }

   public int MaxHealth
   {
       get { return (int)GetProperty(MAXHEALTH).Value; }
       set { GetProperty(MAXHEALTH).Value = value; }
   }

   public bool IsAlive
   {
       get { return (Health > 0); }
   }

   #endregion

   public GameLiving(IGameComponent owner = null)
       : base(owner)
   {
       AddProperty(new GameComponentProperty(this, HEALTH, 0));
       AddProperty(new GameComponentProperty(this, MAXHEALTH, 0));
   }

   public void Move(Vector3 position, bool global = false)
   {
   }

   public void TakeDamage(int damage, IGameObjectLiving enemy = null)
   {
       Health -= Math.Min(damage, Health);
   }

   public void RecoverHealth(int points, IGameObjectLiving healer = null)
   {
       Health += Math.Min(points, MaxHealth - Health);
   }
}

[Guest Red Ocktober]

hey zio... quick question... (and don't take this as anything but a serious question)...

 

what does the app as you have it coded so far do...

 

--Mike

[ZioRed]

A very quick answer that comes to mind is to reproduce the game assets of Unity (and may be a visual editor to manage them if I'll have time), an abstract entity which could have many components for rendering (you could have an entity with 2 meshes, set their offset and then move them simultaneously just moving only one object).

 

However I'm writing a very generic gamelib so that it could be used as base for any kind of game or application and extensible by writing new components as plugins as Rick says.

[Guest Red Ocktober]

that's not what i meant... i think i see what you're doing overall... (generally looks good)...

 

what i'm asking though, is what specifically does the code fragment and the resultant program do...

 

--Mike

[ZioRed]

It displays three buttons (I'm working on GUI as an extended game component) and an health bar (which extends a generic ValueBar GUI component) which belongs to a living (which is still a game component) and show its life points in value and % and is updated and rendered by the GUI component.

 

Each component (and relative children) registered in the Game object is updated and rendered at each _game.Update() and _game.Render().

[Pixel Perfect]

The crowd is assembled around the ring and the atmosphere thick as the two contestants prepare to battle it out. In the left corner we have Red October with his Game Objects and in the right corner we have Rick and Co with their Game Components. The crowd goes silent and you can cut the tension with a knife as the ref gestures the two into the centre of the ring. The bell rings, the crowd roars and the battle commences .....

 

Will be interesting to see who goes the distance here

[ZioRed]

Yeah this is what a forum should serve I'll see Mike's GameObjects too when he will release, as the great Peppino Di Capri said: "exams never end"

 

At least I'm doing my gamelib for C# only, Rick for C++, Mike ?bmax?C++?

[Guest Red Ocktober]

ok... that's what i was asking...

 

ok... looking at that, and the component aspects of the way you've designed it... compare your component design to a simple oop class based design...

 

 

oop based design...

 

class: living, has a health property...

class: healthbar, does what your health bar does...

 

done...

 

 

can you see the point i was (humorously) trying to make to davaris, about it being a bit overblown... not to say that you should abandon your way... not in the least...

 

 

i'm listening... what advantages does component methodology have over simple oop class methodology...

 

 

 

 

edit

 

LOL at Pixel

 

yeah... i'm here pounding away at the keys... trying to get each individual GameObject instance to become aware of itself... that is, to be able to react to user input when individually selected (picked)...

 

each one is just a simple class (type in bmax)...

 

i get this done, then next getting objects to be able to be aware of the surroundings and other objects...

 

so far my whole thing is shorter than the lil demo app code zio put up... but i'm of an open mind...

 

not easily convinced... but maintaining an open mind... i fooled around with a component methodology a long ways back... my experiences with are why i look at it as i do now...

 

 

 

--Mike

[ZioRed]

One benefit is that you can easily modify the data handled by your component at runtime, in my examples I created properties because I like the classic way of class definitions but you really don't need to create properties, you can just access to them with the standard GetProperty().

 

At this moment and with the small games I have in mind for the near future, I don't see any great benefits from component based compared to the inheritance method except for the gamelib.

[Rick]

I'm actually looking at implementing mine in C# now. It would work great for an editor. Each component is a dll. Drop the dll in a folder the editor reads. It dynamically loads the dll without even closing the editor. Now the component is available to use to build game objects. That'll be the general idea anyway. Doing that with C++ would be ugly.

 

 

At this moment and with the small games I have in mind for the near future, I don't see any great benefits from component based compared to the inheritance method except for the gamelib.

 

If you build you components generic enough you will have a nice library to pick from for other games. If you build an editor of sorts like I was describing above making different kinds of games quickly would be possible. The component method is all about easier maintenance and flexibility. That's really all it is. People who have used the OOP way have found when plans change and/or projects get massive things get out of control. You either hack changes in or end up reorging things all the time. Most of the time a nice hierarchy design just ends up getting ugly. Objects end up with a ton of stuff they don't require leading to bugs and such. That's why this method was created. To avoid that. That's not me talking, that's me explaining what the articles are saying. I'll let you know if that's true as soon as I get my system up and running.

[ZioRed]

I'm actually looking at implementing mine in C# now. It would work great for an editor. Each component is a dll. Drop the dll in a folder the editor reads. It dynamically loads the dll without even closing the editor. Now the component is available to use to build game objects. That'll be the general idea anyway. Doing that with C++ would be ugly.

Welcome again on our platform

[Guest Red Ocktober]

At this moment and with the small games I have in mind for the near future, I don't see any great benefits from component based compared to the inheritance method except for the gamelib.

at least you realize this... there's hope for you (as opposed to the other two just kidding... just kidding )...

 

i'll be watching your progress... good luck...

 

 

my goals are a lot simpler... world domination and indoctrination of the universe of game programmers to the GameObjects philosophy... that's all...

 

seriously... i'm trying to make a simple way for anyone to take a model... drop it into the sandbox (editor)... associate it with a Gameobject class (set the classname key)... and include the class source into ProcessScene.bmx...

 

it's based on simple class metaphor... everything inherits from TGameObject... super simple...

 

 

thx for taking the time to explain your approach... i still think it's flaky (just kidding... just kidding )

 

--Mike