Help us develop the most detailed multiplayer civilization-like game imaginable

The Game Room
21

Thoughts:

1 - As described, the game will definitely reward people who log in obsessively every 3-4 hours, as they’ll be able to squeeze out a little bit extra maneuverability out of their troops, efficiency in resource-usage (starting to build your (whatever) just as soon as the resources roll in rather than up to 18 hours later, etc.) and so on. Don’t know if this is a feature or a flaw.

2 - What’s the imagined starting and ending point of the game? Once you get 20 people (or whatever) they spin off into their own “instanced” world, which then runs until someone fulfills the victory conditions?

3 - What happens with zombie players - guys who log on, play a couple turns, then just ditch the game? I’d say you should definitely not have too high a reward for capturing someone’s capital city (or whatever) as otherwise an empire that happens to be plunked in the midst of a group of zombies might secure an unfair advantage.

22

this sounds an awful lot like a more complex version of a game I play called Travian. (www.travian.com)

You probably want to look into that game and maybe play a bit (on a speed server) to see what works and doesn’t work. I’ve actually kind of gotten bored of it and am just waiting for the end of the game (should be in the next couple months for my server.)

It also has a feature like your time units, where every action takes a certain amount of real time. So if I want to build 100 troops, it might take 10 minutes per troop, so I’ll have my army ready in 17 hours when I log in again. And building a building takes a certain amount of time, and you can only build one building per village at a time. So theoretically, you can kick off all your builds and walk away for a while.

But the trouble with that, and the thing that really turns me off is that every action takes a different amount of time, so to be most efficient at the game, as Tom Scud said, you want to be right there waiting when something completes to kick off the next thing to avoid wasting precious time. This problem gets complicated by the fact that there are different “time resources” that can be used at the same time.

Workers building buildings (one building at a time per village)
Barracks building infantry troops (one troop per barracks, but you can queue them)
Stables building cavalry troops (one troop per stable, but you can queue them)
Workshops building seige engine troops (one troop per workshop, but you can queue them)
Armories upgrading armor (one upgrade per armory)
Blacksmiths upgrading offense (one upgrade per blacksmith)
Town Halls hold celebrations to build “culture points” for village expansion (one celebration per town hall)
Merchants moving resources (up to 20 merchants per village, with varying travel times)

So you can see that with all that going on, once you’ve built up to a certain level, there’s something happening ALL THE TIME in one village or another. So you can easily just get sucked in and sit juggling all day. And if you don’t, you won’t succeed.

IMHO, a lot of that problem could be solved by semi-intelligent queuing of actions. If I could say “this village, keep improving up your barracks until it maxes out, then work on your iron mines. Stop if you run out of resources and wait. cancel the whole thing if I tell you to.” and “in this other village, just keep cranking out phalanxes until I say stop”.
Another feature that would help would be “Banking time” in the sense that if my workers finish a building at 12:30 and I log in at 1:30, there’s 1 hour of wasted time “in the bank”, so if I want to build a building using time “in the bank”, it takes no real time at all. Exactly as if I had logged in at 1:30. So any time a worker or barracks or town hall or ANYTHING was idle, it should be banking time that can be used later.

This would go a long way to making Travian a strategy game, and not a “log in all the time to succeed” game.

23

This game could be killed by requiring too much micromanagement.

I’d suggest, instead of hordes of individual troops moving around the map, consolidating units into “armies” or cities/fortresses/etc. An army (perhaps led by “command” units of varying capacity?) could be given a certain zone of control even when it’s idle, but would be vulnerable to attacks on its line of supply. Units based in a city would have the same zone of control, wouldn’t be as vulnerable in terms of supply, but would have the drawback of reducing populace morale and production in the settlement. A fortress would have all the benefits of a city, but without the morale reduction… it would have to be more expensive to compensate.

24

I fear I have my own project to work on (plus I’m big on making a profit :stuck_out_tongue: ) but I’d like to know if you guys have tested Darkstar much? I looked at it but decided to port the Torque Network Library to Java instead, since it’s been used in production games. I haven’t started work on that segment yet though so I could still make the switch. (So far I’ve been focusing on the JOGL side of things and getting everything I need to do good 3D.)

25

Not necesarily, since one your units are out of TUs they can not do anything, there would not be too much use in logging every 3-4 hours if your units hace gained a couple TUs since your last login, as for building units and stuff you can queue that and they will be built until the resources ran out and start building again when more resources arrive, there’ll anyway be no doubt a benefit for obsessive players but that’s inevitable and true for most games.

