Well, as far as anything specific to Sentinels of the Multiverse itself, I’ve only coded two cards (one of which doesn’t exactly fit the current API). Right now I’ve probably implemented most of the model, but none of the engine. I know one tough hurdle I’m going to hit is the fact most (all?) enumerators already defined in the .NET framework are either wrappers around other enumerators, or they throw an exception when the underlying collection is modified while being enumerated. I’ll likely have to implement my own wrapper enumerator which sets itself back to where it left off when the wrapped enumerator throws its exception. Either that or reimplement a trigger’s collection of responses using the observer pattern while not relying on any enumerators, but the former sounds much simpler.
If that’s what you people believe when you see a computer working, then yes, I’m using magic, hehehehe.
Once I get the engine up to a decent point, I wouldn’t mind releasing it open source. Of course, card packs would be a completely different story, as it would contain various IP (copyrights and trademarks) of Greater Than Games, and could get me in trouble.
In thinking how I’d code the game, it seemed like a queue of actions to take would work well, where the result of an action could be more actions inserted into the queue at the head. I imagine the queue starting with a single task which is something like ‘Do a Round’. That task would then spawn a Villain Turn, each Hero Turn, and an environment Turn, all to be put in the queue, followed by another ‘Do a Round’ task. Beyond the queue, the model would need to have heroes, villains, environment and their associated draw pile, trash pile, in-play set, and hand. The piles, set, and hands would then have cards associated with them. Each card would then have actions they could spawn and effect filters they could set. Some actions, such as doing damage, would be implemented by looking through a set of source filters (like Absolute Zero changing cold damage he does to +1), general filters (like Legacy’s Galvanize setting all damage done by heroes to +1), and target filters (like Warlord Voss having all damage decreased by 1 or 2 for each minion). Other actions would primarily change the status of cards – this card is no longer in the hand, it is in the in-play set.
I share this both because I felt like writing down what’s in my head and to ask The JayMann if this is like what he envisions.
Half of what you have written is what I’ve implemented. However, instead of something generic like “filters” or whatnot, I’m using the Observable/Observer pattern (Reactive Framework). Basically, the opposite of an enumerator (a push based enumerator of sorts). Basically, anything that needs to respond to any event registers it’s response (observer) with a trigger (observable), and I’ve designed lasting cards to have a play time, and responses have a reference to a card, and if the card is lasting, it uses it’s play time (otherwise uses the current time or a custom defined time) such that all responses can then be sorted by earliest so that earlier responses are triggered first. Also, any response can cancel the trigger, prevent further responses from responding to the trigger. Many triggers I’m implementing in pairs, such that one trigger occurs before the action takes place (allowing the action to be cancelled before it’s performed) and one that occurs after the action (so it can respond to the fact the action actually took place). Basically, the only thing I haven’t implemented yet is the code that processes each round (engine), and that’s because I’ll need a good amount of the model defined and set in stone so that engine is strait forward, and so that a necessary change in model doesn’t adversely effect the engine.
Right now, WPF, as I’m experienced in using ViewModels in WPF. ASP.NET MVC should work well with ViewModels as well, and Silverlight/WP7 is just a different version of WPF. Other views shouldn’t be too difficult (for someone with experience that is) like MonoTouch, Monodroid, GTK#, etc.
[font=courier] class DrawnToTheFlame : LastingCard {
protected override bool PlayLasting() {
return true;
}
public override bool CanPlay {
get { return true; }
}
public override CardType Type {
get { return CardType.Hero; }
}
private string[] keywords = { "Ongoing" };
public override IEnumerable Keywords {
get { return keywords; }
}
public override string GameText {
get { return string.Empty; }
}
Power power = new Power() {
GameText = "Ra deals each non-hero target 1 fire damage for each villain ongoing card in play.",
Play = () => {
var damageCount = Game.Villain.CardsInPlay.Where(c => c.Keywords.Contains("Ongoing")).Count();
foreach (var target in Game.CardsInPlay.OfType().Where(t => t.CardType != CardType.Hero)) this.DamageTarget(target, damageCount, DamageType.Fire);
},
};
public override IEnumerable Powers {
get { return new Power[] { power }; }
}
}[/font]
At a stuck point, more or less, so decided to draw a random card and implement it. (Note: Card does not compile, as there currently is no Game.CardsInPlay list. I’m still not sure if I should make a bunch of game level lists, or if I should just create a game level player list and compose the more specific lists as needed (e.g. Game.Players.SelectMany(p => p.CardsInPlay)).)
I also have yet to implement services (request dialogs, etc)…
I was thinking that the lists should be specific to individual players, such that a game would consist of one (or more!) villains, one (or more!) environments, and three to five (or less or more!) heroes, and then within each villain, environment, and hero you’d have separate lists for draw pile, trash, hand, and in-play.
I mostly think of it that way because, well, that’s how I think of the game, but if you have game-level lists, then you have to tag each individual card with who owns it and what state (draw pile, trash, hand, in-play) anyway.
If I were to have game level lists, they would just be enumerable wrappers over the individual lists. The internal debate is whether to create a game level wrapper for each possible list, or just create a player wrapper and compose the lists as needed. (I.e. do I create public static Pile CardsInPlay { get { return players.SelectMany(p=>p.CardsInPlay);}} or do I just use Game.Players.SelectMany(p=> p.CardsInPlay) each time I need to get all cards in play?)
Ah. Very interesting. I can see arguments on both sides in terms of understandability. I’d probably implement the wrappers after about the 2nd or third time I wanted all of the cards in play.
It’s just fun to hear knowledgeable people talk about what they know.