Hi All,

I've been mulling over ideas for a tick based multiplayer RTS for ages now, and have yet to take the plunge and get these thoughts down onto some coherent paper form.

The basic premise of what I want to do is have a multiplayer RTS with a 2D graphical element. Visual pieces are moved around like you would in a tabletop game of Warhammer and turns are portrayed by a periodic tick. To keep things tidy and easier to micromanage, the game terrain is divided into a grid.

Currently, I have mocked up a grid in photoshop which is divided into 16x16 squares. The idea is that units can vary in size, the smallest ones (insects or whatever tiny lifeform is eventually written into the game plot) occupy one 16x16 square - from that starting point, larger units can occupy larger spaces (giant monsters or spaceships etc...). Provided the dimensions can be made from the original 16x16 building blocks.

One thing that I want to avoid, is the old Age of Empires approach to buildings, that is to say: "Build a Factory" or "Build a Turret", since there's little room for variety. One thing however, that Age of Empires did get right was the wall building idea - where you could place and join pieces in any shape you wanted to.

My intention is to take this one step further; give the player smaller denominations of building materials. Instead of giving them a plain old same-as-the-rest castle; give them the option to build walls, doors, wires, switches, power sources, stairways etc...

This way, the player's buildings are bespoke, fit the terrain better and give the player the opportunity to experiment with how the different components could be strung together to solve whatever problem. Plus, there's nothing to stop having cosmetic components (eg: Red flag, blue banner, yellow carpet, this statue, that statue etc...). The buildings also then become practical gameplay devices that can be entered and used, instead of just boring 2D standalone objects.

Can you think of any examples where this kind of simple 2D building has been used? Minecraft could be used as a 3D example, with it's potential for building devices and structures from smaller components.

I'd also be interested if you have any ideas for components that could be used. I will try to post a mock up soon to more clearly illustrate what I am talking about.

-

One of the other concerns for the gameplay would be species, as the many of the ideas that I have had are hinting towards a futuristic - or at least interstellar setting.

One idea that I had was to build the player's starting species, based on a set of preferences. For example, points are assigned to determine assets:

---
Points Left: 0/10

Strength: 4
Speed: 4
Intelligence: 2
---

From this, the character is designed; High values assigned to strength dictate a stocky physique - high values assigned to speed might mean that this species has six legs, but a poor share of intelligence points means that this species will take a little while longer to progress through the technology tree.

The technology tree will also be dictated by the species parameters that the player is assigned.

The more parameters that are available for change (the above being a simplified example), then the more variety in the species in the game (and hopefully, fewer instances of players encountering species identical to their own).

I'd love to hear what you all think of these ideas? Including whether or not they've been done before, done to death or even if you have anything to contribute to them?

They sound like good ideas. I can't think of any games at the moment with your building idea, but 4x space games often have a species design idea a lot like yours. Take a look at Master of Orion II; their pick system is used to customize your species and provide different play experiences. One comment I have is that it's hard to express variety in species if you translate a score in a given field to a specific feature, like number of legs or overall build. It might not be a bad idea to let the player desgin the look of their species as well as set its strengths/weaknesses.

One option I had considered is that since this game would be using a very simple 2D graphical interface, the player characters are going to be represented by roughly 16x16 - 32x32 silhouettes. White ones indicate your own units, red enemies, green allies, yellow indicates neutrality and so on.

This idea means that several tiles can be overlayed to build one silhouette. For example:

The game has three sprite sets - one contains the building block options for a skinny species, the next contains medium building blocks and the final one contains a larger species' building blocks. Each of these sets could contain one of its own examples of a two legged, four legged, six legged body part (the build of each depending on the set it comes from).

Once the physique has been ascertained, the game knows which sprite set to pick it's pieces from, so:

---
Points Left: 0/10

Strength: 4
Speed: 4
Intelligence: 2
---

This becomes "Strength is high, so the sprites will come from the third, large species sprite set. Speed is also high, so from that sprite set we select a leg spite that has six legs. Lastly, intelligence is low - so the head will come from the small column".

Because each piece of the sprite is juxtaposed onto the same silhouette, many layers can be added without worrying about how they might clash.

I suppose that ultimately, if the game gained enough popularity - the player community would probably reverse engineer 'what assets make what character', and people would be able to accurately predict their own species by assigning it the right levels - but the reason I am doing this, is that they are challenged to work with the species they get when they see what their characteristic preferences dictate.

-

If I were playing as an arachnid race, with lots of legs, high strength in numbers, speedy but individually weak - and I encountered an identical race, then each player will likely employ similarly matched tactics and things would get repetetive. The winner would simply be the one with more time to establish their bass/foothold/whatever...

However, if I were playing as that same race and I came across massive two legged humanoids, strong and, technologically advanced - but slow movers; things would be much more interesting. Would they use superior fire power to defeat me defensively? Would I employ geurilla tactics, overwhelming them one at a time?

The different species would obviously have varying architecture too, which takes me back to the point about buildings that I made earlier.

The major weakness to your system is that the game is an RTS. In RTS, you have to balance the tactical and logistic component of the game. Most real time strategy game are tactical oriented because there are aggressive players. With this complex building system, players are force to be less aggressive. Also you say tick-based. Of course every game is somehow tick based, but how long is the tick will influence the game. If the tick is 30 milliseconds or less, we call this as real time because the player cannot tell a difference. However, if the tick is sufficiently larger than 600 milliseconds, people will notice a significant delay between actions and will say the game is simultaneous active time. Real Time : Active Time : Turn Base, it's a scale of peoples reaction.

