The Shape Of The Game
SDxWiki

A place to discuss what the game should look, feel, and smell like.

Dan Muller: Initial ramblings

What intrigued me most about JumpGate was the idea of a persistent persona that could interact with the universe in ways that were more intricate and meaningful than just combat. I mean, combat is fun, but I was really drawn to the trade aspects of the game. Ultimately, I didn't find JumpGate's economic modelling rich enough or believable enough to keep me interested.

Squads are cool, but let's face it, it's hard to coordinate getting a bunch of people together online at the same time. Wouldn't it be interesting if a clan (which implies a larger group than a squad) included resources that you could draw on even if other player members weren't available? And if you competed with other clans in ways other than combat? Economic competition, for instance, doesn't require realtime co-presence of the competing parties. Given some level of AI to act on your behalf, other areas of competition could exist too, for instance territorial (with automated defenses).

Don't get me wrong, I'm not dissing real-time flying and combat as an important element of a game. But my interest lies more with simulating diverse aspects of a world, and ultimately, with developing AI to interact with the model and with players.

Whatever shape the world takes, I think that in order to really involve players, it has to be self-consistent.

One interesting topic to consider is the RPG question. JumpGate billed itself as an RPG, but contained only a very thin veneer of RPG terminology. It was really a simulation. Perhaps the managed events promised for post-release will add some RPG elements, but I think that it might be possible to have simulation and traditional RPG characteristics blended together in more interesting ways.

The RPG characteristics I'm thinking of are things like simulated skills, modelled using statistically modified random chance. In JG, there was nothing like this. Instead, real skills were required: for piloting and interacting verbally with other players. No skills were modelled at all in interacting with the game universe. Their "experience points" and "level" concepts were a watered-down version of the worst aspects of RPG levels.

There might be a certain tension inherent in including both simulated and real skills in a game, though. For instance, let's say that a Trade Negotiations skill gives me better luck at negotiating purchases with simulated companies in the game. But why doesn't my skill count for something when I negotiate with a player? (Or does it? How?) Or, if piloting skills are entirely non-simulated, why can my character get better at negotiating as I play more, but my piloting skills don't improve? (Assume I've got two left thumbs and a worn-out joystick.) To what extent are such inconsistencies tolerable?

Frank Swierz: Frank likes Dan's initial ramblings, but adds this...

Jim Horn: Says Frank didn't add much...

John Harding: Two things spring to mind (I just discovered I can't count - that explains a lot of my code!) - these are all at a more conceptual level:

  1. KISS - the more you try and model the more difficult it is to get it right. Aren't JG's experience & levels simply devices to keep you playing after you've amassed enough wealth? I'd call them pacing mechanisms rather than central game elements. OTOH, levels are apparent in everyday life too - generally they don't let the rookies fly the F16 fighter jets (otherwise I'd sign up just for a laugh!)
  2. At a higher level I want a game that melds single player (SP), multi-player (MP) and massively multi player (MMP) into one consistent universe where I can easily shift between all three. Is that too much to ask? SP when I want to play for half an hour when I want to. MP for when I want to play with my buddies. MMP for when I want to interact with a community.
  3. I also want to be able to commit different levels of time to the game at different times without too much fear of being totally left behind.
  4. I want to be able to commit different levels of effort too: I like driving games because I don't have to think too much - get in the car, press the gas peddle and go... I rarely tinker with all the car settings - I just wanna race. Sometimes I want to immerse in a role that's more challenging like intergalactic trader - but I don't neccesarily want to fly for 10 minutes accross empty space to ply my trade. Complex fight sims (first person or the JG variety) are fun but they take too much brain power to be an "idle distraction"
  5. I want fries with that.
  6. This sure beats work ...

Dan Muller:

Sounds like you want a whole bunch of different games.

  1. JGs levels affect a lot of stuff - what ship hulls you can get, what equipment you can buy, parameters of the missions you get. If I could afford an F16, I could fly it -- except for the laws that regulate airspace, requiring me to have a certain license. I can get a license by taking the courses. How successful I am at my job (missions) doesn't factor into it.

