• Programs, Items, etc are just Entities, which store a list of Components. All Entities have a grid position (x, y), a unique ID, a name and a description.
• Programs would have a ProgramComponent and a VisibleComponent, along with either an AIComponent or a PlayerComponent.
• Items would have an ItemComponent, a VisibleComponent, etc.

shared_ptr<ProgramPrototype> pProtoHack(new ProgramPrototype(PROG_HACK, 2, 4, 5));        //"Hack" is just a type/class of program
shared_ptr<ProgramPrototype> pProtoSentinel(new ProgramPrototype(PROG_SENTINEL, 2, 4, 256));    //Same with sentinels
    
pProtoHack->addCommand(Command("Slice", "Deletes 2 sectors from target"))->setName("Hack")->setDescription("Basic attack program");
    
pProtoSentinel->addCommand(Command("Cut", "Deletes 2 sectors from target"))->setName("Sentinel")->setDescription("Corporate data defender");
    
shared_ptr<EntityProgram> pHack1((EntityProgram*) (pProtoHack->createInstance(1)));    //Number passed to createInstance() is just an ID for the entity
shared_ptr<EntityProgram> pSent1((EntityProgram*) (pProtoSentinel->createInstance(2)));


pHack1->getImageIndex();    //Because image data is shared, the method retrieves the value from its object's prototype reference

 

Also, apologies in advance for any confusion... I can't really explain the mechanics of this game without going into a lot of detail

Probably the biggest problem I see among hobbyist game developers these days is that they try and use component-based entities, thinking it'll make their game better, and then they get bogged down in the many different ways in which they could choose to implement such a thing, and then get slowed down by the complexity of writing such generic code everywhere. Personally I think they do more harm than good now. I believe that if you're in a position where you have to ask about your component-based system, you're not ready to use one. But anyway, rant aside.

Your situation looks fine. I'd probably implement it a similar way. BUT - you mention 'prototype-inspired' as if it's an alternative to 'component-based' - but it is not. These are unrelated topics.

• Your component-based system could be prototype-based as well. In Unity3D it's common to create objects from 'prefabs' which are pre-configured GameObjects with their own collection of components. The prefab is the prototype in this case. But everything is still 100% component-based.
• The prototype pattern imparts shared information to instances via copying. You can also do it via reference, where an object maintains a reference to a more abstract object. eg. You might have an entity called Smaug which holds a reference to a 'Dragon' object. When querying an entity, if a value is not found locally, it can inspect the 'parent' reference to get it. So you basically end up implementing data-inheritance within your program. But this too can still be component-based - an instance of a component might have some 'instance' variables that it stores locally and some 'class' variables which only exist in the parent.
• One way of representing the 'external object holding shared state' idea is via the Flyweight pattern. This has a spectacularly poor description in the Design Patterns book, focusing on memory use with a particularly invalid example, but it does actually handle data-based inheritance. The downside is that it's not always clear that there is a division between concrete and less-concrete data there, but the concept is the same.

When you think about it, these systems are all equivalent in some sense - generate objects where some of the information is shared with others and some of the information is not. Even a class in C++ and the compilation and execution process uses the flyweight concept, except the shared data is the memory that makes up the executable methods. It's all just data in the end, and there are many ways you can choose to arrange it.

I didn't mean to suggest that the two concepts are mutually exclusive - having a prototype-based component system did cross my mind - but I wasn't sure if it would be worth it. I suppose it all depends on how specific my intentions are. Funny how you talk about Flyweight, I was just reading that as thinking about all this sharing of data reminded me of it! Thanks for those ideas though, I think it may be the fact that doing something slightly different that isn't spelled out for me just feels weird which keeps me from seriously considering things like that.

One reason I like components is that they lend naturally to data-driven design, rather than having everything hard-coded in. But again I'm wondering if it's really necessary for a project like this. It's not like I'm straight out of the C++ tutorials and have just learned about a fancy new way of doing things either - I've read quite a bit on the subject, but unfortunately that seems to be all I ever do :S

Anyway, I'll see how it goes. Thanks again for the advice.

How many different types of entities do you need for your game? Is there a possibility to reuse the entity system? Do you want to use such an entity system because you simply want to create one (and feel its power ;) )?

You can still define properties of your entities in data files and you can also call some script functions without a complicated system. What you cant do is: defining new types of entities in script/data. That would be cool but do you really need that?

If by types of entities you mean the equivalent of classes eg in which they have the same properties but with different values of these properties, then not a lot. Although it would be nice to be able to add weird and wonderful new entity types I only really need the two mentioned (Program and Item) for now. I don't want to use an entity system for its own sake; I'm considering using it because it's the Next Big Thing and I can see why it is superior, in many respects, to huge class hierarchies. However the class hierarchy isn't very deep here; as mentioned, different entities are not defined as much by a different class as they are by the data values they have.

And yes, components would let me define new entities outside of the program itself which would be nice. I suppose it would benefit me in the long run when compile times grow extremely long.

Going ahead with my inheritance heavy approach still feels wrong to me, but components also seem overkill ._.

But what I want to avoid this time round is doing a U-turn and starting from scratch... again. I seem to keep doing this but it obviously doesn't help, which means I have to choose a way of doing this and stick with it.