Moo Clone in the making

[Vince278]

If any of you need a beta tester I'd be glad to help and give my opinion. I'm full of those.

I heard of others who were working on an X-Com clone but it hasn't made any progress in years.

[vmxa1]

Neither has the SC2 update, well some I guess, but at this rate I will be long gone.

[Tattila the Hun]

I have a succestion on ships. Make them FULLY customisable, no limits to engines or quantitys of weapons. If one wants to have warp 1engine, no armor, but 678443+ mauler devices, let him have it. Of course it would cost more than a 100 years combined production of your entire empire....

[Ellestar]

This text taken from zileas.com, now site moved to shambler.net Author - Zileas
Now i can't find it there, so i post text instead of a link.

Lecture 2: Rules and Game Dynamics: Game Design as Engineering

Game design is generally thought of as an art form, but in truth, only parts of it are. It is essentially a hybrid engineering/art like architecture for instance. Only some designers in the industry recognize it, or at least will say so, but those that do have produced some of the best games. I'm completely certain that Looking Glass Studios and Blizzard Entertainment both use this approach, among several other less known quality developers.

When making a game, its important that you have central objectives -- namely in the form of gameplay. What is it that you want your game to play like? How do you want to center the interaction? These concerns are very important to answer before you start addressing problems like "What sorts of tanks should I have?" or "What should the story be?". All too often designers will stumble into a project with some general idea, and start fleshing out the "fun stuff", like specific minor details of the story, and the abilities of various characters or units, or whatever, and then later on decide how the game rules work, while retaining things that were never thought through. In a nutshell, I cannot emphasize enough to engineer the framework first, THEN fill in the gaps and flesh out the details.

Generally, you engineer the framework of a game by making rules which create the desired game dynamics. Rules are obviously the mechanics of the game -- how far can an arrow fly, how does something die, what cards you can trump other cards with, etc. Game dynamics, which contribution to the creation of the gameplay in some way, are your ultimate objective, and come from the use of rules. A game dynamic might be something like "high ground is advantageous", which could come from a range bonus given to units being higher than other units, a downhill charging bonus to attacking downwards, or a penalty to climbing a hill (which makes ranged troops more effective). This would together with maybe other types of terrain-related game dynamics create a dynamic of terrain impacting strategic choices, which would be part of the key pieces of the gameplay. Putting together game dynamics results in your game focus, or gameplay. Also, game dynamics can, together, create other game dynamics.

You should try to figure out what game dynamics you need to get your desired gameplay, and then figure our rules that work to accomplish them. For instance, when making Quake 2, ID software no doubt decided that they wanted every weapon useful for a different situation. In order to do this, they thought up ways to accomplish this, and this ended up being a reason to add the grenande launcher (a weapon to shoot around corners), the rail gun (a sniper weapon), the rocket launcher (An area effect weapon for foes that are hard to hit), or the shotgun (A close range weapon). Although many of these effects are "realistic", ID tweaked them to bring out the desired characteristics.

Generally, if you look at a famous game, you should be able to pull out the game dynamics and the associated rules, and from there figure out what their goals were. A lot of the time you'll find that some things dont seem carefully designed, and a lot of the time you'll find a badly balanced game dynamic that would've been great end up breaking the rest of the game.

Examples of game dynamics:

An Example of a set of dynamics:
1) Myth: The Fallen Lords, developed by Bungie Entertainment, is in essence a game about tactics on a 3d battlefield. They chose the fantasy setting, which intrinsically makes a lot of things more believable and thus made things easier for them from a gameplay perspective. In order to accomplish the desired gameplay, they added the following game dynamics, based on certain rules:
a]Dynamic: High ground is advantageous
-Hard to climb
-Ranged units like archers shoot farther when shooting down
-Sight bonus (can see farther, allows better reactions

b] Dynamic: Units have clear counters
-Melee units can always outrun ranged units
-Short range artillery units (dwarves, fetch) extremely effective against
melee units, bad against other ranged units, as a result of their speed
and range (I.e. this is a dynamic supported by those rules).
-Clustered units prone to ranged units, non clustered units not prone.
-Skirmisher units (ghuls) are particularly effecitve against archers and
dwarves, but horrendously ineffective against anything else.