If we were in a less regulated environment, the license wouldn't be an issue. Space is big -- maybe some areas are so regulated, others not. In any case, JGs levels sounded like military hierarchy titles, but affected too much.

There should definitely be obstacles -- no pain, no gain (and no challenge). But they should be more believable and varied, I think.

  1. I think this can be addressed by having a varied selection of interesting activities. Goals for all social types and moods!

  2. Same answer as 2, except that I'd like to examine the "being left behind" bit.

If the things that you can attain are varied enough (money, skills, social/business connections, prestige, whatever you want to model), then you don't get this simple notion of "my level is higher than yours" feeling. Instead, people can stand out in more varied ways. Some players will still be obviously more advanced overall than others, but you reduce the "rat race" feeling by giving people more things to focus on than they can easily integrate. Who's better, Arnold Schwarzenegger or Bill Gates? So many different ways you can compare them, who can say? (Hint: Arnold has better one-liners.)

But to some extent, you play less, you will in fact advance less. The effect is probably not so bad in a live game with a user base that is constantly changing. But if you really wanted to, the only way I could see to counter this might be through automation acting on your behalf when not on-line. Maybe I don't play much, but when I do, I spend my time writing really good automated convoy scripts that keep making money for me when I'm offline. Not sure if that's a feature you'd want, but hey, it's just an idea.

  1. As for the "press the gas pedal and go" variety, there's no real reason for a JG-like sim to be difficult to start. All you need is some conveniences like pre-configured sim ships to pick from. Some sort of sim is essential as a training ground without consequences, I think. JG actually has two sim modes, offline single-player and online multi-player. From a development point of view, the offline one is most difficult, since it (at least conceptually) requires you to have some form of server software running for your client to interact with. (Although JG cheats, I think - the environment is just completely static except for your ship.)

Enuff for now, gotta do the bills...

Dan Muller again...

Some more random thoughts that I need to record.

  1. Combat in space: I've read a few books, e.g. C. J. Cherryh's space series and Hamilton's Neutronium Alchemist series, where space combat is depicted very different from, and IMO much more realistically than, dogfights-in-space like Wing Commander, JG, and IWar. These battles are characterized by high delta-V encounters that last mere seconds. Once basic courses for each encounter have been plotted, everything happens under computer control, with decisions occuring in milliseconds - deployment of armaments and defensive mechanisms with varying degrees of autonomous intelligence, high accelerations, and very, very short lives. Breaches of ship hulls tend to be catastrophic. Survival rates are low. A game that approaches tactical combat from this perspective would be very different from a flight sim, but could still be a lot of fun. More emphasis would be placed on quick tactical decision-making skills, but there would be little or no demand on motor skills for aiming and flight path adjustment. You size up your resources and what you can determine of your opponent's, plot a course or select an automated attack tactic, and wait tensely while your ships' computers and luck determine the outcome. (If you don't like the mention of 'luck' here, consider that any conflict that occurs in realtime involves luck. You can guess at your opponent's likely choices when making your own, but you can never know what they will be.)

  2. I would really like the typical ship to have a small crew. Small, because intelligent and highly reliabile ship technology requires no more. But still, there's a qualitative difference in play when you know that your decisions affect not only yourself, but also your crew -- even if they're only simulated. Their payroll will also represent a drain on your profits which you must take into account. These NPCs could also have varying skills at their jobs, which might include maintenance, cargo loading & unloading, perhaps even higher-level functions like handling purchasing and sales in-station.

  3. Segue to ... skills, simulated and otherwise. What skills should the player be required to bring to or develop in the game? (The aforementioned tactical decision-making, for instance.) Which can be usefully simulated? (Trading skills translate to better prices, and perhaps an ability to find merchandise where others see a tight market.) Also, relationships can be simulated. Have you spent a lot of time at a particular station? Chances are you'll have better contacts there, get better prices on merchandise, perhaps cheaper lodging (nothing's free, eh?). Maybe even higher priority in launching and landing slots at a congested station.

