* Xconq UI thoughts @ 2003-11-20 2:15 Stan Shebs 2003-11-20 2:26 ` Brandon J. Van Every 0 siblings, 1 reply; 23+ messages in thread From: Stan Shebs @ 2003-11-20 2:15 UTC (permalink / raw) To: xconq So many ideas flying around, I can hardly keep up! But here are some thoughts based on having built a half-dozen separate UIs for Xconq over the years, and having heard the player feedback. 1. Xconq should follow the prevailing trends in game interface design, and it should be informed by the A-list games rather than the obscure ones. That means custom interface design, not cookie-cutter-GUI-builder stuff. That's the motivation for the SDL experiment; it's a cross-platform kit that has been used for some high-quality commercial games. The downside is that you have to develop more widgets and create more artwork for them. Another downside is that what is cool today will soon become dated. 2. Office apps are not fun. Multiple overlapping windows, floating palettes, etc, all get a big "yechh" from players, and very few use them. (Developers think they're cool, but do you want your audience to be game players or game developers?) 3. Players are willing to tolerate less efficient interfaces if they are entertaining to use. The standard video game preference panels are nasty modal things, but developers dress them up with animation and sound effects, and players are OK with that. 4. Players are not programmers; complicated automation features will likely not be used. Players are perfectly happy to do repetitive actions if they're being entertained while doing them. 5. Players hate to type; they would rather roll around a bunch of buttons and popups than hit a single key on the keyboard. (Programmers love keyboards, but see #4.) 6. All this applies to game design too. Only a handful of the most hardcore want to write GDL, scripts, or whatever; that's as true of Quake as it is of Xconq, Quake just has a much larger fan base from which to recruit the hardcores. Stan ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Xconq UI thoughts 2003-11-20 2:15 Xconq UI thoughts Stan Shebs @ 2003-11-20 2:26 ` Brandon J. Van Every 2003-11-20 2:57 ` Eric McDonald 2003-11-20 10:31 ` Xconq UI thoughts Andreas Bringedal 0 siblings, 2 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-20 2:26 UTC (permalink / raw) To: xconq Stan Shebs wrote: > > 1. Xconq should follow the prevailing trends in game > interface design, and it > should be informed by the A-list games rather than the > obscure ones. "Should," but, there are the dictates of budget and doability. Where's your team of artists? Your army of programmers to provide custom GUI work? Your project management infrastructure on par with something like, say, the Nebula 3D engine? http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/WebHome AAA titles are into multi-million dollar budgets now. You have to implement a UI you can afford with volunteers. If anybody knows of UI that has been achieved by volunteers that have AAA production values, great, show it to me. We'll learn from whatever they did. But I have not seen it. People generally reserve that level of polish for things they intend to make a living from. And not to state this unfairly, but there's a developer breeding mechanism at work in such things. People who really value AAA production values, and who are capable of producing them, move on and find a way to make those things in commercial products. People who don't, generally stay behind in hobbyist freeware projects like Xconq. I'd love any pointers to specific exceptions that break the general rule. But from where I sit, the people with the drive and talent to produce what you're suggesting, generally aren't available as volunteer labor. > 2. Office apps are not fun. Multiple overlapping windows, > floating palettes, > etc, all get a big "yechh" from players, and very few use > them. I agree totally. > (Developers think they're cool, Not all of 'em. This one certainly doesn't. > but do you want your audience to be game > players or game developers?) Actually, my personal agenda is what Xconq (or any suitable 4X TBS platform) can do for *Game Designers* as an experimental medium. I am not primarily concerned with trying to reach as many players as possible. I want to reach many more players than Xconq currently does, but I certainly wouldn't set myself up for AAA production values in order to reach some mega-goal. I will have long since returned to my own proprietary efforts before that happens. For me personally this is about prototyping some game design ideas. > 3. Players are willing to tolerate less efficient interfaces > if they are > entertaining to use. The standard video game preference > panels are nasty > modal things, but developers dress them up with animation and > sound effects, and players are OK with that. No, they are not all ok with that. But again, I am circulating in game designer circles such as http://groups.yahoo.com/group/gamedesign-l/ and news://comp.games.development.design My main agenda is that all the mouseclicks and sloth has to die. > 4. Players are not programmers; complicated automation features will > likely not be used. Thus, it is paramount to design simple ones. > Players are perfectly happy to do repetitive actions > if they're being entertained while doing them. And the main problem with the 4X TBS genre, present incarnation of Xconq included, is that *many* players are *not* entertained by all the mindless gobbledygook they must slog through to finish a game. As far as I'm concerned, this is strong evidence that players are *not* entertained by repetitive actions after a certain threshold. > 5. Players hate to type; they would rather roll around a > bunch of buttons > and popups than hit a single key on the keyboard. I agree. > (Programmers love keyboards, but see #4.) No, not all of them do. I hate 'em. > 6. All this applies to game design too. Only a handful of the > most hardcore > want to write GDL, scripts, or whatever; that's as true of > Quake as it is > of Xconq, Quake just has a much larger fan base from which to > recruit the hardcores. Yes, one has to be mindful of building lotsa technological infrastructure on the premise that someone wants to use it. Infrastructure should be built for people who are *actually* using it, as they actually *need* it. If you run around trying to provide general purpose capabilities, you will never produce any content and you will eventually get bored. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Xconq UI thoughts 2003-11-20 2:26 ` Brandon J. Van Every @ 2003-11-20 2:57 ` Eric McDonald 2003-11-20 9:45 ` growth agendas and OO Brandon J. Van Every 2003-11-20 10:31 ` Xconq UI thoughts Andreas Bringedal 1 sibling, 1 reply; 23+ messages in thread From: Eric McDonald @ 2003-11-20 2:57 UTC (permalink / raw) To: xconq > And not to state this unfairly, but there's a developer breeding > mechanism at work in such things. People who really value AAA > production values, and who are capable of producing them, move on and > find a way to make those things in commercial products. People who > don't, generally stay behind in hobbyist freeware projects like Xconq. > I'd love any pointers to specific exceptions that break the general > rule. But from where I sit, the people with the drive and talent to > produce what you're suggesting, generally aren't available as volunteer > labor. Of course this totally overlooks the segment of developers that have both the drive and the talent, but have made other career choices that they find more fulfilling, __who simply work on a project as a hobby in their meager free time. > > (Programmers love keyboards, but see #4.) > > No, not all of them do. I hate 'em. This explains much.... > Infrastructure should be built for people who are *actually* using it, > as they actually *need* it. Could it be?! He _finally_ gets it! Now he understands why there was no red carpet and royal fanfare waiting for him wrt the Windows build process. Amazing, he _finally_ gets it.... ^ permalink raw reply [flat|nested] 23+ messages in thread
* growth agendas and OO 2003-11-20 2:57 ` Eric McDonald @ 2003-11-20 9:45 ` Brandon J. Van Every 2003-11-20 10:49 ` Bruno Boettcher 2003-11-20 17:24 ` Eric McDonald 0 siblings, 2 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-20 9:45 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > Of course this totally overlooks the segment of developers that > have both the drive and the talent, but have made other career > choices that they find more fulfilling, __who simply work on a > project as a hobby in their meager free time. Yes, I suppose that is true. But the proof is in the pudding, right? Like I said, show me the freeware projects with the AAA production values. I've never seen one, and I suspect they're few and far between if they exist at all. It matters naught if someone actually has the talent to produce all the eye candy, if instead they apply their hobbyist talents to AI code. Priorities are priorities, time outlays are time outlays. > > Infrastructure should be built for people who are > > *actually* using it, as they actually *need* it. > > Could it be?! He _finally_ gets it! Now he understands why there > was no red carpet and royal fanfare waiting for him wrt the > Windows build process. Amazing, he _finally_ gets it.... Do you understand why Xconq won't get any bigger without certain infrastructural layouts? This is quite late in technological history to be doing C code. But... some have a growth agenda, and others don't. If you want to see a project with a real growth agenda, check out http://nebuladevice.sourceforge.net/cgi-bin/twiki/view/Nebula/WebHome That's project management for growth. Now admittedly, it's not a fair comparision. There's a company still driving a lot of Nebula's development, even though they license the engine BSD style. But the point is, you get external investments in proportion to how easy you make it for others to join your project and contribute to it. I am willing to contribute to the OO-ification of Xconq, if you want to pursue that agenda. If you think that agenda is misguided, then it's best to find out now. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: growth agendas and OO 2003-11-20 9:45 ` growth agendas and OO Brandon J. Van Every @ 2003-11-20 10:49 ` Bruno Boettcher 2003-11-20 10:59 ` Brandon J. Van Every 2003-11-20 17:24 ` Eric McDonald 1 sibling, 1 reply; 23+ messages in thread From: Bruno Boettcher @ 2003-11-20 10:49 UTC (permalink / raw) To: xconq7 On Thu, Nov 20, 2003 at 01:43:52AM -0800, Brandon J. Van Every wrote: > I am willing to contribute to the OO-ification of Xconq, if you want to > pursue that agenda. If you think that agenda is misguided, then it's > best to find out now. wasn't there allready someone slowly pushing into that direction? the first step was to get xconq compiled with g++, AFAIK we are at this step.. so maybe we need a design phase here which reorganizes the sources? as i told Eric prvately, indeed if we had a simple to understand OO model of xconq i would be willing to add a CORBA layer to it, for (remote) connections (from remote UI's over xconq-servers to distributed ai connections...) even if its in C++ :D but i fear migrating xconq to OO will be quite some work.... -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: growth agendas and OO 2003-11-20 10:49 ` Bruno Boettcher @ 2003-11-20 10:59 ` Brandon J. Van Every 2003-11-20 11:51 ` Jakob Ilves 0 siblings, 1 reply; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-20 10:59 UTC (permalink / raw) To: xconq Bruno Boettcher wrote: > > wasn't there allready someone slowly pushing into that direction? the > first step was to get xconq compiled with g++, AFAIK we are at this > step.. Apparently so. > so maybe we need a design phase here which reorganizes the sources? We do not, I repeat, *not* want to do this top-down all at one go. Rather, we need a migration path. We want an incremental, hodgepodge, piece here, piece there approach. That's what's appropriate for the volunteer labor actually available to Xconq. A hodgepodge OO approach may sound bad, but it's better than Xconq's current C code. The C code is actually not totally far off from OO, it's just too flat. Improvement is the point, not creating tons of work that has no fungible value to anyone. Also, incremental testing is the point. You cannot move a big system like Xconq over to something else all at once. Once Xconq has done "hodgepodge OO" for awhile, it may become feasible to turn it into "highly structured OO." Also, more ambitious improvements become possible. For instance, it is really not feasible or sane for most people to attempt new GUIs with the code being the way it is. Some OO paradigm simplifications are necessary first. In short, there really is nothing to argue about as to what the structure of the OO should be. Rather, pick an OO language tool, and start OOing some minor things, with the hope of that leading to major things. I'm picking Python. Others could pick C++ if they like that, or some other language if they're terribly motivated. Then it becomes a matter of who actually codes, who actually uses the language tools. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: growth agendas and OO 2003-11-20 10:59 ` Brandon J. Van Every @ 2003-11-20 11:51 ` Jakob Ilves 2003-11-20 12:05 ` Brandon J. Van Every 2003-11-20 17:57 ` Jim Kingdon 0 siblings, 2 replies; 23+ messages in thread From: Jakob Ilves @ 2003-11-20 11:51 UTC (permalink / raw) To: Brandon J. Van Every, xconq Hello planet Earth! --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > Bruno Boettcher wrote: > > > > wasn't there allready someone slowly pushing into that direction? the > > first step was to get xconq compiled with g++, AFAIK we are at this > > step.. > > Apparently so. > > > so maybe we need a design phase here which reorganizes the sources? > > We do not, I repeat, *not* want to do this top-down all at one go. > Rather, we need a migration path. We want an incremental, hodgepodge, > piece here, piece there approach. That's what's appropriate for the > volunteer labor actually available to Xconq. A hodgepodge OO approach > may sound bad, but it's better than Xconq's current C code. The C code > is actually not totally far off from OO, it's just too flat. > Improvement is the point, not creating tons of work that has no fungible > value to anyone. Also, incremental testing is the point. You cannot > move a big system like Xconq over to something else all at once. Absolutely! (Hodgepodge being offered? That sounds delicious, maybe I should consider returning to earth!) This is a very good way of developing, introducing (and needing to kill) just one bug (if any) for every step. Sure, one can do large chunks and exterminate all those bugs all at once but they can become awfully persistent if they gang up against the poor developer. They are far nicer to eliminate one at a time (trust me, I've used both approaches ;-). Given that Xconq is rather large, a good test suite would be most useful. That way the developer can reasonably quickly check if the last step in the development caused an bug or not. Multiple migration paths could be nice, that way one developer can turn one piece into OO on his/her box while othes deals with other pieces. Then both check in their pieces into the development CVS. Yes, coordination will be needed among parallell OO migraters so their changes don't happen to clash (for example, check out the entire current CVS source and do a run against test suite in order to identify any incompatible OO migration pieces checked in). Having one developer alone doing the OO work probably is a bad idea, IMHO. That person will be a bottleneck for the project and the risk is big that the person get's fed up with the task or even worse, what must not happens do indeed happen: that the developer no longer find it fun to develop Xconq. > Once Xconq has done "hodgepodge OO" for awhile, it may become feasible > to turn it into "highly structured OO." Also, more ambitious > improvements become possible. For instance, it is really not feasible > or sane for most people to attempt new GUIs with the code being the way > it is. Some OO paradigm simplifications are necessary first. > In short, there really is nothing to argue about as to what the > structure of the OO should be. Rather, pick an OO language tool, and > start OOing some minor things, with the hope of that leading to major > things. I'm picking Python. Others could pick C++ if they like that, > or some other language if they're terribly motivated. Then it becomes a > matter of who actually codes, who actually uses the language tools. Um... Java? Using the Apache Batik SVG for the graphics? With XGDL for defining games and with Javascript for snippets in the game definition code. What a fantasy! Seriously, Java have advantages but I don't see any way of incrementally migrating Xconq to Java from C. Too bad, but such a monolithic migration would likely be suicide. C++ could be a choice, or at least an intermediate step. Once the OO is there, be it "hodgepodge" or "highly structured" flavor, it would be a less painful suicide to do a migration, all at once, to say Java or some other language. For an excersice in utter programming perversion (which is fun at times ;-), we can go for Perl and Perl-tk. > Cheers, www.indiegamedesign.com > Brandon Van Every Seattle, WA > > Taking risk where others will not. /IllvilJa (still in orbit ;-) Having fun where others will not ;-) (Sorry could not resist that one). ===== (Jakob Ilves) <illvilja@yahoo.com> {http://www.geocities.com/illvilja} Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: growth agendas and OO 2003-11-20 11:51 ` Jakob Ilves @ 2003-11-20 12:05 ` Brandon J. Van Every 2003-11-20 17:57 ` Jim Kingdon 1 sibling, 0 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-20 12:05 UTC (permalink / raw) To: xconq From: Jakob Ilves [mailto:illvilja@yahoo.com] > > (Hodgepodge being offered? That sounds delicious, maybe I > should consider returning to earth!) We serve 'em fresh 'n' tasty. Of course if you've seen "Spirited Away," you know what happens when you eat too many of them! > Having one developer alone doing the OO work probably is a > bad idea, IMHO. That person will be a > bottleneck for the project and the risk is big that the > person get's fed up with the task or even > worse, what must not happens do indeed happen: that the > developer no longer find it fun to develop > Xconq. Yes, having only one guy do OO is not a realistic way for migration to proceed. The OO paradigm has to be accepted and used by a lot of people. I am hoping that by embedding Python into Xconq, and showing people how it can be used, people will become willing to use it for various tasks. Eventually people become "sold" and "hooked" on Python. > /IllvilJa (still in orbit ;-) > > Having fun where others will not ;-) (Sorry could not resist > that one). Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: growth agendas and OO 2003-11-20 11:51 ` Jakob Ilves 2003-11-20 12:05 ` Brandon J. Van Every @ 2003-11-20 17:57 ` Jim Kingdon 1 sibling, 0 replies; 23+ messages in thread From: Jim Kingdon @ 2003-11-20 17:57 UTC (permalink / raw) To: xconq7 > Given that Xconq is rather large, a good test suite would be most > useful. That way the developer can reasonably quickly check if the > last step in the development caused an bug or not. If you think of a test suite big enough to detect most bugs throughout xconq, it gets really scary. But the good news is that test suites are fairly easy to write one test at a time (starting with the code you are about to tear apart or feature you are about to add, for example). I've written a few tests, but more contributions are welcome. Here's the section I just wrote for the hacking manual. Running the tests (or at least autotests) as described here would be a good first step for someone thinking of helping out in the testing area. There are a variety of tests, some more automated than others. Running `make check' gets you all of them. Warning: some of them take a very long time to run. Generally speaking most of the tests should be interpreted to fail if xconq dumps core, and succeed in most other cases (some error messages might be considered failures). Perhaps the most interesting tests are the autotests. These are written in a unit test style, meaning that the test code links into the code under test, which is good for speed and makes it easy to test particular parts of the code rather than end-to-end behaviors. They should run fast enough to run them every time you make a change to xconq. To run just the autotests: $ cd kernel $ make skelconq $ cd ../test $ make check-auto ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: growth agendas and OO 2003-11-20 9:45 ` growth agendas and OO Brandon J. Van Every 2003-11-20 10:49 ` Bruno Boettcher @ 2003-11-20 17:24 ` Eric McDonald 2003-11-20 17:51 ` Eric McDonald ` (2 more replies) 1 sibling, 3 replies; 23+ messages in thread From: Eric McDonald @ 2003-11-20 17:24 UTC (permalink / raw) To: xconq On Thu, 20 Nov 2003, Brandon J. Van Every wrote: > Do you understand why Xconq won't get any bigger without certain > infrastructural layouts? The C infrastructure is pretty good (as Peter points out in a later message); in fact, it is good enough that Xconq has gained 2 developers in the past 5 months. Not bad.... As far as building the game goes (since that is actually the question at hand), the answer is: sure, it would be nice to have some additional infrastructure. You seem to have this "me vs. them" mentality though. When I suggested that _you_ could contribute your VS project, you became rather defensive, thinking that I somehow doubted your efforts. It would be nice if you would understand that, within the open source community, there is a kind of "altruism", that if you accomplish something positive then you share it with others. I didn't build this particular piece of infrastructure because I didn't *need* it. >But... some have a growth agenda, and others don't. I have a personal growth agenda for Xconq. It goes something like this: Pre-7.5: (1) Fix all known stability issues and crashing bugs. (2) Verify documentation correctness and add more exposition where necessary. Possibly spiff up the HTML version of the manuals. (3) Make sure that all the test cases pass muster. Possibly enhance the testing system. (Although the normal use of skelconq is to be invoked with arguments, it should probably not assume that this is the case, as you pointed out and as I also noticed some time ago.) Post-7.5/Pre-7.6: (1) Make a badass AI. (2) Do some work with the tasking/planning system (related to AI work, but some make-user-life-easier things also). (3) Possibly extend GDL. (4) Possibly extend the standing orders syntax. (5) Possibly work on SDL/? interface. > I am willing to contribute to the OO-ification of Xconq, if you want to > pursue that agenda. If you think that agenda is misguided, then it's > best to find out now. I don't think that this is necessarily misguided in the long term. But the C infrastructure works pretty darn good at present. We even have some "polymorphism" due to nifty macro magic.... Xconq currently attempts to be at a C89 compliance level to make sure that we are supporting as many platforms as possible. If you say that we should just ditch those platforms, then you are simply stating an opinion which is not even all that pragmatic. I actually did put out a feeler a while ago, to see about moving the compliance level to C99; the conclusion I reached is that the time is not right yet. Eric ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: growth agendas and OO 2003-11-20 17:24 ` Eric McDonald @ 2003-11-20 17:51 ` Eric McDonald 2003-11-21 1:59 ` altruistic VS 2003 Solution files Brandon J. Van Every 2003-11-21 2:01 ` growth agendas and OO Brandon J. Van Every 2 siblings, 0 replies; 23+ messages in thread From: Eric McDonald @ 2003-11-20 17:51 UTC (permalink / raw) To: xconq Ooops, forgot one agenda item that I've been mulling the last couple of months: On Thu, 20 Nov 2003, Eric McDonald wrote: > I have a personal growth agenda for Xconq. It goes something like > this: > Pre-7.5: > (1) Fix all known stability issues and crashing bugs. > (2) Verify documentation correctness and add more exposition > where necessary. Possibly spiff up the HTML version of the > manuals. > (3) Make sure that all the test cases pass muster. Possibly > enhance the testing system. (Although the normal use of skelconq > is to be invoked with arguments, it should probably not assume > that this is the case, as you pointed out and as I also noticed > some time ago.) > Post-7.5/Pre-7.6: > (1) Make a badass AI. > (2) Do some work with the tasking/planning system (related to > AI work, but some make-user-life-easier things also). > (3) Possibly extend GDL. > (4) Possibly extend the standing orders syntax. > (5) Possibly work on SDL/? interface. (6) Possibly modularize the combat system, and then recast models 0 and 1 in terms of the modular system by setting the appropriate combat behavior flags. Eric ^ permalink raw reply [flat|nested] 23+ messages in thread
* altruistic VS 2003 Solution files 2003-11-20 17:24 ` Eric McDonald 2003-11-20 17:51 ` Eric McDonald @ 2003-11-21 1:59 ` Brandon J. Van Every 2003-11-21 4:17 ` Eric McDonald 2003-11-21 2:01 ` growth agendas and OO Brandon J. Van Every 2 siblings, 1 reply; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-21 1:59 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > When I suggested that _you_ could > contribute your VS project, you became rather defensive, thinking > that I somehow doubted your efforts. No, I went through a triage of why you would possibly bother to phrase your question as you did. I eneumerated the possibilities: - you didn't believe I had created VS 2003 Solution files - you didn't approve of VS 2003 Solution files - you were worried that I might have done them badly All 3 ended up with the same result: why bother to ask the question as you did? The proper question would have beem more like, "Could you please .ZIP up your VS 2003 files so we can stick 'em into the source pool?" Or, "are they ready for the source pool yet?" And I answered that: no, they're only 95% complete. > It would be nice if you would > understand that, within the open source community, there is a kind > of "altruism", that if you accomplish something positive then you > share it with others. Which has nothing to do with the question you asked. I had already built the VS 2003 Solution files. My altruism is not at issue; you may want to make it an issue, but it is misguided of you to do so. It's like, you never really got the idea that amidst all the screaming and gnashing of teeth, and us getting on each other's nerves, that I was actually building things for Xconq. I think that's because you were tuning out my various status messages like "I've got the Tk client built now," "Hey! I've got the SDL client built now." Why did you think I wrote those things, to lie to you and say "4A! 4A! Read it and w33p loz3rz, I'm not giving you didly doo!" ?? Sometimes I think you are used to working with a very low class of people in hack3rz forums, because you seem to have these paranoid ideas about what my motives are, when I'm always pretty blunt and clear about my motives. Anyways, you need to accept that there's altruism, then there's difference of personal style, and finally there's unviability. I am only interested in the intersection of our common agendas. I'm not here to just give freely, I give because there are things I want to get in return. For instance, migrating a C codebase and getting lotsa happy novice Python programmers / game designers jammin' on Xconq is of direct career benefit to me. If successful, not only would I enhance my stature as an Indie Game Designer / Programmer, but I can consult that skill for big bucks. The technical term for that is a Win-Win Situation. Of course that's a best case, and I'm a gambler. If I embed Python and nobody uses it because of developer climate and people's energies, at least I will know some things about how efforts fail. Other issues you raised are sold separately. :-) Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: altruistic VS 2003 Solution files 2003-11-21 1:59 ` altruistic VS 2003 Solution files Brandon J. Van Every @ 2003-11-21 4:17 ` Eric McDonald 2003-11-21 9:02 ` So let's get right to the point Brandon J. Van Every 0 siblings, 1 reply; 23+ messages in thread From: Eric McDonald @ 2003-11-21 4:17 UTC (permalink / raw) To: xconq OK, you managed to troll me once again. On Thu, 20 Nov 2003, Brandon J. Van Every wrote: > - you didn't believe I had created VS 2003 Solution files No, I believed you. I just couldn't believe how long it took you. > - you didn't approve of VS 2003 Solution files No. If you think that I am close-minded or dogmatic in that regard, you really haven't learned anything about me. (Though that doesn't surprise me, since you don't really listen.) > - you were worried that I might have done them badly This is a possibility, one which can't be ruled out unless they see the light of day. > you did? The proper question would have beem more like, "Could you > please .ZIP up your VS 2003 files so we can stick 'em into the source > pool?" As if I would ever type that.... There is no way I would beg or prod you for something that is of uncertain quality or value. I simply suggested that you could try to contribute something to the Xconq project. You are a wee bit paranoid if you are reading anything more into what I said. > Which has nothing to do with the question you asked. I had already > built the VS 2003 Solution files. My altruism is not at issue; you may > want to make it an issue, but it is misguided of you to do so. I have no intention of making it an issue. You make it an issue almost every time you send an email to this list. Your attitude and motives speak for themselves just fine without my help. > actually building things for Xconq. I think that's because you were > tuning out my various status messages like "I've got the Tk client built Tuning out, no. ROFL, yes. There is a lesson that I learned from this though. I should keep a page of gold stars to hand out for the next time some egomaniac starts blowing such gas all over the place. "Look, mommy! Look what _I_ did today." Jeeezus. Grow up. > loz3rz, I'm not giving you didly doo!" ?? Sometimes I think you are > used to working with a very low class of people in hack3rz forums, Nope. You're about the lowest I've gone. Eric ^ permalink raw reply [flat|nested] 23+ messages in thread
* So let's get right to the point 2003-11-21 4:17 ` Eric McDonald @ 2003-11-21 9:02 ` Brandon J. Van Every 2003-11-21 23:14 ` Lincoln Peters 0 siblings, 1 reply; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-21 9:02 UTC (permalink / raw) To: xconq Eric McDonald wrote: > Brandon Van Every wrote: > > > Sometimes I think you are used to working with a very > > low class of people in hack3rz forums, > > Nope. You're about the lowest I've gone. I see, Eric. I'm not going to retract my apology to you, I've apologized for what I should have. But it's clear that you have never been interested in moving on. You basically don't accept the differences of style between us. That might change years from now, but it won't change in any timeframe that matters to present ventures. So let's get right to the point. How many things that I propose, are you going to obstruct out of your need for personal animosity? I think it's best that you make the list now. That way, we don't have to waste time with people talking about it, me implementing it, and you blocking it. State your turf, the things you certainly aren't going to give ground on. We'll make this partly a multiple choice test. 1. Python required in the kernel a) yeah, that's awesome! b) hell no. Go away. 2. Kicking 7.5 out the door so that new features can be added a) yeah, any week now! b) I want my months before you even think about touching my source pool. 3. Recruiting a horde of Windows C# .NET developers a) the more the merrier! b) get out of here you Micro$quish suckup bastard And, these are questions I expect firm answers to. The number of (a) answers determines whether Xconq is a good use of my time. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: So let's get right to the point 2003-11-21 9:02 ` So let's get right to the point Brandon J. Van Every @ 2003-11-21 23:14 ` Lincoln Peters 2003-11-22 0:06 ` Why Eric doesn't like my personal style Brandon J. Van Every 2003-11-22 0:07 ` So let's get right to the point Brandon J. Van Every 0 siblings, 2 replies; 23+ messages in thread From: Lincoln Peters @ 2003-11-21 23:14 UTC (permalink / raw) To: Xconq list On Thu, 2003-11-20 at 23:09, Brandon J. Van Every wrote: > So let's get right to the point. How many things that I propose, are > you going to obstruct out of your need for personal animosity? I think > it's best that you make the list now. That way, we don't have to waste > time with people talking about it, me implementing it, and you blocking > it. State your turf, the things you certainly aren't going to give > ground on. I had hoped that this arguing would be over by now, but you both still seem to get on each other's nerves. I'm not sure why. I'm not going to try to take sides, but I will try to answer some of these questions (although none of them make good multiple-choice questions). > > We'll make this partly a multiple choice test. > > 1. Python required in the kernel > a) yeah, that's awesome! > b) hell no. Go away. I don't think Python is required, but Python would make it easier to do things that are difficult or impossible right now (which have already been discussed over the last few days). And it might improve Xconq in ways that we can't predict now. The catch is that none of us want to add Python support to Xconq until other bugs are fixed (see #2). No matter how many cool things a game is supposed to be able to do, nobody will play it if it doesn't work. > > 2. Kicking 7.5 out the door so that new features can be added > a) yeah, any week now! > b) I want my months before you even think about touching my source pool. I think that it's quite clear that we all want to fix as many bugs as possible before releasing 7.5. Although it seems that we're getting close. Remember, open-source projects (usually) do not have marketing people screaming at them. Xconq 7.5 will be released when it is ready, and not a moment before. A lot of software companies (especially Microsoft) could have saved themselves a lot of trouble by working this way. I don't think that anyone is worried about you "touching our source pool" beyond that you might introduce something that has unexpected results. That's why anyone with CVS access tests a piece of code as thoroughly as possible before committing it. > > 3. Recruiting a horde of Windows C# .NET developers > a) the more the merrier! > b) get out of here you Micro$quish suckup bastard "Micro$quish?" That's a new one. I originally brought up Mono because I thought that it would make it easier to add components to Xconq in languages other than C. Although I suppose that it would make it possible to add lots of new features to the Windows version, I would be reluctant to add anything that would not work on all Xconq platforms. For example, I would be willing to add code to Xconq that would let it talk to MS Excel, but only if it was possible to do the same thing with at least one other spreadsheet application (e.g. Gnumeric) on other operating systems (e.g. Linux). My interest in Mono has nothing to do with its cross-platform nature, although it is a feature that could save us a lot of effort in the long run. If Microsoft pulled the plug on Ximian, Mono would not lose any of the features I originally pointed out. And I would expect it to be possible to maintain a separate implementations for Mono and .NET in a similar way to how we maintain separate interfaces now. Getting back to your question, if a horde of Windows C# .NET developers could make a contribution to Xconq without causing problems in the UNIX and MacOS versions of Xconq, I'd be inclined to welcome them. > > And, these are questions I expect firm answers to. The number of (a) > answers determines whether Xconq is a good use of my time. Are the answers I provided firm enough? By the way, I think that it would be worth looking your VS 2003 Solution files. I'll assume that they work reasonably well, as I doubt you would have said anything if they didn't work. Although that doesn't mean that we shouldn't test them before committing them to CVS. Is there anyone else on this list who has VS 2003 and would be willing to take a look at the files? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Why Eric doesn't like my personal style 2003-11-21 23:14 ` Lincoln Peters @ 2003-11-22 0:06 ` Brandon J. Van Every 2003-11-23 11:13 ` Mark A. Flacy 2003-11-22 0:07 ` So let's get right to the point Brandon J. Van Every 1 sibling, 1 reply; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-22 0:06 UTC (permalink / raw) To: xconq Lincoln Peters wrote: > > I had hoped that this arguing would be over by now, but you both still > seem to get on each other's nerves. I'm not sure why. It is a simple matter. Eric does not like my personal style, he thinks I'm an arrogant SOB. He is somewhat correct, and I'm not going to change how I do business for him. His options are to get over it and accept that people with different personal styles can accomplish different things for an organization, or we will go our separate ways. I don't really have a problem with Eric, which is what's interesting about this situation. Eric has a problem with me. If you want a deeper psycho-managerial explanation, you will find it reading http://www.teams.org.uk/shaper.htm . I am a Shaper. Not sure what Eric is, although I have some guesses and he's definitely not a Shaper. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Why Eric doesn't like my personal style 2003-11-22 0:06 ` Why Eric doesn't like my personal style Brandon J. Van Every @ 2003-11-23 11:13 ` Mark A. Flacy 2003-11-23 14:22 ` Brandon J. Van Every 0 siblings, 1 reply; 23+ messages in thread From: Mark A. Flacy @ 2003-11-23 11:13 UTC (permalink / raw) To: xconq >>>>> "Brandon" == Brandon J Van Every <vanevery@indiegamedesign.com> writes: Brandon> Brandon> It is a simple matter. Eric does not like my personal style, Neither do I. Brandon> he thinks I'm an arrogant SOB. I also believe that you are an arrogant SOB. Brandon> He is somewhat correct, and I'm not going to change how I do Brandon> business for him. No doubt that's the secret to your success. Brandon> His options are to get over it and accept that people with Brandon> different personal styles can accomplish different things for an Brandon> organization, or we will go our separate ways. Please find something else to do or simply DO something and shut the fuck up about it. -- Mark A. Flacy Any opinions expressed above are my own. Any facts expressed above would imply that I know what I'm writing about. Sometimes, I do! "Be flattered when I assume ignorance. It's more complimentary than the alternative." -- Jerry Avins ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Why Eric doesn't like my personal style 2003-11-23 11:13 ` Mark A. Flacy @ 2003-11-23 14:22 ` Brandon J. Van Every 0 siblings, 0 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-23 14:22 UTC (permalink / raw) To: xconq Mark A. Flacy wrote: > > Brandon> He is somewhat correct, and I'm not going to change how I do > Brandon> business for him. > > No doubt that's the secret to your success. Do you want to define "success?" You're working on a hobby project with a small number of developers. What do you know about "success" in game development? You some kind of principal at a well-known and well-respected game company, just moonlighting here? > Please find something else to do or simply DO something and > shut the fuck up about it. Well, it is true that I am looking around for codebases where I don't actually have to convert people about what to do. That are in better shape from an OO and higher level functionality / make major changes standpoint. People like you make it easier not to worry about "generosity" as one of the factors. It's as though you think people should just gladly do things for Xconq, without regard for basics like: - whether anyone would actually use, desire, or test the Python code. - whether it would actually get checked into CVS in any timeframe of relevance to me. Without even these basics, why would anyone with my priorities develop anything for you? Nevermind all the flat C code. Sure it works, but in 2003 it's not an attractive development platform. You know this; the question is whether you have any energy to change it, or if you're satisfied that "it's working for you." If it works for you I don't begrudge you that fact. But it doesn't work for me, nor a lot of other OO developers out there. We simply couldn't do the things we want to do in Xconq without changes to the infrastructure. We are disinclined to write major, painful buckets of C code. FWIW the conversation with the Freeciv guys has been nicer, because I had already gone over the personality land mines here and I didn't feel the need to repeat them there. I never expected the Freeciv guys to change their ways, so I didn't set it as a goal to try. Rather, I thought I'd check to see if I might be pleasantly surprised, and I'd try to understand something about why C coders stick to their guns. Turns out someone did do some Python once upon a time, and it fell by the wayside. Guess if you build it, people don't come eh? Since you've seconded Eric's attitude, I'm outta here. Some of you will be glad; I'm glad, because at least it's a resolution. What I've learned from this experience, is team dynamics (or lack thereof) is as important a factor as anything else. Some kinds of people, with some kinds of priorities, I simply cannot work with no matter how many appeals to altruism or freeware do-goodery people might try to hide the problems in. What it gets down to, is you have your agenda, I have mine. "Thanks," at least, for helping me to clarify my agenda. I'm pretty clear on what it is now, this has been a good exercise for me, if not for you. And hey, you got VS 2003 files out of the deal, I've paid my bar tab. Next move is I'll either find a project that intersects with my agenda, or I'll start my own. Maybe I'll ping you guys about what happens at some point. Some of your lurkers I think would actually prefer to work on something ala Python. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "We live in a world of very bright people building crappy software with total shit for tools and process." - Ed Mckenzie ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: So let's get right to the point 2003-11-21 23:14 ` Lincoln Peters 2003-11-22 0:06 ` Why Eric doesn't like my personal style Brandon J. Van Every @ 2003-11-22 0:07 ` Brandon J. Van Every 1 sibling, 0 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-22 0:07 UTC (permalink / raw) To: xconq Lincoln Peters wrote: > > I'm not going to try to take sides, but I will try to answer some of > these questions Lincoln, thank you for taking the time. > (although none of them make good multiple-choice questions). It's a better multiple choice quiz than you might at first think. I'm laying out some requirements for me to do certain things. But, I'm open to the possibility that some of my requirements may be overly narrow. If people have a way of addressing my concerns, I'll listen to them. > > 1. Python required in the kernel > > a) yeah, that's awesome! > > b) hell no. Go away. > > I don't think Python is required, If I am to do "hodgepodge OO migration" for/with you guys, it is required. And it must be in kernel. "It's not required" is synonymous with "thanks for offering, Brandon, but we're not ready to move on this." If I do the work, it has to be in my preferred language, and it has to be forcibly stress tested by anyone who runs Xconq. I see no way to achieve these 2 objectives other than "it is required." I am not excluding the possibility of interop solutions with other languages. I am saying, if I am working, there will be Python and it will be required for Xconq's operation. Others might make similar, reasonable demands regarding C++, Perl, or whatever. But equally, they will need to provide the interop solution. > but Python would make it easier to do > things that are difficult or impossible right now (which have already > been discussed over the last few days). And it might improve Xconq in > ways that we can't predict now. Yes, I agree there are many benefits to Python. I think it will be an easy sell once you have example code doing something in kernel. > > 2. Kicking 7.5 out the door so that new features can be added > > a) yeah, any week now! > > b) I want my months before you even think about touching my > source pool. > > I think that it's quite clear that we all want to fix as many bugs as > possible before releasing 7.5. Although it seems that we're getting > close. Well, here's the rub. What's your timeframe? I'm a businessman, and I'm not interested in waiting. Certainly not in waiting indefinitely for when someone "might" kick 7.5 out the door. For me it's unacceptable to have a bottleneck like that in my critical path. If you're going to Do something, you Do it. Are you amenable to forking the source? A stable bugfix release, vs. a next-generation-let's-get-started release? It's what people often do to overcome this sort of problem. > Remember, open-source projects (usually) do not have marketing people > screaming at them. Xconq 7.5 will be released when it is > ready, and not a moment before. If that's your shipping culture, we won't be able to conduct business. It's not aggressive enough for a comercially-oriented developer such as myself. Also, it doesn't inspire people or keep the project growing. What I've been hearing is that people would like to see some of these Python features, but I doubt anybody's getting excited about waiting until 6 months from now to see them. > A lot of software companies (especially Microsoft) > could have saved themselves a lot of trouble by working this way. You've gotta be kidding. If you believe that, you totally don't understand the Microsoft release model. I live in Seattle, and I do, as do most people around here. Microsoft deliberately barfs the first version. They put it into the field and force the customers to find the bugs, that's part of how they make money. They use aggressive marketing to push their early crap. The first version of any Microsoft product sucks. The second one is so-so. The third one is ok. The fourth is often decent. The fifth is usually pretty good. Pretty soon, nobody can possibly catch up to the combo of their technical improvements + their marketing mindshare. It is one of the main methods by which they have conquered the computer industry. I don't know any commercial developer who takes the attitude of "sit back and wait." That's a hobbyist idea. If the disconnect is too strong here, that's ok, we'll go our separate ways and no hard feelings on my part. > I don't think that anyone is worried about you "touching our source > pool" beyond that you might introduce something that has unexpected > results. That's why anyone with CVS access tests a piece of code as > thoroughly as possible before committing it. I'm on board with that culture. It's what we always did at DEC, and we achieved the highest level of OpenGL Conformance in the industry at the time with such methods. I always apply fascist testing and source control methods in my own work. > > 3. Recruiting a horde of Windows C# .NET developers > > a) the more the merrier! > > b) get out of here you Micro$quish suckup bastard > > "Micro$quish?" That's a new one. Not really, it's common. Try Googling for it, albeit without the $. > Although I > suppose that it would make it possible to add lots of new features to > the Windows version, I would be reluctant to add anything > that would not work on all Xconq platforms. C#, .NET, and Microsoft-specific stuff is not my first priority. However, considering how aggressive I am once I'm doing something, it may come up sooner than you'd guess. It's how I'll be writing GUI code, when / if I'm ready to do that. Also, putting on the "cheerleader" hat I'll be trying to get people with the Windows mindset into your project. If you don't really feel "the more the merrier," if that actually makes you squirm in your chairs, we'd probably better know that about each other's attitudes and intents up front. In that case, it would be better for me to depart and lead a Windows-centric project. > For example, I would be willing to add > code to Xconq that would let it talk to MS Excel, but only if it was > possible to do the same thing with at least one other spreadsheet > application (e.g. Gnumeric) on other operating systems (e.g. Linux). I can help you with things needed for .NET / Mono interop, but you would have to be point man for Mono. For instance, I'm not setting up a Linux box. And, you should understand that language interop is my agenda, not cross-platform implementations for everything in Xconq. If Python runs in kernel on all platforms and C# .NET implements a Windows-specific GUI, my needs are spoken for. > Getting back to your question, if a horde of Windows C# .NET > developers > could make a contribution to Xconq without causing problems > in the UNIX > and MacOS versions of Xconq, I'd be inclined to welcome them. I think that's a simple matter of separating kernel concerns from GUI concerns. I'm not saying C# should be in the kernel. My view is, C# is going to be the preferred language for Windows GUI programming for the forseeable future. Meanwhile, Python is to be preferred for platform independent code, AIs, and game design scripting (if you guys decide to augment or replace GDL). I am evolving a hybrid Python / C# business model, you guys are my guinea pigs. :-) > Are the answers I provided firm enough? Yes I would say so. It remains to be seen what other people's opinions are, and what the dominant consensus of your group is. And also, whether Eric wants to raise enough of a stink about anything to effectively exert "veto power." Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: growth agendas and OO 2003-11-20 17:24 ` Eric McDonald 2003-11-20 17:51 ` Eric McDonald 2003-11-21 1:59 ` altruistic VS 2003 Solution files Brandon J. Van Every @ 2003-11-21 2:01 ` Brandon J. Van Every 2 siblings, 0 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-21 2:01 UTC (permalink / raw) To: xconq Eric McDonald wrote: > > Post-7.5/Pre-7.6: Ok, so when is 7.5 going to get kicked out the door? > > I am willing to contribute to the OO-ification of Xconq, if > > you want to > > pursue that agenda. If you think that agenda is misguided, > > then it's best to find out now. > > I don't think that this is necessarily misguided in the long term. > But the C infrastructure works pretty darn good at present. We > even have some "polymorphism" due to nifty macro magic.... Nifty polymorphism with macro magic? You are scaring me. I appreciate that you're working with a legacy codebase, and that a working codebase has inherent value. But surely, in the year 2003 you do not expect people to take this as serious OO. > Xconq currently attempts to be at a C89 compliance level to make > sure that we are supporting as many platforms as possible. The kernel, fine. But we've established that not all GUIs are equal on all platforms, nor are all build environments. > If you > say that we should just ditch those platforms, then you are simply > stating an opinion which is not even all that pragmatic. Python runs everywhere, so I don't see any issue with sticking it in the kernel, other than making sure it works. You might resist that idea now, saying "No no! We don't want instability and change!" But that is the price of moving on. I think you'll like Python, you'll start using it, then you won't object anymore. > I > actually did put out a feeler a while ago, to see about moving the > compliance level to C99; the conclusion I reached is that the > time is not right yet. You know, when I compile the stuff using VC 2003, I get all sorts of warnings. I don't see what would be such a big deal about killing all those warnings, they're mostly trivial int conversion and comparison warnings. I'm not volunteering to undertake that task right now. I'm just saying, if this is what's in the way of the "C99 compliance," it is not a big deal to take a day to get rid of all of those warnings. But, I don't know beans about what C99 compliance implies, nor do I care. The Windows way is to force people to upgrade. And by that I don't mean grabbing Micro$oft's new OS every 2 years. I hate them for doing that, and I won't! I mean that in 2003 you don't support Windows 95 anymore. It's a waste of development time that benefits almost nobody. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA 20% of the world is real. 80% is gobbledygook we make up inside our own heads. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Xconq UI thoughts 2003-11-20 2:26 ` Brandon J. Van Every 2003-11-20 2:57 ` Eric McDonald @ 2003-11-20 10:31 ` Andreas Bringedal 2003-11-20 10:37 ` keys and menus Brandon J. Van Every 2003-11-20 10:58 ` Xconq UI thoughts Bruno Boettcher 1 sibling, 2 replies; 23+ messages in thread From: Andreas Bringedal @ 2003-11-20 10:31 UTC (permalink / raw) To: xconq7 > > 5. Players hate to type; they would rather roll around a > > bunch of buttons > > and popups than hit a single key on the keyboard. > > I agree. I strongly disagree. If there is a paranthesis in the menu which tells you what keys to press to achieve the same result then those _will_ be used. 'm' for map being one of the most used ones. F9, F11 for quickload/save are also very handy. Ctrl-S Ctrl-L for regular save/load. 's' for sentry/sleep, 'b' for build, 'f' for fortify, 'w' for wake are also common to most players, especially for Civ players. The problem is when you have to search through documentation to find the keys. When you have the relevant key binding listed in paranthesis behind the relevant popdown menu choice you automatically learn it and use it. Another important thing is to use the standard key binding used most commonly in other games. Having different key bindings for each game you play makes it harder to learn and therefore harder to use. However a permanent menu choice like in Panzer general where you have a row of choices along one side of the screen is easier than key bindings and far easier than popdown menues. Panzer General's good menu system, pleasant game coulors, and easily surveyable map/units is half it's reason for success. (The other half being a good game/combat system) Andreas ^ permalink raw reply [flat|nested] 23+ messages in thread
* keys and menus 2003-11-20 10:31 ` Xconq UI thoughts Andreas Bringedal @ 2003-11-20 10:37 ` Brandon J. Van Every 2003-11-20 10:58 ` Xconq UI thoughts Bruno Boettcher 1 sibling, 0 replies; 23+ messages in thread From: Brandon J. Van Every @ 2003-11-20 10:37 UTC (permalink / raw) To: xconq Andreas Bringedal wrote: > > > > 5. Players hate to type; they would rather roll around a > > > bunch of buttons > > > and popups than hit a single key on the keyboard. > > > > I agree. > > I strongly disagree. If there is a paranthesis in the menu > which tells you > what keys to press to achieve the same result then those > _will_ be used. Yes, but they should never be required. > Another important thing is to use the standard key binding used most > commonly in other games. Caveat: some genres only have perceived standards, not actual ones. But I must admit, I found Xconq keys rather "wack" compared to Civ keys. I don't know if Xconq keys are based on Empire keys that were different or something. Anyways, the standard solution in this case is a user configurable keymap, plus some keymap profiles for common layouts that people use. I thought it was very strange that in a hex game, the movement keys were not in fact laid out in a hex on the keyboard, seeing as how that shape is readily available on the keyboard. > However a permanent menu choice like in Panzer general where > you have a row > of choices along one side of the screen is easier than key > bindings and far easier than popdown menues. What's a "popdown" menu? I've been thinking in terms of a "right-click always gives you a popup menu of specific icons" style of interface. I'm willing to train the user that they always need to right-click, using a scripted tutorial. It is not a difficult convention for Windows users, it's how you get around Windows. That way, permanent screen real estate does not have to be allocated, and you don't have to waste movement mousing over to the icon bar. > Panzer General's good menu system, pleasant > game coulors, and easily surveyable map/units is half it's reason for > success. (The other half being a good game/combat system) I agree that they nailed playability and ease-of-use. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA Taking risk where others will not. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Xconq UI thoughts 2003-11-20 10:31 ` Xconq UI thoughts Andreas Bringedal 2003-11-20 10:37 ` keys and menus Brandon J. Van Every @ 2003-11-20 10:58 ` Bruno Boettcher 1 sibling, 0 replies; 23+ messages in thread From: Bruno Boettcher @ 2003-11-20 10:58 UTC (permalink / raw) To: xconq7 On Thu, Nov 20, 2003 at 11:07:57AM +0100, Andreas Bringedal wrote: > > > > 5. Players hate to type; they would rather roll around a > > > bunch of buttons > > > and popups than hit a single key on the keyboard. > I strongly disagree. If there is a paranthesis in the menu which tells you same here.... i play xconq essentially with the kbd.... on the other hand i am regularly called a 'dinosaur' by my students.... > The problem is when you have to search through documentation to find the > keys. When you have the relevant key binding listed in paranthesis behind yup, and i remind in some games keys to select units to build were there twice making the move to the mouse an obligation.... -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-11-23 11:13 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-20 2:15 Xconq UI thoughts Stan Shebs 2003-11-20 2:26 ` Brandon J. Van Every 2003-11-20 2:57 ` Eric McDonald 2003-11-20 9:45 ` growth agendas and OO Brandon J. Van Every 2003-11-20 10:49 ` Bruno Boettcher 2003-11-20 10:59 ` Brandon J. Van Every 2003-11-20 11:51 ` Jakob Ilves 2003-11-20 12:05 ` Brandon J. Van Every 2003-11-20 17:57 ` Jim Kingdon 2003-11-20 17:24 ` Eric McDonald 2003-11-20 17:51 ` Eric McDonald 2003-11-21 1:59 ` altruistic VS 2003 Solution files Brandon J. Van Every 2003-11-21 4:17 ` Eric McDonald 2003-11-21 9:02 ` So let's get right to the point Brandon J. Van Every 2003-11-21 23:14 ` Lincoln Peters 2003-11-22 0:06 ` Why Eric doesn't like my personal style Brandon J. Van Every 2003-11-23 11:13 ` Mark A. Flacy 2003-11-23 14:22 ` Brandon J. Van Every 2003-11-22 0:07 ` So let's get right to the point Brandon J. Van Every 2003-11-21 2:01 ` growth agendas and OO Brandon J. Van Every 2003-11-20 10:31 ` Xconq UI thoughts Andreas Bringedal 2003-11-20 10:37 ` keys and menus Brandon J. Van Every 2003-11-20 10:58 ` Xconq UI thoughts Bruno Boettcher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).