c] Reward mix-and-matched strategies that require creativity
-Melee units support ranged units well when ranged units placed properly
either as shields (delaying actions) or protection vs skirmishers.
-Short range artillery very good at softening up melee units, but can
seldom finish them off.
-Ranged units do well when melee units "lock down" other units by engaging
in hand-to-hand combat with them. Ranged units hit stationary targets
far better due to their realistic projectile movement. Also, their
arrows have scatter (like all ranged units), so they are again,
not as effective against non-clustered units (but clustered melee is
great against unclustered melee

There is more to myth than that, but that gives some idea as to how it becomes a game about tactics on a 3d battlefield.

An example of a slightly undermined set of dynamics:
1)Homeworld, by Relic Entertainment, is a great game, but some of its game dynamics are weakened slightly by a few problems. It was an extremely ambitious project, and its a miracle that it turned out as well as it did, and relic entertainment really proved itself in its creation. However, like all ambitious projects that cover a lot of ground, nothing was perfect. Three dynamics I am analyzing in this case are

a) The idea of a unit counterability circle (Complex rock paper sciscors basically), which I explain below

b) The idea of being able to choose strong counters to build against other unit mixes, as this is primarily what an RTSes strategy is about (that and tactical control)

c) The idea that all of the game, including the early game, should have strategic diversity, as that entails choices, and thus real interaction

Most of these were accomplished fairly well. However, they were weakened by either rules that were not thought out as well as others, or simple realities of the ambitious nature of the true 3d RTS they created. In general, some features and rules when not carefully thought out can sabotage your desired game dynamics. One of the biggest difficulties in game design is spotting these problems before its too late to easily correct them. This is what Relic fell into, but the game turned out being a groundbreaking title anyway It is far easier to see the few problems in an otherwise perfect game, than to even begin to start a coherent discussion about the flaws of a really bad game. That is why I use Homeworld.

a] Unit counterability circle flawed
-Fighters do well against capital ships. Corvettes do well against fighters
Capital ships do well against corvettes. However, super-capital ships are
cost-effective against everything, and one of the super-cap units is
extremely effective against fighters. The result? Corvettes end
up being a bit less useful than other units, especially the multigun,
heavy and light corvettes (Salvage, repair and minelayer have special
functions that put them outside the true corvette dynamic, and into a
set of their own dynamics)

b] Production discourages choosing strong counters
-Your starting production capability (which is all you will have for at
least 30 minutes), can produce any one item at a particular speed. If
you produce more than one item at a time, they all produce at their
normal speed. The result? In order to spend your income, you produce
multiple units, sometimes when you only want a lot of one, or two. At
its surface this forces unit mixing, however, so its not ALL Bad --
but it DOES undermine the players ability to choose strong counters, and
unit mixing can be innately balanced (encouraged) into the game, which it
is in other ways in homeworld..

c] Early game static (usually)
-Map transverse times tend to be very long. Prevents many early game
gambits from being effective
-Because of dynamic b, in cases where you can apply early game gambits
such as various rushes, you cannot produce covettes (which counter early
fighters) in large enough numbers to make a difference... so you counter
with fighters... effectively resulting in no strategy choice, and a
static early game


Overall homeworld is an excellent game, even with the flaws I've mentioned. It is so new, and yet so playable, that such small errors can easily be overlooked. However, in future versions of the same sort of game, no doubt such errors could differentiate the title from other titles without such errors. Since homeworld is one of a kind, and those errors are far from severe though, it is still a good game.

[Ellestar]