JDH After talking with Dan about point #1 above I really like this idea (because my motor skills ain't what they used to be!). I think it melds well with the idea of having a technically based game where we encourage players to develop automation scripts. It also removes at least one avenue of cheating (reflex augmentation). I could see space battles coming down to a complex game of paper/rock/scissors (but with many more than three choices). Those that wanted too could have totally automated combat scripts whereas others could select a strategy for each "pass". I also think that we could create a visually stunning display (with slow motion playback from different camera angles, for example). If we want a more dogfight like mode of play we could model planets and have those dogfights occur in planetary atmosphere (and get more jet fighter like flying characteristics).

I like the idea of NPCs aboard a ship. I also like the idea of convoys and combining ship capabilities - how about the ability for a group of say three or four ships to combine into a virtual ship. Their flight computers would cooperate and give control to one ship. The other ships would then keep tight formation with the master ship - but their pilots would be free to concentrate on other duties (combat for example). Or the purpose of combining might be to get enough power to tow an asteroid or cargo tug. It might be a good way to encourage cooperation between players. Or it might suck.

I'd like to find a way to create more of a sense of a busy space port. Lots of traffic, official communications from the station (think air traffic control) that sort of thing. The chance to bribe corrupt officials to get a better, quicker, bigger dock.

Dave Hettmer

I never played Jump Gate, so I have no preconceptions about what an online game should be (possibly a good thing) or reference points for what online games offer (possibly a bad thing).

I've read Hamilton's series as well and I agree with Dan's first point. Whatever happens, players oughtn't be required to master key mappings or own a particularly snazzy game controller in order to fly effectively. If we place more emphasis on computer-assisted flying then game play will depend less on reflexes, fancy maneuvers, and low ping times.

I come from D&D background, so I lean toward allowing players to assume a personae with abilities that are enhanced or diminished by character races and attributes that aren't necessarily possesed by the player. This helps primarily with NPCs, which will likely be a large part of the game. Also, various games I've played/created allowed characters to spend resources to enhance certain characteristics or buy better equipment. For example, we designed a game we called Death Highway where players bought cars and armed them. New characters tended to buy VW bugs and load them up with one big gun, or buy bigger vehicles and put in a handful of smaller guns. As players advanced they would earn money to buy things like better targeting computers. This sort of thing gives players some control over their automated systems.

Dan Muller Here's an interesting link with some food for thought: [Hearts, Clubs, Diamonds and Spades: Players Who Suit Muds]. The article categorizes Multi-User Dungeon playing styles and their effect on MUDs. It closes with some opinions on balancing gameplay in MUDs. (If you're in the category of people that don't like to categorize people, you might not like this article.)

JDH I found this interesting but a little tedious towards the end - but on balance I thought that it presents a good basis for considering long term viability of game design. For example we could attempt to map game design features onto their affects on the player types as we seek a "type 3" style of game. I do have questions about the validity of the whole article (after all I suspect that Bartle is the administrator for a type 3 game which he suggests is the most attractive commercial proposition). At first I thought that there may be another category not discussed - namely "cheats" - however I think that they fall into the "explorer" category. This is especially true if we approach the game with the concept that our servers are the only thing that we can trust - thus the "cheats" become "explorers who have found a new way to interact (or exploit) the game". Dan suggested that people who program complex scripts (assuming we provide such a facility) identify themselves as a particular category (although others may consider them cheats because of their unfair advantage). I think these people belong in Bartle's "explorer" category as well - when reading the character traits that Bartle assign to this group I quickly identified it with the type of people who would want to develop scripts. This can also be a good thing because "explorers" tend to want to share their knowledge (which is how they get their validation) - and this lends weight to the idea that script development and trading might be a valid part of the game.

Istvan JumpGate's player-skill-based system is what makes it unique over all the character-skill-based systems out there. However, that approach appears most optimal for the flight-simulation genre. It does attract players, but it does admittedly turn off the incompetent pilots who still are interested in combat, especially player-versus-player. I am still personally interested in player-based systems over character-based systems, because it seems more interesting than push-button-watch-AI-adversary-die. However, I think it may be possible to examine and strive for some level of integration between what the player can do and what the character can do, especially in a sci-fi environment.

