Dear Stardockians, It seems you're concerned about the complexity of one or more of: 1) underlying data/logic model 2) effective user interface to display relevant information about the model 3) effective user interface to make relevant changes to the model 4) effective automated algorithms (or "AI") to make decisions for players based on high-level player input My guess is that you're not too worried about 1, and 2 and 3 are a lo
keithLamothe
"The transport network is abstracted." That would be good. Honestly, the resource allocation part of camp 1 doesn't sound all that complex to me, but the actual shipping of the stuff sounds like it could be a bear to manage or understand. I'd probably be in favor of an abstract "transport capacity" stat for each civ with a transport priority for each resource. The thing I'd miss then is the ability to interrupt enemy transports. Sure, you could say that
My vote is for the sophisticated model, Thank you for bringing us in on the debate; I wanted to ask for more details but figured you didn't want the hassle of unreasonable user feedback. I underestimated Stardock ;) You are right that the interface would have to be very good. My ideas may be way off, but here they are in case they help: Have map mode for "Resource allocation" where the user picks one resource ("X") and the cities are marked: <br /
Let me provoke some thoughts here. A civ/gal-civ/mom/moo-like turn-based strategy game has the following options for "story": 1) backstory in the manual. Impact on game = none. 2) procedurally generated story a la Dwarf Fortress. Impact on game = subtle. 3) player-event-based text (tech researched, building built, civ destroyed, etc) which is just static except for "insert-city-name-here" stuff. Impact on game = none. 4) scripted event
Bot vs. Bot is a must. Brad, I know you got to watch the AI play itself in GalCiv, and we won't let you keep that fun to yourself this time around ;)
Brad, Thanks for the update, it really helps to know what's going on even if it isn't completely positive. Personally, I didn't purchase Demigod because it's just not my genre (the demo may change my mind), but I am very impressed by what I've seen. Particularly I'm impressed by your commitment to put all reasonable (and perhaps unreasonable) effort into making that project a success. As a publisher, you've put more blood, sweat, and tears into resolving the
BoogieBac and folks, Thanks very much for keeping us up to date. I hope your post-Demigod recovery goes well and you have a chance to relax and recharge. While I look forward eagerly to the Elemental beta (even a completely non-fun engine beta), it's much more important that the team be happy (and healthy). Very good news about the tools; the necessary data-driven programming will take longer and be less flexible in some respects, but this game has enormous m
Brad, Thanks again for feeding us voracious info-mongers. All this sounds really good. Couple comments on quests: 1) Very important to allow heroes to quest as well as the main avatar; perhaps have "big" quests that require the avatar. 2) Also important is to allow for quest "strings", where successful (or unsuccessful!) completion of one quest is required for another to begin. One example: Quest where a big nasty dragon
Brad, An initial "Cloth-only" beta sounds good, particularly for keeping testers focused. I'm reminded of one project at work where a requirements-elicitation meeting was derailed because the client kept talking about what text she wanted to see on "the sidebar" in our prototype interface. Never mind what data types and processes the system needed, "the sidebar" became the priority for an amusing amount of time. Anyway, my wife and I are quite eager to assist in an
[quote]so I guess I'll have a group of bears pull it all the way up[/quote] Should be quite effective, actually. Q: Where does a 500 pound grizzly bear sleep? A: Wherever he wants. Q: Where do you sleep? A: Wherever the 500 pound grizzly bear tells you to. Establishing communications between the bear and the forum's SQL database poses some difficulty, but I'm sure BSQL will be along shortly. &
Brad, Thanks much for continuing to feed us info :) You asked for comments, so: 1) It'd be great if the list unit "slots" were moddable so if we wanted to add 10 more slots for left wrist armor, right pinky finger armor, back-of-the-right-shin armor, etc we could. [b]Question[/b]: you mention "you just get a person", is that the only base unit type that allows design? You've told us about dragons and stuff and I imagine those aren't just "a person"
Ah, I've been waiting for the armor thread :) On the "invincible-elite" issue, it's both yes and no: N) Assuming it's just a crack veteran soldier in high-quality full-coverage plate armor, he's probably very difficult to damage for that scrub grunt. But assuming there are enough grunts that don't panic, they could accept high losses in exchange for simply surrounding the elite, tackling him to the ground, and hacking at the now-mostly-stationary hunk of metal that
Surrendering and non-conquest Victory Conditions were optional in GC2, so good chances there.
I really like the idea of the massive-world-spanning-game-of-tower-defense, and I hope that at least the moddability will extend to that. Opposing players to provide the normal kind of challenge, plus wave after wave of increasingly strong NPCs (I would probably not go with the diminishing power option, personally, but it sounds worth having), and see how long you can survive. In many games (4X particularly) I find myself by mid-game or late-game with such a massively effective
With the caravan system as described for internal movement of goods I don't think they could avoid using the same system for moving goods for moving goods to another player for 2 reasons: 1) if the transfer were instantaneous, where would the resources go? Their capital city? To their channeler? (this would be ok as a use of magic, but only if the goods were with your channeler before transfer). That wouldn't work very well if the other guy has more than one
Every hundred turns or so, play a round of musical chairs... ;)
PBEM games would probably require auto-resolve (or auto-resolve w/recording-of-battle-to-playback ala Dom3) combat. The issue there is that unless they also implemented something like Dom3's "set up your army's positioning and tactical policies before battle", the auto-resolve could be less than satisfying. Still, even with no-control auto-resolve, it would be nice to be able to play giganto-normus maps with 50+ players, and that doesn't happen without some sort o
Given that: - units will be designed from a list of components - each component requires x units of some resource - those resources ust be produced (generally from raw materials, it would seem) - components become available through researching the prereq tech - each faction has a different tech tree There will be some diversity of economic systems anyway. Some factions will have techs that give iron-heavy components, some wi
[quote]I apologize to the devs if I've tried to bring up a dead horse for more beatings. I have an impression that lots of the Stardock site functionality talk goes on via Wincustomize, but I never go there. Spartan's project just got me thinking...[/quote] Ah, I didn't mean that the devs had been over it with the user base, I meant that the web-db guys had probably been over it a few times with their bosses. I do that kind of web-db thing for a living and it's a constant of life that y
I can hear SD's web-db programmers already... "What?! You want member records to have multiple images instead of just one? We've been over this!"
Hey, I like hitpoints ;) But I see your point, no pun intended. And Tamren, I'll be happy to resolve some stuff into psuedocode, I'll just need you to look over it and make sure I didn't get it wrong.
As a programmer I would start the game with negative sanity to begin with, so I'm obviously not in favor ;P
Hmm, so an army stack wouldn't so much be a collection of units as a supply of men (with varying degrees of training) combined with a supply of equipment? There would be a "default" config if necessary in order to display the stack as something other than a mass of men, but the army could morph into anything within the capacity of their equipment and training before battle? Does sound interesting, but I'm still not convinced the AI could manage it as good as even
While it's taking such a beating I'd like to say that I'm firmly in favor of a sharp good/evil distinction. Not that any mortal race/faction should be extremely good or extremely evil (if it's a race of demons or demonically polluted humans like the fallen are kinda like, then extremely evil fits), but there should be an obvious standard by which each is measured. Without such a standard the words "good" and "evil" become largely meaningless.
Having a unit be able to change equipment after construction (whether in the city, in the field, before battle, during battle, whatever) would be really useful and have tremendous tactical advantages... but the complexity of implementation would be significant and I think more suited towards something like the Total War series that is more about intense tactical combat. For starters you'd need: 1) the game to be able to tell: can this unit change to use that equ