As i see you’ll start with a couple of units and play until you are bored :slight_smile:

technology will advance indefinitely, we can add new technological advances into the game when they run out.

off course, at some point players will lose interest, and then the “world” can be reset or something.

since all players will start with only a couple of units there should be no problem, also there will be no rewards for anything, you got what you conquer, are given or buy, exactly as in the real world, one of our basic concepts is using the minimum amount of rules and “game” interferences, there will not be defined Government Types, no game run economy, etc.

Instead the players themselves will organize their nations as they see fit, and this touches in another concept, there will also not be defined “empires”.

Each player controls units, buildings, and cities, but not “empires”, nations will be a purely player managed concept, for example:

Players A, B, C and D are in the same geographical area, after some initial clashes and trade, it starts to be clear that A likes the military side of things, B loves administering cities, C likes everything but trade, and D has a commercial emporium.

So they form the ABCD nation, A takes care of the military, B runs the cities, C is elected overall ruler and they make an agreement to elect an overal ruller each month, D runs the economy.

As time passes more players appear in the area, some are hired by A to manage military units, he gives them say 3 units each and they help him with that, some start their own commercial enterprises, some work for D, some administer cities for B.

Then one fine day Commander E the trusted subordinate of A, decides that he no longer wants to be a subordinate, trusted or not, and orders his troops to take all cities, civil war (and penis) ensues, and the game goes on…

26

I see your point, and i like the “Banking time” concept, it could be usefull if not overdone (no more than a couple hours of banking allowed and only for buildings, not for units).

Queuing is already a game concept, also as multiple players can be part of the same empire/emporium/corporation there will no need to manage extremely large amounts of units/installations and cities.

27

We have tested it but only a bit, from what i see in their site it has been used in a number of projects, some of them commercial IIRC.

does the TNL manage concurrency, load balancing, persistence and transactions? we choosed darkstar because it promises to manage all that for us (and server/client communications too), leaving us free to work only on the game logic.

28

Excellent point.

That’s the second reason why other games avoid adding detail, the risk of excessive micromanagement, however this game reason d’etre is precisely that, detail, detail, detail, no heavy handed game rules to avoid micromanagement.

How then, avoid boring the players to death once the number of units/installations/cities grows too much?.

Delegation of tasks.

The game will have an Owner/Controller concept, it’ll work somewhat like a feudal system, ie:

you started playing a year ago, so you have lots and lots of things that you “Own”, however you have given “Control” of lots of them to players that started later, in that way you are not swamped by micromanagement and they can start with more units and stuff than the couple default units every player gets when he signs in.

Naturally the loyalty (another game concept :slight_smile: ) of units and cities will slowly transfer to their actual controller, so you’ll have to be on the look up for coups attempts, hostile takeovers, revolutions, civil wars and all those things that make history so much fun. :slight_smile:

29

Yes.
I think it has tools to allow one to do so.
Not sure.
Yes.

I think the main think it might have over Darkstar is in allowing you to choose how the data needs to be sent. I.e. does it have to arrive? Does it need to arrive in order? Etc. But perhaps Darkstar has all of that.

It also has some security measures added in to prevent DOS attacks and such. Again, perhaps Darkstar has that.

And of course Darkstar doesn’t need to be ported at all. I might end up giving it a much stronger eyeballing if it has indeed been used. I thought it was in Alpha or Beta stage from looking at its website.

30

i’ve checked the website again and, while there are some commercial projects in development, there’s still none in production.

Current darkstar version is 0.9.7, so i think it’s still in beta, but about to go gold.
As for the way the data get’s sent i think there is nothing like that, you just send and receive byte arrays, but i could be mistaken.

As for DOS attacks and the like, i searched the Dstar forums and did not found anything, so i have just started a thread asking about that.
Anyway, couldnt DOS attacks be managed at the Operating System level instead?.

31

If there’s a single (useful) action that can be taken for 1 TU, it will benefit the obsessives to log in as soon as each unit accrues 1 TU and micromanage them immediately. Even if it takes several TU’s to do something, the obsessive who logs in as soon as he has the needed TU’s will get what he wants sooner than the player who logs in once a day. And in a resource gathering civ-like game, the rich get richer, so getting what you want sooner gets you more stuff sooner, and makes you more powerful.
This is not necessarily a flaw. There are enough obsessive players out there that you could probably have a fine player base even while alienating the casual players. Og knows there are plenty of games out there that thrive with that issue, including the aforementioned Travian. The banking idea may help alleviate the issue, but probably not completely. (you could conceivably have a “casual server” where you are only allowed to log in once a day, and give one batch of orders a day. Then you’re getting closer to a turn-based game, and not a real-time one, though)

