I'm in the middle of designing a pretty large project, and trying to get everything together before starting a team. Luckily, I believe my design and "idea guy" abilities are above-par... However, I'd like to get outside opinions and perspectives.

For the sake of simplicity in this question, we'll say my game is an RTS (similar to C&C or StarCraft). My general question is obviously, what do you as individuals consider a decent mixture of complexity (and associated strategy) and learning curve.

To give a broad example, C&C has a smaller degree of complexity, and practically NO learning curve--within 15 minutes, you know exactly how everything works. In contrast, Sins of a Solar Empire (one of my personal favorite games, EVER), the learning curve is enough to introduce your nose to the inside of your LCD monitor, but this is because of an incredibly detailed (and intricate) amount of options available.

Now you understand my general question, here's a few specifics about my game itself. The player will have several buildings at his disposal, one being a Droid Manufactory--for those who don't know, yes, that is an actual word. haha, where he'll produce droids for his army. As I have it right now, he has these general types at his disposal.

A.R. (or Automatic-Rifle Droids)
A.P. (or Armor-Piercing Droids)
C.R.A. (or Close-Range Assault Droids)
Med-Tec (or Medical-Technician Droid)


Obvioously, more would be to come. But, I'd like each of your individual opinions on whether you'd prefer something more involved, like:

R-Series (Rifle Class)
--S-R (Semi-Rifle Droid)
--S-R2 (Improved S-R)
--A-R (Auto-Rifle Droid)
--A-R2 (Improved A-R)
--L-R (Laser-Rifle Droid)
--L-R2 (Imrpoved L-R)
A-Series (Assault Class)
--CR-A (Close Range, shotgun-style)
--CR-A2
--LR-A (Long Range, mortar-style)
--LR-A2
--AP-A (Armor Piercing)
--AP-A2
S-Series (Support Class)
--MT-S (MedTec Droid)
--PS-S (Portable Supply Droid)


Again, I'm looking for overall, broad comments on what your thoughts are between complexity/learning-curve; and, in particular, how you feel about my specific example. Also, feel free to note or comment about my naming schemes. lol

I think complexity only works if you stagger it. You buy a Rifle droid, it gets 5 kills and you upgrade it to either Semi or Auto (although I would call semi-droid a marksman, to make the benefits clear (assuming the benefits are increased accuracy)). Then, if they choose semi, they can upgrade to.. I dunno... Sniper or Engineer. If they choose auto it's HMG suppresion or Lasers.

This way you can introduce lots of complexity, but make it reveal itself slowly to give the player time to catch-up.

Also, I would avoid using the abbreviations. Newbies wouldn't know what they mean (although they are pretty easy, there always a few silly people.)

EDIT: I like complexity if it's easy to understand and managed well. No clicking 6billion times to upgrade my droid army to assault class one at a time. I wanna drag me a box over dem nasty mo' fo's and do dem all at one time y'hear?

I have one simple rule in game design which trumps all others: If it's not fun, its not in the game.

Many games are guilty of introducing too many options just for the sake of having them. The best types of complexity tend to be the emergent ones, not some artificial and masturbatory quest for being or having "the most XYZ ever!".

Therefore, I say -- and I realize this isn't concrete advice -- that added complexity is fine up to the point that it is no longer fun, and you should never push it any further.

There are different types of gamer's of course -- compare Mechwarrior to Armored Core -- Mechwarrior has some element of choice/customization, but not to a great depth, and it appeals to a more casual crowd while Armored Core has traditionally placed a great emphasis on options and customization to the point that choosing the correct load-out prior to a mission greatly affects how you will approach it and whether you survive.

Placing such demands on a player appeals to some, but for most it is a turn-off. Which you persue probably depends on whether you intend to break out into the mainstream -- if you're content with the indie market I think you can persue either equally well -- there are more casual gamers but their attention is divided, the hard-core players, on the other hand, are fewer but starved for options and are used to being served by niche, independent developers.

What people will seek out to fill their simulation desires never ceases to amaze me -- I have one friend who is really into Submarine simulation games (theretofore unknown to me) -- literally simulating WWII era submarine combat. He related to me recently, how one mission required him to locate and destroy an enemy submarine *solely* by listening to the pings coming in off the sonar, and how awesome that was.

We can think about this in more concrete terms before bothering to prototype. Ask yourself, and think hard...

*Would the player actually want to make these decisions? Is there a reason I would want a certain combination? Why a laser? Why do we even have semi-automatic rifles that cannot be fired fully automatic? Fully autos can easily be set to fire single shots. If they are balanced, why would I pick one and not the other?

It's like if I come to two doors, A and B and have no information. If I might as well decide by a coin toss, and the results are the same, than the whole situation is superfluous.

*Consider the user interface. What are the user interface implications?

We're talking about a lot of units.

You can easily customize a group by mixing individuals.

e.g. Instead of having support bots with three choices of rifles, you could have support bots, and rifle bots, and just throw 'em together.

