Component oriented programming and entity systems have piqued my interest lately. There are quite a few articles online that I think you should read to understand more. One good source is here: http://stackoverflow.com/questions/1901251/component-based-game-engine-design
One implementation of entity system involves separating data from functions. So, components will only contain fields, and subsystems will contain the logic that uses the data from the components. For example, you may have a spatial component (x y position) that zombie entities contain, then you will need a Movement subsystem that updates the zombie's spatial coordinates every game tick.
Subsystems may also manipulate data from multiple components. This is needed for interactions between components. E.g. Change the graphics component's data based on your spatial component's data, so that your renderer knows where to draw your zombie.
I've just provided simple examples based on my understanding, but if you are interested I encourage you to read more about this topic starting with the link above.
To be honest, it already sounds like you are biting off more than you can chew!
I remember when I first started wanting to make a game, oh the ideas and features I had planned, but once getting into actually making the game, I realized why the no one had made such a game before... it was too hard/not practical... etc.
I think you should reevaluate just exactly what you want, whether it be just making a game this one time and never to do something like it again:
- find a coder and pitch your game idea to him/her (read game design book beforehand maybe..)
- use game maker or something similar (as for your wish for making it seem like you didn't use game maker... once you start, you may realize just what qualities in a game will reveal its game-maker-esque nature and find a way to conceal it maybe or perhaps you will realize that it's not important at all...)
Use making a game as a learning experience for game development in the future:
- learn coding (it will a long time between starting to learn coding and making a game with lots of frustration in between- not a decision to make lightly)
Both quality posts. Thanks for the insight. Prior to this post, I have never heard of strings modelling stories, but it does seem like a neat idea. I think that as far as story managing goes, DAGS and strings+beads seem to be equally powerful... although the addition of beads allows for some modular components to be included.
I wonder if we can generalize story, arrays, meters and state machines (or a combination of) so that we can apply the same rules every time for aiding the creation of any story driven game... Thanks again.