Will each player accrue TU’s? or will each unit accrue TU’s? The former would help with the micromanagement issue, but the latter is probably more fitting for your goal of realism.

You may want to at least provide some infrastructure for managing nations. Travian has “alliances” that you can join (I don’t mean to keep bringing up Travian as an example, but it’s the closest game I’ve played to your concept. I don’t think it’s a shining beacon to aspire to, but rather a flawed but decent attempt that could be learned from and improved upon.) When you’re in an alliance, you can see a little bit more info about the players in your alliance than normal (namely, their most recent log in time). And the leader of the alliance can send mass messages to the whole alliance. Personally, I think it would be better if ANYONE could send a mass message to the whole alliance, so that may be something worth including, but would require some nation concept to be built into the game.

Having the alliance concept as a built-in part of the game has another key benefit: it publicizes the nature of the relationship to other players. In your example, another militaristic player might see D as easy pickings because he doesn’t know that D is under the military protection of A. A himself won’t be attacked much, but he’ll be constantly fending off attacks on D (and B and C). If there’s a way to mark A,B,C & D as part of the ABCD nation, other players will know what they are getting into when they attack any one of them.

32

Interaction between online and offline players is the non-trivial bit that will make or break this game. The asynchronous multi-player thing is fairly annoying in my experience, but I thin that’s just because it’s so hard to get right… I like Rapier42’s “time bank” idea as it basically allows a bit of a real-time aspect to asynchronous play. It sounds like the “time unit” idea hits most of the high points of that plan.

Do I end up with a defensive unit that hasn’t been moved or attacked for days siting there with 100TU while I have a scout I can use 1TU every time I log in? Actually that might be an interesting way to encourage users to have to rotate the troops on the front lines. Pull up fresh troops with a reserve of TU and rotate the old troops to the back to recover.

It might be interesting to have interactions where all players involved are online behave like RTS, but if you encounter someone that’s offline it’s turn-based.

33

So if the game is a couple months into session and I start in as a newbie, I get plunked down at a random point in the map with a half-dozen Stone Age tribesmen when all of the leading nations (or whatever) are already in the Renaissance? How in the world do I not get wiped out immediately, unless I’m off-line friends with someone who has a powerful nation already?

(It’s not the same as a noob in World of Warcraft coming in at level 1 when there are hundreds of level 70+ guys around, because WoW players are not in direct competition for resources et cetera.)

34

Not exactly.

Once the game server has a couple of months, you’ll still have the possibility of starting from zero, but you could also try to get “hired” (by asking in the game forums, or any other means we can think of) by any other player who has some units/installations/cities he would like to let you control (to avoid excesive micromanagement), while he maintains ownership of them, in time you can get your own stuff or steal them from the original player

We could also devise some way to give late starting players some “base tech level” or some thing like that, but that’s something that should be tested extensively cuz the possibilities for abuse are huge (creating new accounts to get more tech and things like that)

35

While there will be some usefull actions that can be done with a few TUs they’ll be in the order of “Move one tile to the right”.

So, lets assume this configuration:

[ul]
[li]The max TU per unit is 24 [/li][li]The rate of recovery is 1 TU per hour[/li][li]Moving one tile costs 1 TUs[/li][/ul]

With those settings you can log on once an hour and move your unit one tile, or log on once a day and move your unit 24 tiles.
Obviously the player that logs on each hour will be more responsive to events, but the player that logs on once a day we’ll not be much worse, just a bit.

We plan to make those settings completely configurable, so we can tweak them on play testing until we have the best possible combinations, and, as you said, multiple servers can be setup with different settings for different types of player.

Per unit, as you say, its more realistic.

You are right about that, they we are planning to manage that issue is off course to allow purely informative “Alliances” (so you can know who has B’s back before attacking him), but also something i call “Permissions Set”.

Since the game will have a whole Permissions subsystem (that you can use to give other players permission to move through tiles ocuppied by your units, take n resources from your depots, etc) i think that it could be usefull to allow the players to create defined sets of permissions and give them to each member of an alliance, roles could also be created within those permissions sets to allow some players more permissions (if, for example, they are the ruler of the alliance).

36

I agree with what you say (except for the RTS part, but that could be a good idea for a Branch Project, once the basic game its done).