Notice, the reason that you have 3 sets is that you still don't really want to have "[color="#1C2837"]smaller denominations of building materials". If you do, then you will not need to have multiple sets. The goal of having "[color="#1C2837"]smaller denominations of building materials" is to have only one flexible set. Using 3 set is a way to improve on one hand the lack of hassle for the players, while on the other hand creates complexity to the game. You decide to have 3 sets because you anticipate that the players will become annoyed by the long time it takes to layout their city. However, you have to take into consideration that the game is always having two factors: tactical and logistics. By having 3 sets of small, medium, large, you impose a complexity to the logistics side to simplify the players actions; thus decrease their responsibility on the logistics front. It's similar to having unit tiers to add complexity to the game and force the player to be tactical and not strategic.
[color="#1C2837"]
[color="#1C2837"]For the game, you will have individual "bricks" to build the castles. However, you should implement so that gravity will hold a wall stronger, so if a single piece has pieces above itself, then it should have a stronger defense. However, there is also the tip over effect, and if the wall gets too high the bonus changes from positive to negative if the player does not taper the wall with a thicker base and a thinner top portion of the wall.

[size="1"]The major weakness to your system is that the game is an RTS. In RTS, you have to balance the tactical and logistic component of the game. Most real time strategy game are tactical oriented because there are aggressive players. With this complex building system, players are force to be less aggressive. Also you say tick-based. Of course every game is somehow tick based, but how long is the tick will influence the game. If the tick is 30 milliseconds or less, we call this as real time because the player cannot tell a difference. However, if the tick is sufficiently larger than 600 milliseconds, people will notice a significant delay between actions and will say the game is simultaneous active time. Real Time : Active Time : Turn Base, it's a scale of peoples reaction.

Yes.

To clarify, the game dynamics that I am refering to will be conducted over long, noticable ticks (likely to be minutes apart) - therefore calling this an RTS was inaccurate. A better phrasing would be "Persistent Tick/Turn Based Strategy"

[size="1"]Notice, the reason that you have 3 sets is that you still don't really want to have "[color="#1c2837"]smaller denominations of building materials". If you do, then you will not need to have multiple sets. The goal of having "[color="#1c2837"][size="1"]smaller denominations of building materials" is to have only one flexible set. Using 3 set is a way to improve on one hand the lack of hassle for the players, while on the other hand creates complexity to the game. You decide to have 3 sets because you anticipate that the players will become annoyed by the long time it takes to layout their city. However, you have to take into consideration that the game is always having two factors: tactical and logistics. By having 3 sets of small, medium, large, you impose a complexity to the logistics side to simplify the players actions; thus decrease their responsibility on the logistics front. It's similar to having unit tiers to add complexity to the game and force the player to be tactical and not strategic.
[color="#000000"][/quote]

The goal of having small denominations of building materials is nothing to do with the spritesets at all. The goal is to give players the ingredients, so that they can build something to their own liking - instead of giving them a finished, one size fits all item. Also, I'm not sure that you grasp what I was talking about in my original post - this has nothing to do with laying out a city or with tactics in the way that you have mentioned.

[color="#1c2837"]

[size="1"][color="#1c2837"]For the game, you will have individual "bricks" to build the castles. However, you should implement so that gravity will hold a wall stronger, so if a single piece has pieces above itself, then it should have a stronger defense. However, there is also the tip over effect, and if the wall gets too high the bonus changes from positive to negative if the player does not taper the wall with a thicker base and a thinner top portion of the wall.
[/quote]

You might have the wrong end of the stick here, the game idea is aimed a 2D environment - likely top-down. Also - the building blocks won't be literally broken down into brick-by-brick building. More like sections of wall. What you are talking about is entering the realms of physics engines.

Here are some illustrations that I mocked up to give people a better idea of what I am talking about.



The room above is made out of wall individual wall sections, the keyhole blocks are a typical sci fi energy door type thing, the calculator looking block is a switch and the lightening bolt blocks are batteries. The smaller blocks are wire blocks that the player can use to connect functional components.

None of this works - it is simply a mock-up to show you what angle I'm coming from. In this instance, a few components interact with each other to make a room that can only be opened from the outside. What I mean by smaller denominations is that the more ingredients you give the player, the more different things they can potentially construct.





This second mock-up shows a simplified diagram of the three tilesets I refered to earlier (the columns on the left). On the right are different species that could be mixed and matched by the computer depending on their initial asset assigment. The right hand side of the image shows several different permutations of the components:

Left: Small intelligence/head + Large strength/build | Middle: Medium intelligence/head + Medium strength/build | Right: Large intelligence/head + Large strength/build.

Excuse the quick mock-ups, I did them just to embelish this post. The actual graphics will hopefully be more considered.

I was thinking upon the line of isometric 3d. Anyways, I see the idea is that building using components is the goal. Of course, the advantage is the greater flexibility; however, the more pieces you develop, the more you have to program into the game to result in all possible combination, or you will have the statistics match to the component piece. In either case, there will be some degree of imbalance to certain combinations, so players will cater towards a few combination that are more optimal than any other combinations. There will always be a case for a few optimal sets that must have rock paper scissor effect to maintain some sense of balance. Your goal, during the play-test phase, is to ensure that more of the combination goes into the optimal rock paper scissor element of the game. The more combinations into the optimal range, the better. However, you don't have to have an entire game balance, unless you want to take several decades on game balance. Just a basic balance, that will need patching latter.

I would start some new threads which are more focused. "Tick-based RTS" had me thinking that it would primarily discuss smooth movement, rounds, timers, control, etc. as opposed to building blocks, isometric vs pure 3d, mobile attributes and statistics, and the likes.