Code behind SE: Harder or easier to manage?

[Expected Value]

This is a question I am posing to the programmers mostly. From a programming perspective, is it getting harder to add new cards to Shadow Era without causing problems, staying the same, or is it getting easier? Is the code getting progressively neater, progressively harder to manage, or staying the same?

I notice a lot of players spend their time in the forum dreaming up new cards with radically new abilities that would require additional programming but I personally think one of the most important things for Shadow Era right now is to keep all of the programming stable and streamlined. As the number of cards with unique programming attached to them increases won't the number of card interactions that could cause bugs and instability increase exponentially? Card designers should make sure to get the maximum use out of every ability, i.e. it is silly for the programmers to have to spend all the time making haste work and then only get one ally out of that feature (Kristoff).

[Raphael Majere]

Very interesting topic.

I think SE is on the right track, allowing the code/data to run well over 3G, web,etc. I play AC:R CCG (ipad only) and I cannot play it via 3G. Only on Wi-Fi. That's just not optimal: losing out on a lot of players who wants to play on the go. I play SE on the go all the time.

[iClipse]

Well, things have to be coded correctly, which they aren't always. Sometimes that is because you don't know in advance that what you coded is correct. Or sometimes it's a design issue. For example Victor deals damage when he reduces allies to 1 health. But he shouldn't, he should put allies in a certain state, because otherwise it won't work with cards that reduce damage.

So you have to design in advance if he should deal damage or if he should just put something in a certain state.

[Expected Value]

@Raphael: Yes, it does seem like SE is on track for the time being anyhow.

@iClipse: I agree Victor should bring an allies health to 1 as opposed to dealing as much damage required to do that. I also think that once programmers figure out how to do that it should be recycled for future uses. Your point also speaks to how the rules and terms of SE must be consistent. Imagine what a nightmare trying to officiate this game in paper version would be without some reforms to make the rules consistent in this game.

[iClipse]

True. That's why the design team is working hard on it, so that all rules are clear.

[Seth]

True. That's why the design team is working hard on it, so that all rules are clear.

Part of this problem, though, is also that the game is being coded with a sort of "as long as we get the right result" sort of mentality. The design team may say "Reduce an ally's health to 1," but the coders find it easier to deal that amount of damage rather than code a whole new mechanic to actually set health to a certain value. This kind of thing will create systemic problems down the road (and has already started to) and should be worked on in addition to fixing the rules.

[Lime Street Hero]

The design team may say "Reduce an ally's health to 1," but the coders find it easier to deal that amount of damage rather than code a whole new mechanic to actually set health to a certain value. This kind of thing will create systemic problems down the road (and has already started to) and should be worked on in addition to fixing the rules.

This scenario together with poor spec/tech documentation is what slowly kills a good product and makes it too expensive to manage. This kind of knowledge dies with the circulation of programmers on a project (and that will always happen) and get lost in the spaghetti.

If this is a problem at this stage of production, it could cost dearly. Better rid these things early. I'd say that this needs to be taken care of BEFORE any new sets, beyond the 200 cards already planned for, are implemented.

Joel Spolsky has some great insight on this for those who wants to indulge:
http://www.joelonsoftware.com/articl...000000036.html

[Gondorian]

I don't think it's fair to speculate on the quality of the coding in SE, unless you've seen the code.

The issue with Victor was because it's unclear whether lowing health is the same as damaging. If that was clearly specified, then the code would be easy to write. So it's more about tightening up the semantics (as opposed to code quality), which is what we are doing in the Design Team right now.

[CodeDomination]

The code isn't the worst, especially for an indie title, but it has some gaping flaws that I'm sure kyle is aware of.

[Dai]

I'll not say that shadow era is indie counting on what number of people is inside wulven studios