Lecture 8: Play Balance
Game balance, in the broadest sense, is derived from two major axioms of game design. The first is that players should have options and choices -- a game without choices is usually not really a game... choices and the interaction involved are what elevate a game from reciting a script, or watching a movie.
The second is that games should not have unnecessary components that dilute the gameplay. Choices that are never a "right" choice, or are almost always a wrong choice are not really choices at all, and are just noise that makes the rest of the game less compelling. Combine these two, and you have the basis of balance. Specific balance issues are listed below:

1) Dominant Strategies
A dominant strategy is a case where one choice is always better than the other. This is always bad, because its effectively one choice, with noise -- not a compelling bit of gameplay. In multiplayer games, this manifests itself as times where you always play the same strategy no matter what, or when one player can play a particular sequence of actions and responses that guarantee the other player will be at a disadvantage, no matter what.

2) The true "costs" of actions
Actions in most games have some inherent game-based cost, be it some resource, like gold or minerals, or in the case of many turn based strategy games, a turn, as well as some player time investment. There is also an inherent player time investment that is especially relevant in real time games, and somewhat (though not as) relevant in other games. Actions with low payoff, low game cost, but high player time investment, are generally less useful (and imbalanced-weak) compared to low payoff, mid game cost, low player time investment actions, simply because many players will refuse to "waste" a lot of time, or in the case of a real-time game, cannont afford to use such time in that way.

Several examples from Starcraft:

An example of this is mass zergling wave rushing being favored over a number of other more "cost effective" strategies. You could also consider the fact that a mass tank push vs protoss is theoretically unbeatable, but in practice, pretty easy to beat because of its difficulty of flawless implementation.

Its important to realize that actions have a concentration cost AND a game cost when dealing with real time games especially. You must balance both to keep all actions equally appealing in their own unique way.

3) Risks should correlate to Rewards, or Versatality is power
When an action is versatile, its allowing you to in effect make several actions, for the cost of one (or at least the concentration cost of one). It allows you to not use as much time when responding to a variety of things, and allows you respond to indeterminate situations with less risk... This can be a substantial benefit in many cases, and versatile actions that allow an adverse response from the other player (i.e. an attempted counter) should not be especially strong compared to less versatile actions, since versatility is "playing it safe".

4) Balance across skill levels
When dealing with a competitive game, you want skill differentiation -- when you have skill differentiation it is important to have balance be constant over skill levels for the most part. In this respect, it is important that as skill increases, that various game components increases in their apparent effectiveness. One potential hazard here is that in extreme situations, the game might just not be fun at all at a particular skill level.

5) Scenario Imbalances
Sometimes called "map imbalances", these are imbalances stemming from the initial conditions of the game. Sometimes, when you can start with different options individually, the "global" configuration of the game may be slanted towards favoring one particular individual configuration. Similarly, sometimes there may be only one global configuration, but specific starting "positions" or states might be better than others. As the alternative name implies, this is most apparent in situations where you have a map.

6) Dominant Playstyles
Similar to Dominant Strategies. Often, when playtesting your game, you will notice that there are several major playstyles which are at least somewhat feasible. Its important to try to cultivate as many playstyles as you realistically can (don't expect more than a few though), and to get them to the point where they are about equal in potency.

The distinction between dominant playstyles and strategies is that I define playstyles as being a more general approach to the game, and strategies as being specific responses to situations. In some games they are one and the same In some they are not.

7) Single-Player Games and Difficulty Balance
You don't want single player games to be too hard. In general, a good way to balance them is to balance them to slightly below the median skill level, and then add extra goodies for higher skill level people, or just add higher difficulty settings. It's also important to make sure that the game becomes progressively more difficult. Mech Commander is an example of a game with a big problem in this department, in that mission 3 out of 25, also known as the farm mission, was the hardest mission in the game, and prevented a lot of people from playing past the very beginning of the game. Don't do this!

8) Expected Return of Game Elements
You obviously should balance the power of things largely based on the cost to get them, and the value of the effect they can create. When dealing with something that becomes obsolete (which should be avoided, but has to happen in some types of games), consider the expected return over time, including the period after it grows obsolete. For instance, in a real-time strategy game, a unit that is good for the first 5 or 6 minutes, but that becomes obslete after, can be a bad thing, because normally when your units survive you come out ahead, but if you fight early on with this unit, and have survivors, its as good as dead as the game progresses...