I am particularly interested in game designs that completely avoid the common "level" approach for regulation of player activity. Generically, I like setting regulations on activity following a "license" or "permit" model, rather than advancement-based restrictions. There could be many kinds of such in a game environment, and achieving the ones a player is interested in would be motivational goals, certainly during early play, and potentially for the longer-term. The most compelling reason I have to want to get rid of levels relates to John's arguments about time and playability: casual players want to be able to play with friends who are intensive players, and any level system that relates difficulty of environmental challenge to the level hierarchy will categorically prevent that.

Last year, I wrote up some design whitepapers on a space-based MMOG, very simulationist, using only our solar system as a game environment, but with vast scope for slow and dramatic expansion by means of adding local star systems from time to time as the game's storyline progresses. It appears you are already planning to build a sci-fi game of larger scope, but I will dredge up some of my old material and see what your efforts might find useful. Many of my thoughts for that game design have been refocused so as to be applicable to any genre, and placed in the [manifesto document] I also linked from my SDxWiki homepage.

The automation scripting is a particularly fascinating idea that links with another concept that has been communicated to me, which I've not yet added to my manifesto document (linked above) because I haven't yet tried to articulate it generically. Flailing a bit here, the basic idea is that players like to tinker and customize. A simplistic implementation example is present in Diablo II, in which many "treasure" items possess "sockets", in which smaller items, such as gems, which are imbued with inherent bonuses and other attributes, can be placed. The socketed items thus inherit attribution from the included objects (sort of backwards from an OOP perspective). The key, though, is that the player can choose to "build" an item with the desired attributes, assuming the right materials can be obtained. In a sci-fi environment, a direct translation of this concept would be equipment with components. A player would select components based on efficiency or special functionality, and thus build the equipment actually needed. Perhaps a specific character-skill (or set thereof) could be useful for modifying components, improving them to squeeze additional performance greater than the default. These modified components would thus obtain greater value than default components (which has potential economic impact I won't discuss now). Perhaps the best game mechanic for this kind of modification is one that involves activity by the player - preferably not simply a repetitive click-task, but one that requires some sort of mini-game such as a puzzle or problem-solving. All of these concepts, of course, represent an enhancement of the "crafter" type play present in most fantasy MMORPGS. There is no reason a sci-fi game cannot contain gameplay like this that would appeal to a player desiring an engineer or "gearhead" character. Script programming, is of course, a sort of problem-solving, in that you have a desired goal, and a set of tools (functions) that you can arrange as you see fit to accomplish the intended task. I'm interested in figuring out playable ways to limit the availability of functions in the automation language based on value economics. Perhaps the availability of automation-capable widgets is simply a higher-value range in the spectrum of available equipment. More importantly - the script-interface should be controlled: (A) as a purchasable object instance (B) a script, once written, should consume resources (C) there should be specific mechanics written into the game for the process of "copying" scripts - such that transfer of a script design is kept within the scope of the game and not something transferable among players by e-mail. This may not be possible, but it should be explored.

JDH You make excellent points about some of the details of scripts. The economics and management of scripts could follow the same model as software does today. First to address the econimics of scripts: To run the best scripts you need the best equipment - we could build in the ability to upgrade the flight computer from a Pentium 2130 to an Athlon 2131+ ;-) Furthermore it's not just the comp but the peripherals that feed into the economics - automation interfaces for guns need to be purchased seperately than the guns themselves. Personally I don't think the running of the script should consume any extra resources other than those directly used for the functionality of the script (the "bullets" used by the gun) - i.e. there should be no cost for running the script after you've purchased the script and the equipment (unless some enterprising gamester wants to run an ASP version and have people lease software!). As for the management of scripts I imagine we could use some form of public key cryptography to ensure that the person running the script is entitled to it. I see scripts as adding realism to our game and as an alternative to the joystick to help assist player-skill rather than subshume it entirely.

