next »

[Dacke]

Depends ... In terms of RTS a fun & strong AI is possible - just limit apm of the AI to the actual apm of the human player.

The problem is that the strong RTS AIs tend to be limited in the strategies they employ (at this point in time). The 2010 winner only played zerg, defended until it could get mutalisks and then used it's massive APM to overwhelm the enemy on all flanks.

In order to create a fun AI, it would be more important to make it versatile and make it play more like a human. Limiting it's APM would make it weaker, but not fun to play multiple games against.

[Netsu]

i thought p2p becomes problematic/laggy when you're not playing against someone geographically close to you? (or at least thats my experience with p2p games)

It's gonna be the same thing with a central server architecture if that server is too far away from you, and depending on how the game handles high pings, if the other player is far away from the server it can also negatively impact your experience. p2p basically means that one of you is the server.

The advantage of p2p is that it will always take less time to propagate data between the two of you than with a server in the middle. If you hit a button, the other player will know sooner if you tell it to him directly.

[Justin Meisse]

I don't want to derail all the legit difficulties of designing and programming an RTS but there's actually a pretty good solution to making isometric art, model out your assets in 3d & render them out as sprites.  Looking at the old C&C games, I'm pretty sure that's how they did it.  You could also do it real time with an orthographic camera locked at an angle you want to replicate an isometric look.

[Alevice]

Modelling P2p under that pretense demonstrates a lack of understanding how networking works. The route between each peer could take longer depending on the network infrastructure than it would to a centralized server*, where all the input logic is processed and synced (and anti cheat mechanisms are handled).

[Dacke]

Command & Conquer used a mix of sprites and voxels.

[Netsu]

Modelling P2p under that pretense demonstrates a lack of understanding how networking works. The route between each peer could take longer depending on the network infrastructure than it would to a centralized server*, where all the input logic is processed and synced (and anti cheat mechanisms are handled).