9) The Basic Cost Effectiveness Equation
Cost effectiveness is Square Root of [Firepower*Hitpoints/Cost-squared]

Test it if you don't believe me. Firepower represents game effect, be it damage, or something else. Hitpoints represent the durability of the game element, which generally will be just that -- hitpoints. Cost is the cost it takes in the game, usually in terms of a game resource. Its harder to measure concentration of course.

Theres other equations too, but we wont cover them now, and I want to avoid too much vigorous hand-waving.


Implementing play balance
With all that theory aside, we can think about acutally balancing agmes. Play balance is one of the more difficult aspects of game design, and one that has broken all too many otherwise good games. Few designers consider the implications of their game in terms of play balance in initial design stages, and only a few more even think about it prior to a mid-alpha state of development, especially when dealing with computer games. The key, like many things in game design, is to think things through early so that you dont have a hellish task to complete later on. Making a system innately balanceable is the first step to making a balanced game -- some systems will be easier to balance than others, and some will be almost completely impossible to balance acceptably well. This lecture discusses how to make your games more balanceable, for the most part.
1) Modularize, Modularize, MODULARIZE!
Its important to modularize your design, as the title mentions. What I mean by this is breaking your game elements into seperate pieces, and trying to ensure that the play balance values of each influences only one game dynamic a piece. Theoretically, if you tweak the value, you then only influence but one thing's play balance state. An example of this going awry would be the Mutalisk in starcraft. It has two major purposes, those being anti-air primary attack and anti-land skirmishing. It shares a common attack for both purposes, as well as hitpoints, etc. Because of this, Blizzard had _extreme_ difficulty balancing it satisfactorily because to change the value of the attack or hitpoints influenced BOTH roles, rather than the problem role. (i.e. the land attack was consistantly too much, but if they downgraded it too much, they ended up with the unit being too weak against air... The Blizzardism for modularization (which is also good for hypnotizing impressionable business folks) is "Purity of Purpose", at least more or less.

2) Unnecessary Details are... Unnecessary
Dont add details that you dont need. Again, the purer the game design, the easier it will be to balance it. "Noise" in your design will probabaly undermine other factors too, and its hard to play balance when its hard to determine what variables are actually the significant ones. The more easily understood the game system is, the higher your chances of figuring it out well enough to balance it. When I was an inexperienced designer, I'd often add in details without thinking too much about it, and end up having to gut the system later on and trim off fat to get it play balanceable.


The Play Balance Process
The preferred approach to game balance, in my opinion, is:
1) Work out "balance on paper" and think through situations and counter situations. Try to get a feel for how you want things to work in general.
2) Balance the game for a wide but very select group of game elements, primarily BY FEEL. Exclude math at this point. Ensure that the game is balanceable as well, namely, that hooks to affect major game dynamics are in place.

3) Scale the balanceu from specific elements to similar elements using balance math, such as the fragmentation equation, and the effectiveness equations.
4) DO NOT rely on master math formulas, etc. You could write a PHD on this stuff, and theres always weird variables you wont account for. You CAN do a board game in pure math, but its still hard. Once you use math to scale things into relevant ballparks, go back again to your design instincts, and do a rigorous qualitative test to discover if things are working against other game elements as designed. This will tell you 100x more things than most balance math will.

Take Small Steps!

Inexperienced designers make radical changes to their play balance #s with every revision of the game. Don't be this designer! After your intial 1 or 2 play balance sweeps from your initial qualitatively balanced set of elements, take it slow! Although well-designed and modularized systems will resist this, most game systems tend to have balance #s that are easy to "overshoot". If you dont take baby steps, changing one or a very few elements in very small amounts at a time, it will be hard to seperate out the effects of doing these things. Also, when attacking a specific problem, try just tweaking ONE quantity at a time.

Players Play Consistantly