Istvan: Actually, about scripts consuming resources, I was thinking in terms not of the "run" event consuming resources, but rather that the "storage" of the script might consume one or more resources possessed as an attribute of an in-game computer system. For example, to create in-game "cost" for using automation, in addition to your proposed automation interfaces (excellent thought!), each computer system might have an abstract measure of capacity/power (I'm thinking in terms of old pencil-and-paper games about computer hacking, wierdly), and the size and complexity (read: bit length) of each written script stored in the "ship's computer" would actually allocate some of that capacity. This fosters (A) writing efficient scripts (B) drive to purchase higher-capacity hardware among script junkies, and most importantly, (C) constraints on automation linked to economy. Like automation? Pay in-game for a good shipboard system to handle it all. This might also help with the issue of people trading scripts - such as in a case where someone wants a spiffy script his system can't handle: he might be able to copy the script by hand into the game from an outside e-mail, but if he still has to gather the resources to upgrade his in-game system to handle the new script, the impact of the external transaction is partially contained. Of course, for there to be trade in scripts, we're assuming an internal automation language of significant complexity. The more complex it is, the greater the need to supply potential players with default scripts for basic functions, and the greater the potential that we are limiting the player base to idle programmers. :)

JDH: I think I was trying to suggest a similar "cost of entry" that you discuss by suggesting we provide the capability (and thus, hopefully the need) to upgrade the flight computer. I equated "processing power" to what you called "capacity". I think we're very much on the same page about that. To address language complexity - part of the driving force behind some of this desire for scripting for me is that the implementation of the game will be greatly enhanced by use of scripting for internal development. If we have scripting internally then why not expose it (in a suitably managed form) externally? To prevent the game turning into a coding exercise for idle programmers (like me, who really shouldn't be typing this right now ;-) ) we need to take care that scripts are there to augment rather than replace player-skill. Lunch time over - back to the salt mines ...

DWM: Fascinating. Using computers to simulate computers -- actually a time-honored tradition, but not in MMOG's, as far as I know, or at least not at this level of detail. Part of me likes the idea of limiting capacity. That forces another tactical decision on players -- what program loadout do I give my computer for this mission? On the other claw, it doesn't seem very realistic. Wouldn't ship-board computers have enormous processing and storage capabilities in a far-future scenario? We might need some fancy footwork to make this sound plausible.

BTW, what's an 'idle programmer'? You mean those guys I used to see playing Unreal Tournament after hours at work? :)

Summary List

I think a summary section of assumptions for base gameplay is needed. Some of these, however, likely belong in the "features" section, but are worth keeping here for now as they help make what we are discussing less abstract.

Other Questions or Issues

Lots of things are left unsaid in the comments and list above.

Random comments:

I'd suggest a first-blush game design incorporating space environment only, but with planetary objects present physically within the environment, but inaccessible.

I suggest player-objects analogous to those used in Elite II - you can change ships and hire crew, for example, but you don't "walk around" as a person. This simplifies interface issues, although it could detract from role-playing potential in the environment.

I suggest avoiding zone effects religiously - more recent games have begun using a "bubble" method, based on detection ranges, to pass local information to the client and to eliminate "zoning".

A detailed, living backstory may NOT be necessary if the players and their organizations are given power to manipulate things in the environment. Eventually, "backstory" could become simply reporting on events that occur due to player action.

The more alternate copies of the game world in existence, the more difficult it is to keep (A) a consistent managed story line and (B) a coherent player community.

One very general comment: with all the MMOG development projects out there (see link on my Homepage), any development effort must attempt a design and include features several conceptual steps ahead of the games already released or near release, simply to remain competitive. Often, any game has one or two key design features that were well-implemented compared to contemporaneous games. A common player complaint is that "no single game has all the right pieces". Trying to bring together feature sets proven effective and popular in other games might be a beneficial exercise.

Istvan: On the subject of fundamental steps beyond what is common on the market is a concept that may not yet be properly articulated in my [Manifesto], but which I have been thinking about a great deal very recently as I get more disillusioned with JumpGate.