You wind up equally involved in deciding the mix and design of a battle group, but do so through the same user interface you use for everything else, rather than adding an additional system for customizing units.

In other words, when you can mix individuals, you're already deeply involved in customization of your forces.

*You list upgraded or better versions. How you present this can be a factor. Civilization games basically have a level on a unit; conscript, regular, veteran, elite. They can level up in fights. Rather than presenting a "Warrior" and presenting a "Super Warrior" in the same role as a different unit, it just marks a Warrior as a vet.

*You might consider customization options for player self-expression.

A lot of video games allow players to have fun doing things creatively, even if it's just facade with little gameplay significance. Think Batman Returns (SNES) where you can pick up a clown and hurl 'em into a glass window. God of War has a similar approach. Those are formally single player games, but this is in there for when you play them with friends watching. Then there's online games, like Farmville, etc. etc. etc. And then there's teabagging.

Last time I played Civ online, we gave cities custom names like "Teledildonia" and the Greek city of "Mediocretes", and my personal favorite, "For Sale".

Basically, it's a lot of spackle, theatrics. Name a battle group, for example, and the name hovers over the group on the opponent's screen.

It should be blatantly clear that such elements are not important gameplay-wise so that players who don't care don't boggle over them unnecessarily. One should never be forced to make such customizations. In Civ, you can skip naming a city and it will fill in the name.

Re: Aspirer

Your thread title says "Ideal". I think that makes the discussion hard, because unless you can lockon to one type of audience, it could be a moving target.

Perhaps you could first define the dimensions you want for your units, then pick perhaps 15 of the possible combinations and set that as the number of unit types per faction. Each faction can have a different mix, and you then you can attach abilities to them so that the units have some emergent and synergetic effects.

Common Dimensions:

o Slow vs Fast movement
o Early vs Late resource type (Low vs High Tech)
o Low vs High endurance
o Low vs High effect
o Short vs Long range
o Slow vs Fast action rate
o Land vs Air
o Support vs Attack
o ...

The cost (in terms of resource, time, upkeep, etc.) is not part of these dimensions. It is determined based on the overall strength. If the unit is weak, then it is made to cost less.

If these dimensions are only binary, here are 256 combinations. But you will only make 15 unit types. Why 15? Because it is a number familiar to people that play Starcraft. It makes the game appear familiar. If you make a game with the same complexity using only 5 units, it will feel like a puzzle game to those players. If you do 30 it will look excessive even if the tactical complexity is the same.

Note that you could make a game with just 1 unit type and design it to have the same tactical and strategical complexity as Starcraft. The reason is that such complexity is a function of not just unit type, but the range of actions, environment, goals, resources, and situations that the game provides.

So perhaps the choice of unit type number is more of a tradeoff between reducing the number of assets and having enough visual variations so that the player is still visually stimulated but not overloaded. It doesn't matter if the lemmings can do a million things. If they all look the same people get bored. Also, you don't want everything to happen on one layer, because it looks flat and thus less visually stimulating.

So let's say 15.

[Edited by - Wai on November 20, 2010 5:10:18 AM]

Don't confuse complexity with complicated.

Compicated systems have many components with little interactions. Complex system can have a few components, but they have many more interactions.

For instance, look at the game Go. This only has 3 components (player 1's pieces, player 2's piece and the board), but the number of interactions between them is so large that no computer can calculate them all.

Go, is a complex game, but it is not complicated.

Another game that is complex (but not as complex as Go) is Scissors/Paper/Rock. With this game there is a fair amount of interactions that go on at a secondary level. You start to think about what the opponent will do, do they have a tell, etc. It is actually quite a complex game when viewed at the secondary level.

One of the things I like about S/P/R is that it is not limited to just 3 options. You can construct it with more options if you like. The next number of options that works well for S/P/R is 5 (call them A, B, C, D and E).

With this you can get several different arrangments. For instance:

1) A -> B and C.
B -> C and D.
C -> D and E.
D -> E and A.
E -> A and B

2) A -> B,C and D.
B -> C and E.
C -> D and E.
D -> B and E.
E -> A

As you might be able to see, these are quite different from each other (I like 2 best as it has a level of asymitry to it). The other thing is that there is no "best" option so no matter what you choose, there is some other combination that will beat you.

When applied to an RTS, you can add in extra effect that make each choice slightly different. Maybe A costs a bit more than B, or that C is only half as good as D, but also half the price, and so forth. You can also havae environmental effects that can change the way the relationships go. So in some circumstances A might beat B, but in others, B might beat A (but these would be limtied and A, in general, would beat B).

With a few of these effects thrown in (they make it more complecated as well as complex at the same time), you can develop a fun, yet deep system that offers real strategic choice to the player.

Just one basically irrelevant comment: the word "droid" is trademarked by Lucas Film and they're pretty aggressive in defending it. it's a very expensive license to purchase, so just pick another word for your final design (like "android" or "robot" or whatever) ["mech" is also trademarked, i think Microsoft owns that one] [smile]