If you have an imbalance in one stage of your development, your playtesters will continue to play with a playstyle that reflects it. Give playtesters time to adapt to changes in your state of balance, and strongly encourage them to try different approach. Top notch QA people will do this without being asked, but most of them either get other jobs, or get promoted to design, so you won't have many top notch QA people. Similarly, fans are inexperienced testers and wont know this either. Be careful!

Dont Be Afraid to Force What You Want!

If you want something to be more effective, MAKE IT MORE EFFECTIVE. Sometimes you try and try to work around something to get a result by altering indirect contributors. Don't do this too much when a simple straightforward approach will work.

An example of this in my experience developing was when I wanted to be able to have certain units be countered strongly by certain other units, and yet strong against other units. I tried to make this work through movement rates, and ranges, and a lot of other things... I also had an armor system that had some semblance of reality, but was primarily a game design construct. After 8 or 9 hours of wasted effort, I just made a system that applies an effectiveness coefficient to every units attack, vs any other unit (i.e. its a table of values for every unit vs every unit), which gets me EXACTLY the effect I want, without screwing up tons of other things by altering indirect forces on this. Of course, those indirect forces still cause things to work a certain way (like high speed, moderate range units eat slow melee units), but I can close the gap with anything that needs such a change by changing a single number -- which is completely and utterly modularized.

The downside here of course is that doing too many "Secret modifiers" or whatever you want to call them tends to make the game less intuitive. I got around this by pressing my modifiers in directions that the units were "supposed" to work anyway.

Workshop:
1) Study how chess pieces are balanced relative to each other. Why are the strongest pieces the strongest, and how might you analytically measure chess piece effectiveness?

2) Is monopoly a balanced game? If not, suggest some fixes. Otherwise, suggest why it is in fact balanced.

[macraig]

Dr Hacker:

Hey, dude, you're duplicating efforts! Haven't you heard about the Free Orion project? It's intended to be an open-source MOO 2.5. DOZENS of people are already on-board. It's in the conceptualization phase now:

http://www.kgasj.net/ap/

http://sourceforge.net/projects/freeorion

I think your talents might be better exercised lending a hand with that rather than reinventing the wheel, eh?

[drhacker]

Thank's for the suggestion, but I'm not trying to make a MOO clone, I'm trying to see if I can create a completely new game, but with influences from MOO...

[Gilgamensch]

DrHacker, did you receive my PM/e-mail?

[Zaphod Beeblebrox]

what i didn't like in moo2: (cant remember moo1 anymore):
- you can only have 4 commanders/governours, you cant even wait to throw out one until a new one arrives.
- in combat screen you don't see which of your 27 ships of the same type is the one with the commanding officer.
- though you can customize your own race, the ai races are always the same and after a few games you will know how they behave. (and you can be sure that no race with the uncustomized attributes of the race which normally bears your pic will show up).
- some of the ships just look dull, ok, thats a very personal opinion
- starsystems which don't have any habitable planets never can be colonized, regardless of how fine your planetary construction skills are.
- i would like to see starbases which don't belong to any solar system but get placed where you or the ai want them.
- i want to see combined fleets of allies!
- the galaxy is 3d, the game should be as well (ok, thats rather hard to do in a way that still can be played easily)
...
lots of other stuff, it has been a real huge time since i last played moo2 even more moo1. not tested 3 so far.

nevertheless i love those games and eagerly await what you will have for us and could perhaps be a little of a help if you want. though i'm not good at graphics or such stuff, better in posting ideas that never get implemented

oh, and i'd like to see habitable moons!

[vmxa1]

The ships with leaders have an L.

[Brutalisk]

DrHacker: I've played Moo1 and MOO2 for many years and all other noteworthy strategy games including some great games which u may have not heard of...

Rather than along post in an already long thread, i'd rather talk to you on ICQ or email.

ICQ#: 4506289
email: evghenios@yahoo.com

[Gilgamensch]

Tried to get hold of him, for a longer period, but nothing happend???????