EGGS - yet another programming project

[Ed Kolis]

Those of you who have been on #SpaceEmpires IRC might have heard of this, but I've been working on another programming project lately... I call it "EGGS", or "Engine for Generic Games of Strategy"...

Well, I've finally got enough implemented that I think I have something worth showing, so here it is:

http://kolis.dyndns.org/eggs

There's not really much in terms of an actual strategy game engine, seeing as I haven't implemented "coordinate systems" or "players"

But I do have a way to represent "abilities" of "entities" in a way that is much more flexible from a programmer's perspective than SE5's ability system!

Take a look, download the source code (C# 3.0), heck, give the test GUI a whirl and see if you can find any bugs (Yes, I know the "add component" and "add content" buttons don't work, as well as all the "remove" buttons - I just got tired of working on it for the night You can still add abilities and set archetypes, though - remember, abilities are inherited by an entity from its archetype; it's basically a generalization of a ship inheriting abilities from its design, or a design inheriting abilities from its hull!)

[Ed Kolis]

So I wake up at 3 in the morning and start having coherent thoughts about encryption... whodathunkit?

Basically I was thinking that if I wanted to design an open-source game based on this engine, I'd have to have a "trusted host" for the game... that is, given a set of players playing the game, they'd need to find someone trustworthy (either among themselves or a neutral third party) to process turns.

That's because it's impossible (AFAIK) to have a program X run by players H and P create data (think ".gam file" but it only contains data on things that a specific player can see) on H's side (the host) which is readable by P (the player) but not by H, if H has access to the source code of the program. (No matter how much encryption I use in writing X, H could step through the code with a debugger, after all!)

I was also thinking of distributed computing as a way to alleviate this problem - basically, "if you can't prevent the host from knowing what players are up to, maybe you can remove the host and let players know only a minimal set of information that they're 'not supposed to', and obfuscate it along the way"! But that would require some really careful coding, if it's even possible at all - obviously I'd need some way of preventing client-side hacks (crc checks on the binaries? might work for .NET, which I'm using, since you don't have to worry about different binaries for different platforms ) - but still, even with that in place, I'd need a way to divvy up the work of processing a turn, and given that any entity in the game can potentially affect ANY other entity, depending on the inheritance rules assigned to the entity's abilities (think of some of SE5's more exotic ability scopes, such as "System Range - Enemies"), I'd need to be REALLY careful that I get all the cases handled that actually need to be handled...

...hmm, that does make me think, is this whole "any entity can affect any other entity" a bad idea in the first place? I'm using LINQ and I'm not sure how that's optimized, but if I were using conventional programming techniques, I'd basically have to loop through all entities, then loop through all entities again within that loop to see if any abilities are inherited, making the ability inheritance process at the least O(N^2)...

Then again, maybe Aaron had to do basically the same thing for SE5, given all the different ability scopes the game has - sure, he doesn't have to worry about items in planet X's cargo inheriting abilities from components of ship Y, because the game is not set up to allow that, but that just means he has a number of smaller sets to test, each of which is O(N^2)...

Just some random theoretical thoughts

[narf poit chez BOOM]

...Inheritance and Interfaces are your friend.

[Ed Kolis]

If you're getting at what I think you're getting at (namely that using class/interface inheritance via C# code rather than ability inheritance via my library would be more efficent), I don't disagree, but that rather defeats the purpose of the library, since if I hardcoded more relationships, that would make the library less flexible.

I have hardcoded a few relationships, of course - with nothing hardcoded, there would be no code at all and it would be completely useless! For instance, inherent abilities are ALWAYS inherited from an entity's archetype, up the hierarchy of archetypes until a circular relationship is found or there are no more archetypes. Of course, if you don't want that to happen, you just don't set an archetype.

I guess what I'm basically doing is implementing a sort of pseudo-object-oriented framework in an object-oriented language. It seems redundant at first glance, but I'm not just designing for the end user (i.e. a programmer using my library), I'm designing for the end user's end user (i.e. someone with programing knowledge who wants to script/modify something written with my library).

Keep in mind also that the whole ability thing isn't everything - since this is for strategy games in particular, I also plan to have coordinate systems such as hexes and Cartesian planes, and a knowledge system whereby a user of the library can create "reports" on entities, which basically say what the location of an entity was at a point in time and what its abilities were.

All that a player will know about, incidentally, is the reports that he or she has received - only the game host will have the actual entities, so as to prevent cheating and reduce bandwidth usage! Actually, I suppose when I implement the player class, to avoid wasting bandwidth retransmitting old reports, I can just have the reports cached locally on the player's machine... that was one of the flaws of the "Cosmic Crises" game I was working on at one point (not to mention of SE5 though only with log messages and combat replays ) - old reports were retransmitted every turn, bloating the turn files! But then that might not be so great as you'd have to keep all your old turn files around to actually access the reports... hmmm...

Of course, if you're not writing a strategy game, you can ignore the reports, and if you're not even writing any sort of simulation of a physical space, you can leave out the locations, etc.

Writing a utility library is really a balance between 3 things: the ease of writing the library (e.g. how long does it take to write?), the comprehensiveness of the library (e.g. does it do feature X out of the box?), and the flexibility of the library (e.g. is it even possible to do feature X and still use the library?). Increase one and you must decrease one or both of the others

[narf poit chez BOOM]

Why not add inheritance and interfaces to your library code?

One way (Without looking at your code) may be to have a list of type Entity - Then, simply store any base entities in there.

[Ed Kolis]

I already have inheritance, in a fashion...

Any entity can have either zero or one archetype entity, which is akin to a class having a base class, if you want the first entity to represent a class. (If the first entity represents an instance of a class, then you could say that the archetype is the class of the object - the analogy is not perfect )

Now as for interfaces, all an interface is, is just a set of requirements, a "contract" if you will, that some object must follow in order to be considered an "instance" of the interface. I'm not quite sure how that would map over though... would it be as simple as saying that all Space Ships must have a Mass ability, regardless of value? Or would you want data validation ("all Space Ships must have a mass greater than 0 tons")? Or something different? Do you think that would be useful? I suppose that might be akin to the "requirements" in SE5, so it could be useful in that regard...

Or are you saying I should allow an entity to have multiple archetypes, e.g. an Organic Frigate could inherit abilities from both Space Ship and Living Creature? That might be useful, I suppose... doesn't seem like a particularly high priority though, given that I'm not sure at the moment how useful it would be in comparison to the ease or difficulty of implementing it properly... I'll have to think on it

[narf poit chez BOOM]

Well, it would save you from having to do lots of iterations.

[Ed Kolis]

The thing is, while I want an entity to inherit all the inherent abilities from its archetype, other types of inheritance are different; they're based on arbitrary rules. For instance, a "storage capacity" ability might need be inherited from components (adding cargo bays to a design adds capacity) but not from contents (putting a ship into cargo of a starbase does not increase the starbase's cargo capacity). Or a "warp damper" ability might have a range of N parsecs and only affect enemy ships, where N and the definition of "enemy" are determined by custom logic (say, the damper ability value has a Range property which determines N and a FindEnemies function which queries the owner, location, and "game object type" ability of entities - hmm, I need to add an Owner property to the entities once I implement the Player class! )

Hmm, though I suppose I need some way of "cloning" an entity, and maybe a even a distinction between "real" entites and abstract archetypes, seeing as I don't have a way for an entity to inherit components from its archetype, which is clearly needed for a "unit design" system! *sigh* Instead of having a separate class for archetypes, though, I think maybe I'll just have an IsAbstract flag on the entity class, and that can be set and checked as necessary, so that for instance you don't have the archetypal "Phased Polaron Beam" being treated as an actual Phased Polaron Beam which just happens to not be installed anywhere... or maybe it's only semantics whether the PPB archetype is an actual PPB or not, as long as it inherits and passes on the correct abilities But I'm pretty sure I need a way to automagically "clone" an entity, otherwise it will be tedious to, for instance, build a ship, as the user of my library would have to do stuff that I should be doing - "ok, we have this Design entity, now we need to copy that and all its components and abilities and stuff to a Ship entity... oops, we have to go and do that recursively for every component on the design..." - I should handle that myself

edit: ooh, problem - with the warp damper, what if you put that ability on a *ship*? Then while it will be inherited by nearby enemies, it will also be kept by the entity itself! I guess abilities need some way of knowing where they "came from" and a way of displaying differently based on which entity they originated with! (This would also solve another problem, namely that of unwanted recursive inheritance - while you want a mass ability to be inherited recursively, you do NOT want a warp damper ability to be inherited recursively, as it would act as a "chain lightning" effect or something akin to the Molecular Disruptor from "Ender's Game", continually extending its reach until there are no more entities within range of any entity in the "inheritance net", not to mention jumping BACK to the entity which it originated with, causing an infinite loop! While this is cool for weapons - weapons do damage so barring an emissive armor type of effect, the damage will eventually destroy enough entities that there are none left in range - it is not something you want to happen without any sort of dissipative effect such as damage to entities!) In any event, then you could have an component entity with a "does X effect to entities within Y range", and a rule that lets the entity's ability inherit to the entity it's a component of before becoming a "foreign" ability - but then after that, it becomes a "this entity is affected by X effect!zomgzomgoneoneone" ability.

*sigh* more coding for me But at least this irons out some issues ahead of time