I think the trick with good RTS unit design is that entry level units should never become useless. In your design, why would I ever want to build an S-R once I had the capability of building an S-R2? Further, what's important is not what the names of the units are, but what mechanics they provide to your army. A functional description of your combat design would be useful. Are you doing a traditional Rock, Paper Scissors combat model where every unit is countered by another? Is it a hard or soft counter system, etc? That is much more useful to decide than what the actual units are and you should have a good grasp of your combat mechanics before you start brainstorming units.

-me

First off, thanks a bunch for some very detailed and worth-while answers!

A few things I'd like to comment on about your responses:

JamesPenny--I do agree with the abbreviations, it would be a little much for new players to grasp quickly. I'm basically just trying to think of a good way to organize them, not only for myself, but in a way that could fit a tidy interface. The only issue I have with your suggestion about leveling each unit in that manner, is because in an RTS, you're controlling potentially DOZENS of units--leveling each like that could be tedious, wouldn't it?

Ravyne--You make a good point. As far as my targeted audience, I'll explain my idea a bit better, and maybe you can understand a bit better what I'm trying to target in particular. :-)

JoeCooper--Nice way to think about whether to add them or not. lol, I'll have to question my design a bit more. ^_^

Wai--I'll have a certain degree of the variances be based on factor, but those will be more for "player" units, which I'll explain in a sec.

Edtharan--Exactly! I'm trying to find a way to make the game "complex" enough to be enjoyable by those RTS fans who want to have a very detailed game, without making it complicated and shying them away from learning it.

Palidine--I didn't know "droid" was copyrighted... That's a bit much, ain't it? lol Kinda like how I heard Microsoft tried to copyright the phrase "double-click" and "window" a few years back. About my combat design, let me explain a bit.



Here's my actual game idea in total. It will be a FPS --and-- an RTS... For argument's sake, let's say it was a 10 player session, 5 vs. 5. Four players would take the role of "Soldiers". Since we use StarCraft as an example, consider these like your "Hero" units. They would respawn (the object would be to destroy your opponents base). There would be a few classes for these type of players to choose from. Snipers, Close-Combat, Support-type, explosives, etc. These players would be playing basically a multiplayer first-person shooter.

The fifth player would be a "Commander". He wouldn't directly be in the battle, but would be viewing the entire battle from the base building. He would see the entire battlefield from an isometric view. He would be in charge of managing resources, structures, droid production, etc.

Just to save some questions I'm sure people have about how I'm managing this, the current working title is "NanoWars" until I find a better one. A key factor of the game will be the "NanoCell" which will use nanotechnology (real definition: the study of the controlling of matter on an atomic and molecular scale). These will be produced at a fixed rate at base, and each player is limited to one at a time (EMP pulses would ruin them in close proximity). The player would deploy these where he felt needed or suggested by the Commander who has a view of how the entire battle is unfolding. The commander would spend the limited resources at his disposal to send the NanoCells the code that would order them to deploy into the correct structures.

Anyway, now that you have a more in-depth understanding of my idea, maybe you can understand a bit more about what I'm trying to balance. The Commander will have deployed a Cell into an Android Manufactory, and will be controlling the manufacturing of selected androids. Some will be have long-range capabilities, some will have more life, some with weapons better spent on armored units or structures.

So, I'm trying to decide on where I should balance it for the players who would rather play the RTS portion, instead of the FPS. So, I'm assuming I'll mainly be gearing it towards an audience more in favor of a complex system.

Re: Aspirer

Have you played something like this in an actual game? I think a potental issue is that a typical FPS player and RTS player have a different time frame for gaming. So a game where an RTS player considers "short" could be "too long" for the FPS player.

Other probable issues:
o The FPS players don't want to shoot at bots. They want to shoot at players.
o The FPS players often want to play in terms of scenarios, where they can replay the same setting over and over.
o The FPS players, when playing an scenario, is always already at the height of the conflict, they don't need to wait for an interesting situation to arise through RTS.

Quote:

[The RTS player] would be in charge of managing resources, structures, droid production, etc.

If all of these are going on like an actual RTS, the FPS players would be bored to death. You could stretch out the RTS session across multiple FPS sessions, but an FPS player would only want to play the parts where things are ready to go. The FPS players would rather play preset scenarios that are guaranteed exciting than to sit in a game hoping something exciting would happen.

It might make more sense if the RTS player just controls a set of pre-determined equipment. The equipment could be jointed decided by the team. During the game, every team member can command the equipment, but given that it could be distracting to do both FPS and RTS at the same time, a player may dedicate himself just to command the equipment.

I've heard about the idea of the commander before, don't know if anyone got to really make it.
I see problems in it, first, inconsistency on gameplay, the two vertients are way to different. Second, how will the commander communicate with the soldiers? would he/she point in the map and the soldiers see the mark and go there if they want? they would have to trust the commander a lot. Also, if the commader is in the headquarters as you said, if it is destroyed, its game over. That is overfucusing in one building, what about a player building hidden bases by enlarging the expansions?