The issue relates to the advancement hierarchy in a game. The designer can create a whole bunch of "things to do" in a game, but if all those "things to do" link to a single advancement hierarchy, then by definition there is only one thing to do in the game - advance. Now, in a game like Dark Age of Camelot, this is less of a problem, because it is made very clear that the game is about bashing critters, and for bashing critters you advance up the hierarchy for the sheer purpose of bashing other cooler critters, and eventually to be able to participate in an ongoing war versus other players. Fine. In JumpGate, however, the description of the game is that it's some wonderful interactive roleplaying environment wherein you can choose all sorts of different career paths and activities and do anything you want. That's a lie. In JumpGate, everything you do is for the purpose of advancing up the hierarchy. The game-killing realization is that the hierarchy is there for its own sake and itself gets you squat.

I firmly assert that it is important to design a game in which there is no hierarchy, nor something that may be mistaken for a hierarchy. While it may appear that this flies in the face of conventional practice, it is exactly that unconventionality that I think makes this the right thing to do. The "role-playing" genre has been mistakenly construed for years in computer gaming as "games in which characters have classes and go up levels", which is only an artifact of the early roleplaying game mechanics underlying the systems being adapted into the computer games.

A real and ideal MMORPG environment will truly be what JumpGate advertised, but never had - a dynamic environment that responds to the cumulative effect of the actions of the players, and in which the players can choose any sort of activities they desire, performing which activities directly allows them to directly and indirectly continue to influence that environment..

If players need guidance on deciding what to do, and let's face it, there are a LOT of uncreative players out there who are accustomed to being led by the nose through every activity both in their games and in their lives, then that is what the backstory of the game is for, and why the direct integration of the backstory elements with the game environment is critical to gameplay.

DWM I've never heard anyone in this group argue strongly for a level-based system, and several of us are opposed to it. The article on the evils of D&D-style levels which someone (Istvan?) recently linked to was well received, from what I heard. So I think we're in pretty good agreement on this.

The 'simulated skills' talked about earlier on this page, though, is a form of level hierarchy, but in manifold independent categories. The RoleMaster RPG system from (defunct) Iron Crown Enterprises worked somewhat like this, but it's an approach better suited to computer games than to paper-and-pencil play, because of the complexity. (One of the problems with the D&D games I ran in the latter part of my DMing 'career' was that they bogged down under this system -- although the biggest culprit was the 'realistic' combat system.) Personally, I could see using such a system, although I think it would be worth trying a game without this. Istvan, do you see this as something that could be 'mistaken for a hierarchy'? (Istvan:Potentially, but I'll reserve judgement - a broad skills system is vastly better than a single hierarchy. In fact, one of my pet attempted solutions, a "prestige" system with numerous axes representing different political orientations within the game's native environment, likewise has the danger of being mistaken for a hierarchy. Both the skills approach and my "prestige" approach, I believe, would be most effective if used together, because they'd "muddy the waters" - giving the "achiever" player type things to attempt wheras a purely abstract environment might only frustrate them.)

