Persistent objects

Started by
19 comments, last by WitchLord 15 years, 2 months ago
Ya this is a really great design you have here, I'm definitely going to adopt it.

Man I can't begin to think about how inheritance will complicate things. Single inheritance is all your shooting for I hope ;)

This weak link pattern would actually go a long way in alleviating some of the problem's we've had with our engine at work. Volatile game objects are registered in several different systems, makes for messy clean up when objects are deleted. This could really make the process a whole lot safer.
==============================
A Developers Blog | Dark Rock Studios - My Site
Advertisement
I won't implement multiple inheritance in AngelScript. It wouldn't bring enough benefits to merit the extra complexity. Most uses for multiple inheritances can be solved through use of interfaces anyway.

I'm glad you like the design. Of course, it's only one way of solving things, and may not be the best for every type of game/application.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Quote:
I won't implement multiple inheritance in AngelScript. It wouldn't bring enough benefits to merit the extra complexity. Most uses for multiple inheritances can be solved through use of interfaces anyway.

I imagine the simplicity of a single inheritance implementation would be much speeder than one for multiple inheritance. Can classes in AS currently implement more than 1 interface?


Quote:
I'm glad you like the design. Of course, it's only one way of solving things, and may not be the best for every type of game/application.

Ya, i think it's adaptable to at least one case in particular in our current design and could help out quite a bit.
==============================
A Developers Blog | Dark Rock Studios - My Site
Classes can implement any number of interfaces.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I had a similar problem. But i solved it differently and it seems to work really good. What i did is at load time. I load every single scripts in the game then i parse out all the global non constant variables then cache them for each script loaded. Now when an object get loaded. All it does is reference that cache list depending on the script that is bind to it, and actually initialize all the scripts variable which are cache onto itself for reference. Now let's say i have three objects which are using a script call "token.script", Now before executing that script since the global are shared because i have only one instance of that script loaded and yet three objects are referencing it, I load the reference variables into the global variables of the script then execute the script for that object. Once the script finish executing, i update the variable on the current object again with the latest values from the script. And i do the same for everything else. That way i only have one script in memory which can be shared between any amount of objects. The cool thing with this system is that it also allows for one object that uses the same script to modify it's own script values without affecting the current object which is using the same script.
While you've solved the memory overhead of duplicating modules, you instead add a performance overhead by having to update the global variables for each script that is called.

You may not have a problem with performance in your application, but I feel using the script classes is a more elegant solution. Besides, using script classes you can use the global variables to share the data between classes of the same type (which may of interest in some application, e.g. group behaviours)


AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Interesting solution BornToCode, this is what I was looking for when I started this thread. But after figuring out the other method using Script Classes, I think they fit my needs better.

I'm still working on how to separate the client / server script logic into different modules so I can apply config groups properly.

I think until 'ol WitchLord gives us inheritance, I will just #include the common script class into the client class, and the client class will store a reference to the "base" common object.

Best I can do at the moment with out any real preprocessor either.

Still I have a bunch of other things to keep me busy for a few weeks while I think on this.
==============================
A Developers Blog | Dark Rock Studios - My Site
I like to return to previous theme...

CGameObjectLink is interesting idea, but I have always guaranted, that CgameObject is created and destroyed from C++. I thing in this case I don't need weak link, I am right?

I just need to send only "pointer" at CGameObject to script without increasing / decreasing refCount and said to garbage collector to ignore them.

Can I achieve this? Is there any way to add reference to CGameObject but without worry about destroying them from C++ -> garbage collector want to destroy them but memory of this @reference is irelevant because of CgameObject was deleted from C++?

And I have other question:

In your example you use:

class CPlayer : IEntityController
{
CPlayer(CGameObject @entity)
{
this.entity = entity;
}
}



but when I try this, comiler said that I haven't copy constructor for CGameObject. But I don't need to copy CGameObject. I want to use already created CGameObject. I miss something?

Yes, even without the link object you can delete the CGameObject from C++. However, unless you can guarantee that all references to the CGameObject has already been removed at the time of deletion, this is not a very good idea, since that leads to dangling pointers (which if accessed can cause any number of unwanted side effects that may be hard to track down).

Also, the link object is not just for the scripting engine. The link object can be advantageous within the actual game engine as well. For example when connecting 2 or more game objects in groups, this would best be done using the link object.

I made a mistake in the script example. It should have been a reference assignment instead of a value assignment, i.e.:

CPlayer(CGameObject @entity){  @this.entity = @entity;}



AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

WitchLord: You are right. Weak link is good idea and I have implemented it now.

But I thing that there is second little mistake in your example.
I thinkk that in destructor of CGameObject must be link->Release();

Not:
~CGameObject() { if( link ) link->object = 0; }

But:
~CGameObject()
{
if(link)
{
link->object = 0;
link-Release();
}

In other way there still refCount = 1 from constructor of CGameObjectLink:

CGameObjectLink(CGameObject *o) {refCount = 1; object = o;}

Is it true?

This topic is closed to new replies.

Advertisement