namespace GM
{
namespace Collision
{
VOID CheckMovingSphere(..);
VOID GetHeight(..);
VOID GetGrounding(..);
};
namespace Intersect
{
namespace Editor
{
Object* Triggers(..);
Object* Features(..);
Object* Objects(..);
Object* All(..);
};
Object* Triggers(..);
Object* Features(..);
Object* Objects(..);
Object* All(..);
};
namespace Magnets
{
VOID Attach(..);
VOID Detach(..);
BOOL IsGridValid();
const Vector& GetGridSpan();
const Vector& GetGridOffset();
};
};
Excessive namespaces
Author
Is it acceptable to create a large hierarchy of global-like functions using namespaces?
I'm trying to find a way to limit my game world objects (characters, items, etc) to just an interface, and no class or structure types. I have 'map' and 'world' objects, and I don't want characters and items to have any access to them. But these functions require them and other higher-level objects to operate.
In other words, I'm going to have a lot of functions. Would this be the way to go, or is there a better way?
Looking for opinions. Thanks.
That's actually quite common, believe it or not, but I'm not sure it's the way most people would like to see it implemented. In the end, it's all about what makes you the most comfortable.
EDIT: Although, the way you are approaching it is a bit questionable. All of your functions are returning Object*, which sounds a bit like passing around void pointers. Is there a reason that you want to avoid using classes?
EDIT: Although, the way you are approaching it is a bit questionable. All of your functions are returning Object*, which sounds a bit like passing around void pointers. Is there a reason that you want to avoid using classes?
Author
Quote:Original post by smitty1276
That's actually quite common, believe it or not, but I'm not sure it's the way most people would like to see it implemented.
What would most people like to see?
Quote:In the end, it's all about what makes you the most comfortable.
I thought it might help to create an interface specifically made for character-level objects, grouped by subject rather than by object types. It completely removes the visibility of both low level functionality and higher level objects. But I've never attempted it before, so I'm not confident that I'll like where it leads.
list = GM::Scans::LineofSight( map_index, layer_index );
instead of
list = g_World->GetMap( map_index )->GetLayer( layer_index )->ScanLineOfSight()
Quote:EDIT: Although, the way you are approaching it is a bit questionable.
Approaching what? The namespace interface?
Quote:All of your functions are returning Object*, which sounds a bit like passing around void pointers.
I wrote the entire example up just for this post, and then neglected to change Object* after I copied and pasted the intersect function eight times. I'm just trying to give a simple example of what the interface would look like.
Quote:Is there a reason that you want to avoid using classes?
I wouldn't be avoiding classes. This would just be an interface for game objects at the medium level, where most of the functionality of the game exists. The classes would still exist, but objects that use the interface wouldn't need to worry about them.
Anyway, I'm still not positive I want to go this way. I'm just not seeing many alternatives. My medium level objects (like characters) need completely different types of interaction with most classes than other objects do. They don't need to tell the map to load from file or to update resources. If I limit the interaction my objects have with other code, I can simplify most of the game's operation (which happens to be medium level objects) quite a lot.
Maybe another type of design change will help?
Thanks again.
Actually, I think this is how C# programmers organize their code. Instead of including headers and linking with libraries, they just say:
using namespace System.Drawing.Foo.Bar;
So namespaces can get complicated. The whole point of them is so programmers can organize themselves. However, namespaces are used to help name resolution. If there are no naming conflicts with different parts of a subsystem, you might want to consider putting them in the same namespace.
using namespace System.Drawing.Foo.Bar;
So namespaces can get complicated. The whole point of them is so programmers can organize themselves. However, namespaces are used to help name resolution. If there are no naming conflicts with different parts of a subsystem, you might want to consider putting them in the same namespace.
Author
Quote:Original post by ouraqt
Actually, I think this is how C# programmers organize their code. Instead of including headers and linking with libraries, they just say:
using namespace System.Drawing.Foo.Bar;
So namespaces can get complicated. The whole point of them is so programmers can organize themselves. However, namespaces are used to help name resolution. If there are no naming conflicts with different parts of a subsystem, you might want to consider putting them in the same namespace.
I wouldn't use the "using namespace" feature much. I don't have any sort of typing allergies. I like to use long and descriptive names, and using that command would nearly make that pointless.
As for placing more objects under the same namespace, why would that be better? If all of these namespaces are under one single namespace, there's not really any cost, is there?
It would just come down to choosing between
Intersect::Editor::Triggers()
and
IntersectEditorTriggers()
The namespace style is extremely compatible with intellisense. It makes it very friendly to find something specific in a large number of functions. It's just a very desirable side effect, but I don't see any bad side effects to counter it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