Just to be clear, the 'p2p' I'm talking about is a server-client architecture where one of the players serves as the server. I don't think there is any other kind of architecture that could be called p2p still in use in real-time game networking (if there is I'd love to hear about it).

In such case introducing a third machine, a central server like Battle.net, will make the time it takes for information to propagate from one player to the other longer.

[Justin Meisse]

Dacke: I wasn't aware of that, I only played up until Red Alert which was all sprites AFAIK.  I work on a mobile game that uses isometric pre-rendered sprites and it's a lot easier than painting them by hand.  Of coarse it's hard to get that pixel perfect look but I've seen some plugins and shaders that can come pretty close, like the technique used here http://forums.tigsource.com/index.php?topic=35320.320

[Dacke]

According to Wikipedia:
Tiberian Sun, Red Alert 2 and Yuri's revenge used voxels to some extent (vehicles and some buildings). But not C&C 1 nor Red Alert 1 (my bad).
http://en.wikipedia.org/wiki/Voxel

[Alevice]

Modelling P2p under that pretense demonstrates a lack of understanding how networking works. The route between each peer could take longer depending on the network infrastructure than it would to a centralized server*, where all the input logic is processed and synced (and anti cheat mechanisms are handled).

Just to be clear, the 'p2p' I'm talking about is a server-client architecture where one of the players serves as the server. I don't think there is any other kind of architecture that could be called p2p still in use in real-time game networking (if there is I'd love to hear about it).

In such case introducing a third machine, a central server like Battle.net, will make the time it takes for information to propagate from one player to the other longer.

And you are still missing the point in the abstraction on how networks work. The path between two clients is not a straight line, but rather a series of nodes that suggest where such a destination could be found. A p2p model doesnt ensure reduced latency.

The point of the centralized server is (along other game logic mechanisms) to ensure an stable path to tranverse, as the path between two user computers could prove to be longer than it would to just go to the intermediary. Yes there is a theoretical latency perceived, but in practice a node with such a high traffic would often "look to reduce" (not a real thing in networking, but the need to reduce load at core distributors would indirectly lead to) the jumps between it and all of their targets, something not feasible to occur between two low traffic ones.

[Justin Meisse]

How about a single player RTS with a good story or interesting game mechanic?  That's the strength of indie developers, multiplayer RTS games are already cornered by the big players.  Pre-rendered sprites and no netcode would narrow the list down to just one very hard thing, AI. 

I'm an artist, not a programmer so I'm just assuming it's really difficult to do but is it beyond the abilities of a 2 person team?

I apologize for sticking my artist nose into a highly technical discussion!

[Alevice]

Pathfinding is still a thing.

[Dacke]

Realistically you'd probably need to reduce the complexity further.

There are just so many moving parts: unit selection, building selection, pathfinding, building, upgrades, different types of movements, minimap, unit types, etc. No single part is necessarily overly complex, but when a project grows it can become really difficult to keep it together. Additionally, the more complex mechanics you have the harder it will be to build a good AI.

A few examples of possible simplifications:
The units' only pathfinding is to follow straight lines (move from where you are to where the player points). This works well in settings with few obstacles, for example space. You can go even further and only allow movement between designated nodes. You could design a system where you don't have to construct buildings or one where you don't even manually have to produce units. You could make all units mostly identical and numerous enough that you needn't bother with complex unit selection.

There are games that have made these simplifications and created a new sort of RTS, for example Eufloria and Galcon. I personally didn't like them, but they show one way of reducing complexity in RTS games.

[RealityShifter]

Fire With Fire which will release in the next month or two could be categorized as an RTS. It's Player vs Player Tower Defense. I mean you build and you attack with troops. We do have a timer to limit how often you can attack the other player though.

Steam Page:
http://steamcommunity.com/sharedfiles/filedetails/?id=279128245

We have a 3 man team with virtually no budget what so ever :D

[Netsu]

And you are still missing the point in the abstraction on how networks work. The path between two clients is not a straight line, but rather a series of nodes that suggest where such a destination could be found. A p2p model doesnt ensure reduced latency.

The point of the centralized server is (along other game logic mechanisms) to ensure an stable path to tranverse, as the path between two user computers could prove to be longer than it would to just go to the intermediary. Yes there is a theoretical latency perceived, but in practice a node with such a high traffic would often "look to reduce" (not a real thing in networking, but the need to reduce load at core distributors would indirectly lead to) the jumps between it and all of their targets, something not feasible to occur between two low traffic ones.

Hm, I'm not sure if I get it. So a central model would work better if the central server is 'easier to find' than a client? And you can somehow control how easy it is to find you?

[Scifa]

Dune 2 was my first!

[starsrift]

So to sum up, NeomerArcana, there's a shitload of reasons why you don't see RTS indie games.

[Sik]

i thought p2p becomes problematic/laggy when you're not playing against someone geographically close to you? (or at least thats my experience with p2p games)

Not necessarily, e.g. a connection between somebody from Argentina and the US will have less lag than one from two people in Argentina, because the routes are traced in such a crappy way that it'll make a round trip all the way to the north hemisphere (this is a problem for all of South America, the infrastructure is that ridiculous).

Even then P2P has an even bigger issue, which is dealing with NAT in modems. Before you could just open a port, but now ISPs are insisting on giving modems where you don't have access to the settings at all and have to call the ISP to change them. This is so they can charge you more to do that. This also basically prevents any chance at hosting a netgame yourself, and punching a hole in the NAT isn't that reliable (especially if it's tied to both the IP and port).

[Alevice]

And you are still missing the point in the abstraction on how networks work. The path between two clients is not a straight line, but rather a series of nodes that suggest where such a destination could be found. A p2p model doesnt ensure reduced latency.

The point of the centralized server is (along other game logic mechanisms) to ensure an stable path to tranverse, as the path between two user computers could prove to be longer than it would to just go to the intermediary. Yes there is a theoretical latency perceived, but in practice a node with such a high traffic would often "look to reduce" (not a real thing in networking, but the need to reduce load at core distributors would indirectly lead to) the jumps between it and all of their targets, something not feasible to occur between two low traffic ones.

Hm, I'm not sure if I get it. So a central model would work better if the central server is 'easier to find' than a client? And you can somehow control how easy it is to find you?

Do you know how routing works?

edit: i kinda read this as sarcasm, which might not be the case. As sik also mentions, certain network infrastructures can make p2p even amongst geographical neighbors to be less efficient due to how routing works over a network. Ideally a connection between nodes would go to a path of least resistance, using the least hops to reach each other. In practice, ISPs may even travel further distances because of their carriers and stuff.

http://en.wikipedia.org/wiki/Routing

[pelle]

A few examples of possible simplifications:
The units' only pathfinding is to follow straight lines (move from where you are to where the player points). This works well in settings with few obstacles, for example space.

Close Combat, at least the first games in the series, did that. Of course units can move right through buildings in that game. Later games you can add waypoints for more control, and perhaps there is even blocking terrain (rivers?). There are minor obstacles like trees that soldiers have to move around, and also soldiers have to move around other soldiers, but the units (squads) are not blocked by trees other units because they are so sparse (made up of small individual soldiers that can easily dodge obstacles).

Ancient Art of War, the real-time strategy game that wasn't quite a rts like we know them know, had no path-finding at all, because when you ordered a unit to move you had to trace the exact path using arrow-keys on the keyboard (press M to move, then trace path, then M to complete, or C to cancel... IIRC). Worked much better than it might sound. Also you could have fun and order units to move around in crazy patrol patterns. Squads were allowed in the same exact location too, so no need to worry about them blocking each other, which makes sense at that scale with each icon on the map representing up to 14 soldiers. You could probably make something like that work very well with mouse or touch control.

You could design a system where you don't have to construct buildings or one where you don't even manually have to produce units.

You could argue that this makes the game RTT perhaps. Not that I think genre-names are that important.

Incidentally AAoW also does that. If you put a squad in a fort that has fewer than 14 soldiers in it it will slowly increase in size, adding random types of soldiers to the squad until it is full. No building, no settings for what to produce.

You could make all units mostly identical

This would work well for a historical rts, really. Historical rts tend to include lots of unit-types just to include lots of unit types, because it is good for marketing or something. Taking some inspiration from history, almost any era, you need just a very few types of units (maybe 3-5). Or you can zoom out a bit of course and just call them armies or something and give them a generic strength number seen when they move around the map. That would also cut down on the number of units to worry about and make everything simpler.

[FrankieSmileShow]

Man I remember playing an old, really simple RTS game where the four teams were different sets of bugs, with a different color.
One team had like a ladybug or maybe a pillbug with a machinegun on its shell. I remember that because that ladybug was super OP. The art was cute-ish-realistic I think. Not super sci fi.
It was completely top down, and really simple to play, but really fun.
I think there were no buildings to make, only bugs. You just had one base to protect, and like 4 different bug types to build to attack your 3 opponents.

I dont remember who made it, but it really looked like the kind of game an indie dev would do today.
Maybe if we can find that it could give some of y'all ideas....

Gaddam this is gonna really bother me. I remember it so faintly...what was that freakin game....
Im pretty sure the fighting arena was a backyard or something.
I think it was from the windows 98 days.