I tend towards the opinion that if the simulated environment is rich and interactive (primarily physical, economic, and sociopolitical simulation, in roughly that order), then players will find things to do that they enjoy. I think our focus should be first on building a scalable, rich environment, a step at a time. (OK, a few simultaneous steps at a time -- can't everyone working on the same bit of code at the same time.) Gameplay mechanics such as skills, etc. could be added later, I think. Rough backstory is important relatively early to help shape and justify the simulation characteristics. (But note that I am not disagreeing at all that the backstory will be important to provide direction for many players.)

DWM Yawn. Saturday 10:30 a.m. and I stayed up too late last night.

I finally read Istvan's Ecliptic description a more closely (just skimmed it quick the first time). The idea of scaling our game down to a single solar system is interesting. Spoiled by grand space opera stories like Hamilton's it's easy to forget that a solar system is one friggin' huge chunk of space, compared to the human scale of thinking. It might be interesting to develop a game that drives this point home. I'm reminded of futurist speculation I've read about the possibility of humankind eventually filling much of the solar system, with a think band of sun-orbiting habitats. (Or take it a step further to Niven's Ringworld scenario.) Imagine what happens when we have billions more people than we do now. (And it's likely that the solar system could support this.) Where currently we might have one Hitler and one Einstein in a generation, we would have billions of them. And you would likely have every conceivable variation of human society existing somewhere simultaneously. Mind-boggling.

For the moment, I'll continue thinking in terms of an interstellar game, but if anyone wants to nibble at this idea a bit more, I'm all ears.

...

I don't think that I've recorded the "IMABOT" idea on the wiki before. (That's I'm a bot.) This has more to do with backstory than game mechanics, but there's an interesting potential synergy. Consider some of the more interesting far-future scenarios that futurists have postulated. For instance, Ray Kurzweil in his book "The Age of Spiritual Machines" (ISBN 0140282025). (See also http://www.kurzweilai.net.) Kurzweil believes that by the end of this century, humans will by-and-large have transferred their consciousness' into machines. What could this look like in a game?

Istvan: Yes, if absolutely nothing else, applications of technologies for "brain-taping" and "machine bodies", are excellent potential backstory explanations for gameplay treatments of "death" - which is a major game design issue. I'm not quite comfortable with leaping straight to the "you are the ship" paradigm - but there's really nothing wrong with it, and if the idea could be beaten into the heads of players (a potential stretch), it would simplify a number of considerations that need to be accounted for when defining the play environment and its limitations.

Istvan: Since I don't participate in the "hallway chats" that Dan has implied are happening from time to time, I may not have the same feel for the overall project scope that the rest of the group might have. Describing the communal game concept as "Jumpgate but more better" (good description, Dave!) is a flawed point of origin, because some of us haven't played JumpGate, and frankly, we each may have different ideas about what JumpGate is or could have been. Additionally, we all have ideas from other games that we might like to integrate.

I want to try to focus this part of the discussion by stepping back to first principles.

We seem to agree that we want a space game. Can we describe what kinds of gameplay we want in it? What do we want the players to be able to do? Let's try to build a master list. The kinds of things I'm looking for can be really elementary or really complex. We can all list things from JumpGate, or different games such as Elite. I'll slap a few things down to get us started, but I hope everyone will add to the list. Each thing in the list will constrain the potential vision in some way, but when we're done we ought to be able to in turn build a comprehensive list of the systems needed to make the intended features happen.

DWM So many questions! How do we organize this discussion? You've covered so much ground already that I'm loathe to insert new items. How should we organize commentary on these items? Can we organize these into smaller categories, and hash out details on separate (possibly already existing) pages? I'm feeling an itch to do some major wiki refactoring...

Istvan I'm uncertain. I think these issues are the most critical facing us - along with whether or not to do a driving game instead of a space game. However, these questions are somewhat independent, and we can discuss what kinds of activities are needed for gameplay abstractly, without even choosing to do driving or space just yet. We need to build a common vision of what's good in the game. I think the fundamental flaw in JumpGate is that NetDevil never had a clear vision for what the game was going to be - or were too easily swayed by the community once they realized that their internal vision was indeed incomplete. They ended up with a hodgepodge that lacks power. No new features will fix it, the fundamental design is inchoherent. We must at all costs prevent this phenomenon from happening to our project.

What should Players be able to do?

And a related question...

What things should be present in the environment?

For more general discussion...

What should the game feel like?

Are we striving for space opera? A gritty, wild-west, frontier feel? Something more like the Age of Sail? A cosmopolitan spacefaring society as seen in Star Trek?

DWM I don't think space opera works well as a model. It implies a tightly focused script, which I think is at odds with an MMOG. Just like an MMOG fantasy RPG will never feel the same as a D&D game with a game master and a small handful of players to whom she's catering. Certainly many elements of the environment can be borrowed from typical space opera milieus, but the experience will be very different from reading a book. I'd like an environment with multiple human centers of civilization, expanding frontiers, and regions both regulated, unregulated, and in dispute. I like the gritty, thriving-capitalism-on-the-verge-of-implosion feel of books by authors like Gibson, but such books focus on activities in the midst of teeming humanity. Use that as a background, and add frontier elements reminiscent of high seas piracy, with trade having to traverse large and largely unregulated spaces. I imagine pirates spent a lot of time bobbing around hoping for a ship to come by, though. I prefer to avoid severe choke points such as jump gates for a variety of reasons. In particular, I would like exploration to be difficult but feasible, and some of the proposals I've made regarding locomotion are intended to try to balance these things. Can an expansive environment remain entertaining, or will it appear empty and boring?

Istvan I think your last question is a really important one. My opinion is that too much wide-open space will indeed cause the game to appear empty and boring. This is one of my chief reasons for advocating choke points and limits on the system of long-distance travel. It might be very interesting, however, to try unlimited travel within a single star system (which is still DAMN big), or more limited long-distance travel in a large array of star systems. I think unlimited travel in a single star system might present a simpler design problem - and it definitionally resolves the serious "edge-effect" problems of the environment. I think we could build both "gritty" and "frontier" into a single star system: gritty around the biggest few settled worlds, frontier in belt or outer system settlements. It would also be easy to have regulated and unregulated spaces. Apparent size of a space is dependent upon travel times and levels of available detail, so one could easily build a game of epic scope within a single star system.

Istvan (much later) I'd like to characterize the theme of the game as being about "the expansion of human civilization". I'd argue against trying to plot a specific story to happen once the game is launched - I feel that's a big mistake a lot of online RPG's make. History needs to be described, but I'm more simulationist: set up a consistent environment with some initial conditions, give it a push, and see what happens. Maybe I got corrupted by JumpGate to a degree, but most of my ideas for "things to do" in the game relate to resource exploitation and grandiose construction projects that players can both start and participate in. I especially advocate giving players the in-game tools to influence each other, as well as the environment - allowing them to effectively create what amounts to events and "story" all by themselves. I'd like to see the players directly involved in expansion of the game environment, as well: for example, supplying resources to projects that result in new parts of the environment being available for gameplay (like interstellar missions to get a gate set up in a new star system).

JDH Istvan, have you followed the [Hearts, Clubs, Diamonds and Spades: Players Who Suit Muds] link that Dan posted above? I'd like to suggest that everybody skim it and see if they agree at least somewhat on the player categorizations and their interactions. If we want to aim to achieve the first M in MMOG I think we need to design our game universe with care to balance our players. I think we can do this (after all space is a big enough place for all of us). I happen to agree with your description of what would be good - I'm just wary about the need to satisfy a self-supporting community. I'd also like our universe to be centered around "the expansion of human civilization" - furthermore I think I'd like it to be "confined" (at least initially) to our own lowly solar system (but still expandable to many star systems). After the game has a reasonable following I like the idea of starting rumours that such and such a power has worked out how to travel beyond our star system. Some players would believe it and some dismiss it. Have our own players help some random people discover how to use this new capability and then see what they do with it - will they keep it secret? or share it with the world? How quickly will the usage spread. Just some ideas ...

Istvan Yes, I'd read that study some time ago. I admit to a sort of prejudice against the Achiever player type, but I am forced to wonder if Achiever behavior isn't partially an artifact of the historical design of such games. My hope is to create a situation where that type will still find satisfaction, even if there's no overt "hierarchy" to climb. I mean, Achiever behaviors exist among people in the Real World as much as in games. How can these people cope without a Real Life level structure? Well, I'm confident most of them do just fine. As to taking a simulationist and experimentalist view of the potentially expanding game universe, well, I think it would be just way too cool to be able to do something like what you describe. It might not turn out to be feasible for marketing-based reasons, but it would still be way too cool.

DWM 2004-10-11

Here's another wacky idea for a game, inspired by [this article].

What if Dr. Wilkins had been correct? What if space was not a vacuum, and the Earth's gravitational (and magnetic!) attraction ended about 20 miles up? Imagine a game set a hundred years ago, with space galleons floating between worlds, propelled by feathered wings, which in turn were powered by clocksprings, steam engines, or perhaps even sometimes galley slaves! Has anyone already done a game like this?