I think the basic TU model (with the useful adittion of Rapier42’s Time Banking) should be enough to make it work, fine tweaking can be done once we have a working prototype to find the exact best combination.

37

Actually, the time banking was my idea. (I don’t really want credit or anything, just clearing it up.) But I’m not sure how it applies under your system.

Do actions in your system take any amount of real time? Or, if I have 24 TUs, can I instantly move 24 squares? If it’s the latter case, the TUs already are a form of the time banking. Essentially, while you are away from the computer, TUs are accumulating in the bank, and then you expend them when you get back, instantly.

So if I log in at 1:00, and have 8TUs on a unit, I move it 8squares, and log out. I come back at 11:00, and have 10TUs ready to spend. The time from completing the last action to logging in again is saved as TUs.

That’s different than Travian, where each action takes some amount of real time. In that situation, it looks more like this:

I log in at 1:00, and move a unit 8 squares, and log out. It takes 8 hours for the unit to move to that position, and it gets there at 9:00. I come back at 11:00, and have wasted 2 hours. The time from completing the last action to logging in again is lost. If the time bank were added to this system, those 2 hours would be sitting on the unit (call them TUs if you like) and I could immediately move the unit 2 more squares.

So in brief, if I’m understanding TU’s right, they are the same as my “time bank” except you’ve put a cap on them at 24 hours.

Now, you’ve mitigated the obsessive login issue a bit, but not completely. For example:

What if I have a resource harvester unit in my home base, and a resource mine of some sort 6 squares away from home base. Assume the harvester can carry one chunk of resources, which is enough resource to build 1 unit. At midnight Monday, the harvester has 0 TU. At Noon, it has 12TU, at midnight Tuesday, it will have 24TU.

Player A logs in at midnight Tuesday, spends 24TU on two round trips to the mine, and gets 2 resource chunks. He spends those resources one two more harvesters, for a total of 3 harvesters, with 0TU each.

Player B logs in at noon Monday, spends 12TU on a round trip to the mine, gets 1 resource chunk, and uses it to build another harvester. At midnight Tuesday, each harvester has 12TU. He sends both of them to the mine, getting 2 resource chunks. Then makes 2 new harvesters. Total: 4 harvesters with 0TU each.

Clearly player B gets ahead.

I can think of only one way off the top of my head to mitigate the issue even more, and it’s awfully hairy and confusing: Each unit could keep its own clock, and know exactly when it is in time. And when you log in, you can take actions that bring all your units up to the present time, in whatever order you like. Sort of a revisionist history of “what I would’ve done if I were logged in.”

In this scenario, Player A above logs in at midnight tuesday, sees 1 harvester with 24TU whose clock says “midnight monday.” He spends 12TU on a round trip to the mine, which sets the unit’s clock to “noon monday,” and leaves it with 12TU He gets 1 resource chunk at his base marked “noon monday”, and uses it to build another harvester. The new harvester’s clock is also marked “noon monday,” which gives it an immediate 12TU to spend. He sends both harvesters to the mine, getting 2 resource chunks, spending all their TU, and setting their clocks to the present, midnight Tuesday. Then he makes 2 new harvesters. Total: 4 harvesters with 0TU each, all marked with the present time. Just like he would’ve had if he logged in at noon like B did.

With all his units in the present, A can log off and go to sleep happy. :slight_smile:
This would likely be a real pain to implement, but I’d play it.

38

long story short for the above examples:

If I’m understanding TU’s correctly, and they can be spent instantly, there’s no lost time with existing units, but when you are building units, you miss out on accruing TU on them if you don’t log in immediately to build them ASAP when the resources are available.

39

Yes you understand correctly, movement is instantaneous (until the unit runs out of TUs), the TU is IMHO an excellent idea (i stole it shamelessly from a web based game called Space Conflict) because it allows you to move your units like you do in civilization, while at the same time avoiding the turn based system that would kill an MMOSG, i played games that worked like Travian and hated sending troops and having to wait for them to reach their destination.

Sorry about the misquoting on the Time bank idea :).

About the unit building issue, i think i have found a solution for that, it works like this:

Your buildings have an standing queue of units to build, they do so taking the appropiate time for each, until they ran out of resources, whenever they get more reosources, they start building the units again, even if you are not logged in.

That. combined with a limited time banking for buildings (that do not use TU) should have the effect of giving “obsessive login” players not very much of and advantage over others.

40

Now that i think of it this does not completely solve the issue, since the new units will not be harvesting resources, we’ll have to look at it more closely, but i think it that, since your new units will be accruing time units from the start the problem is alleviated.