Network game.

[dalerank]

How did it??? Please post your ideas and opinions.

[Andrei Brănescu]

This is my idea. Brace yourselves, this is long. :)

For the multiplayer mode I imagined something really simple where all the mechanics of the game stay the same.

Description: Each player has its own map and occupies a location on the world map. The multiplayer map will be a world map and will contain one or more "single player maps" each with a certain position within the world map.

There could be alliances or free for all mode. Evidently there should be a trade system, but a lot more flexible than the existing one.

To attack another player, one sends he's army to the other town (this will just be a push of a button, the player's army will be seen leaving the city and then later reappearing in the other city). This will take some time depending on the distance between towns (I would say no more than 2 or 3 minutes). There should be warnings for the other player like the warnings about invasions.

After the armies arrive to the other city, the player that attacks will be able to switch between the view of his town and the view of the enemy's town.

Once the fight is over, if the attacker wins, he could stay and build a city. If he doesn't win, he cannot view the other town until the next time he attacks or if he has a scout present.

We should also have a fog of war. There should be a scout unit that could be temporarily sent to the other town to be able to view it.

The speed of the game will be the same for all players. The speed of the troops that move between towns should be proportional to the speed of the game.

There should also be events like in the single player mode: invasions from the neighboring tribes.

To allow the deployment of troops, a minimal distance between the walls and the edge of the map should be imposed. We could let the player construct other buildings outside of the walls, but obviously without walls they would be easily destroyed when the enemy comes.

Pros: - keep the game mechanics (maps, trade, etc.) - less drag on the CPU/RAM as there will be only one map shown at a time Cons: - having to limit the space between the walls and the edge of the map

Of course this proposition is for a muliplayer where human players fight each other. For other types of multiplayer, I'd have to think about it.

An interesting thing to notice is that if we take this approach we could combine Caesar, Zeus, Pharaoh and Emperor together in the same game. Maybe have all those civilizations fight each other? In multiplayer mode the player could potentially choose between one of the three civilizations: romans, greeks, egyptians or chinese.

[dalerank]

is network game more effectively as dedicated server, or part of single game???

[Andrei Brănescu]

I would say there's no need to implement a dedicated server. Usually, dedicated servers are implemented for games that have high resource demands or real-time constraints (like an FPS).

For our situation, the simplest thing would be if anyone could host a game on their machine and have the others connect to it by giving them the IP.

[dalerank]

ok, i understand

[Andrei Brănescu]

We should search for a library that can do this. Implementing it from scratch will probably take too long. I'll look around and see if I can find one.

[dalerank]

mb sdl_net + custom facade???

also i working with curl in updater (support windows, linux, haiku, macos)

[krs krs]

No network play was a big minus for the initial Caesar III. So this is a "must" for the remake.

Since this is a bigger task I would suggest to do it incrementally. Each increment should be fully playable by itself.

Step 0. Networking code. Allow more players to be placed on the same map.

Step 1. Trading - Game plays just like Single Player, but now players can trade between themselves.

Step 2. Battles - Allow players to send troops to another town, with no control! over them. They will fight on their own.

Step 3. Linked Immigration - Salaries and conditions will make people leave cities for neighbouring ones with better offers.

Step 4/5 Diplomacy - Allow tributes to be collected from other cities. Allow alliances.

Step 4/5 Battles Enhanced - Allow players to view and control troops in another players city.

Step 6. Bots - Replace Dropped Players with simple bots so that drops will not spoil the fun for others.

As for conquering I do not see what it does bring to the table. You will not go and play with a second city imo. So just erase that player from the map and put a ghost town (or a simple computer controlled one).

[dalerank]

Granted, the network game is quite a big step, so that the game has gained some independence.

1. Multiplayer - it's a big part of the self, for which I do not have a complete vision of how it will be resolved. You can create queries on specific tasks.
2. Probably the first step is not the path to the network location of the game will be one of two players on the city map mode enemies
3. Basic trade in the game is absent, what you see is only a simulation of trade and so it was in the original
4. Battles -. Allow players to send troops to another city, with no control over them. With this simple forces can be controlled and is controlled by the computer.
5. Immigration within the empire drags along some changed in the code, but it is already possible
6. Diplomacy - this step takes at least, if not more than a multiplayer game, the implementation until present
7. Tribute with other cities included in the diplomacy. Unions too. f
8. Battle Advanced - it conflicts with automatic battles, I do not know how to implement it
9. Bots - have a class that is responsible for the governance of cities of the empire.

[Cherry Soup]

Hm-m. I'll try to represent my point of view. (while writing it, i'm also playing last build on 10% speed)

Alert, even more text, than in first comment.

Placing two+ players on map. It'll be great and fun. BUT.

1. If there only one road, playing map will be nightmare. Implementing more than one road is very hard task. Required more complex search for new people. Which road has access to home, I'm want to inhabit? If there two roads, I can walk to, which one entry is nearest? In first view, that can be solved by searching road not from road start, but from home place. Same mechanics for traders and other guys. (I don't know, how they do it now, but I'm think they start to search from road begin)
2. Having buildings, that belongs to different players. That means, social workers must work only with "allied" structures. (Exactly "allied", because with diplomacy, there can be peace between players) You don't want your Prefects to cease fire on enemy city :) Can be solved by having a separated list of units/buildings to every player, with which workers must work.
3. Even for two players "big" random map are too small (i think).

Having an big-world-map. I have slightly different viewpoint.

1. Celled world-map. World map must be separated to small cells, where player can't build big city. He must expand his territory. But he can expand only to nearest cells.
2. Expanding. My view is really hard to realize. When player gains control over nearby cell, his map extends to this region. E.g. 50x50 maps becomes 100x50 map. But there is a problem of having unexpanded region in map. E.g. when player expands to new cell, he get 100x100 map, but 50x50 corner of it is not controlled by him, and he can't build on it. I think, "closed" cells must remain black or similiar "not available" view. This methods is hard in fact, that than more player expands, then more memory his make will take, and updating it every tick will become harder and harder. How expanding will work (e.g. how player takes control over a cell)? I dunno :D Let me think about it. In first opinion expanding is just simple "send an army/scout to this cell", and after they will scout area, player will get view of cell.
3. Expand overlapping. Okay, we dealed with one player. But what, if second player will try to expand on cell, that other player already owner? Replace controller? But if there are building of first player? So, only conclusion - just add controlling power on this cell.
4. Wars. More interesting, that players can't send an army to each other, when they want. They must expand and expand, to find, where the heck is other player. It's kinda fun. Even if you spawned near to each other, but dig into wrong direction "Oh god, he's been so close, and I didn't realized it!". With my view of world map, forposts will have a chance in tactics, if fog of war will be made.
5. Roads. Because of world-map, there must be many roads, connected into grid. Not every cell must have road. And this roads must be connected to world-border in many places.
6. Outsiders. I mean new inhabitants, traders, etc. They must not go "out of nowhere". Only from borders of world-map and cells, that nobody controlled and they have access to world-map borders. There a small trick. They not go from borders directly (at start it'll make players angry, why newcomers not come so longs), but from nearest not-explored by anybody cell. But what if trader go to Player A, and hist road goes through cell, that explored Player B, but not Player A? There the fun part. He start to walk on that zone, so Player B can brutally kill this merchant, and he'll never take his way to Player A. It's kinda imbalance, because Player B can just block road, and Player A never will get new inhabitants and other outsiders. So, in code, when a outsider killed on his way to target, you must record that, and if kill-rate becomes more than some magic-number, cell will take low priority on pathfinding (but by small random chance it will take normal priority, like some "brave outsiders don't fear dangerous way") (... there I stopped writing this, to write another bugreport ...).
7. Rome. There must be Rome, to whom both players must pay :) You dan't want an Caesar's army approaching you, when you almost all your forces doomed in last PvP battle. But his army must be loyal to players, that are pay. E.g. if army going through city of paying player, they will just go they way, and don't harm players.
8. (non-classic units and mechanics) Propaganda. Yes, yes, and yes. Units like spies will can inhabitate enemy city as simple civilian to grief the economy of enemy.. If he just unemployed, he's useless, but if he take job... As Prefect he'll increase flamin-chances, Engineer - faster building destruction. Priest? Angry Gods is fun. No harvest on farm for plenty years? You need to think, why. Et cetera, et cetera. And ofcourse anti-propaganda. Units like classic Prefects, but inspect in search of spies. There must be detect-chance, which increase over time, that spy work. "sleeping" spies are undetectable.

I can continue, but over 5000 symbols is already too much. :) Conclusion: I see less problems in realisation of "2 players on one map", than "big-world-map". But my view of "big-world-map" game are way complex and harder to realize, than one, that feautered Andrei B.

[victor sosa]

I agree with @Andrei B. in most of his ideas. Some minor changes to it. Let me tell you three ideas: always balance the game mechanics, think big MMOG and keep the logic simple so it can be implement.

• Dedicated server should be use, why: 1 Security, a custom server could (and will be) hack by owner to do cheating over others player and get advantage (already happening on other games) 2 Some place really simple, where all the mechanics of the game stay. You need to save the state of you game related to other. (I will talking about this problem later)

• One map wolrd idea doesn't works, it is just no simple. How do you allow more players to be placed on the same map? let said 1000 or 10000, or even just 50 :) geographic can't be applied. Here is were the beauty of a dedicated server start, you can have a number X of players with their cities (can be more than one, but you can play one at a time), there is no world map, just a list of players with city information. (You can fit 10000 players in a map even it is big map, you will end needing a dedicated server for it, so let's keep it simple)

• Maps: the server will have maps, and the user can select any or random (I prefer random, but anyway you like). Why this well a map with gold on it will be nice, but not balance if everyone have the same resources, resources are limited and should be for balance the economic to work. Different idea, could be that user can propose maps, just that they can't use that map and need approve from the team that keep the server. A well design map will not have all the resources to keep balance in the world (server), the server should have global variables like how many gold mines, iron mines, shoals, forest, etc has so it can be use for economic. It can be a map like a island with a lot of shoals but missing the rest of the resources. Or could be many irons mines (not all of them but many) and missing the rest of resources to balance (this is only to balance), because it could a map with all the resources but just one by resource.

• Diplomacy with alliances or free for all mode: if you have free for all in the beginning, and you start to make alliances with other cities (friends), if you didn't have diplomacy with a city you can't do alliances or attack. Why is this because if someone (old players) has already armies will not let the newbies grow up. (always think in balance game mechanics, rule number 1).

• The real modes: CONQUEST and TRADE: if you select to be in conquest then the military effect applied and TRADE is just for trade commerce, no military variable.

• In conquest mode: the winner, I will change one thing that Andrei said, the winner will NOT stay and build a city, you just can't build two cities at the same time :P sorry, just doesn't make same. What you can do if you win, as Winner as happened in reality is that the winner impose, Balance game of course, there will be a way so you can be free youself from the conquer just by paying a agreement, you will paid taxes to him or send you requests base on what you produce (wine, clay, iron, etc) or a request to share you troop with him (this is like an alliance by victory) the limit will be establish by the server (let said pay taxes to 10 years). The loser in the war will have his city, play as always but will have to accept the request from the conquer player or accept full surrender which will leave the city to be own by the conquer player, Now the city will be own by the conquest, as it was build by him.

• Alliances: well you only share by request you army and that's it. You can trade commerce with you alliances. The immigration and emigration will be affected by the alliances(more other things too), let said that someone has better wages that you should attract more people to his city.

• Good prices: well is managed by the cities in the server, base on simple economics rules: like price demand, cost, ect. on the feedback provided by the cities. so it could be a real economic world.

• Offline game: You need to save the state of you game related to other, right? so If you conquer some city, they will continue paying to you, if you are offline you will get you money, now you see why is important a dedicated server :), and no only that there is a lot of share info (economics, etc) that need to be live even if you are offline. Of course none one can create a new attack on you, no either you will trade with you while you are offline. Any incoming or out-coming trade or invasion will be save in you state, only if it was already post while you were online. :) nice right, No BOT needed.

CONS: Well it a dedicated server idea so it needs servers, you have to pay for, but it will be not be EXPENSIVE, now days there is a lot of clouds that can be very cheap and just will be the multiplayer platform, the rest will be keep free.

PS: "approach we could combine Caesar, Zeus, Pharaoh and Emperor together": you are no making sense, that's a crazy idea :).

Basicaly the rest of the Andrei's ideas all good. I love and share the Andrei ideas. -good ones.

@dalerank mb sdl_net + custom facade?? let see, it could be implement fast and simple. Then YEA

warning: miss spell words could be found :P

[dalerank]

need server logic for those ideas, transport is only 10% of necessary work. This work maybe larger then native game (

[victor sosa]

I can do the 90% of the work :P, besides I don't it needs to be complicated, the server will have some logic and most of the work will be keeping the object states.

I can help you developing the server side, while you do the client side code needed. I will also develop a web UI so the players can check the statistic of the world in the server, etc, etc.

[victor sosa]

We need to define the interface API first for every section like: battles, trade, diplomacy, etc. All this object that will be send and get from the API. So the develop in the client and server side can be don't without wait for a deadlock on development. If the client side know what it will receive or send them it could be finished with out the server side finished.

[victor sosa]

Notes and thoughts about the api, this is a initial thought about the necessary methods of the remote API. Any thing that I miss, just post and I will update this kind of initial doc.

Initially I am thinking on JSON as the object for this API, also mongodb could be the database for it. This keep the original config info in the native game as the interface for the server too. This API will be REST service on server side.

• Security: I haven't thought about it, because I need to check which technology will be used by the server side. But definitely will be some kind of login and auth in the server and the methods used.

• Accounts: need to check how to implements this connected to steam and the server.

• Map: api will implement all the necessary methods to manage a map, like register, open and close maps from the server by the player. Possible methods:

  • register - a player to a map in the world host by the server.
  • open - open a map, go online.
  • close - close a map, go offline.
  • update - update all the necessary info to the map while it is been play online for the player. It could be every 15 or 30 sec or min (or every month on game time)
  • read - read the map info. (this read could be for alliances exclusive read or just normal read)

• Diplomacy: api will implement all the necessary methods to manage a diplomacy. should execute before do trades or attacks. Possible methods:

  • open - open a diplomacy relationship. could be for attack or trade.
  • close - close a diplomacy relationship.

• Trade: api will implement all the necessary methods to manage a trade, diplomacy relationship only. The good price will be setup initial by the server and change based on the player maps development, a open trade will run as always in the game. Possible methods:

  • open - open a trade relationship. by sea or land. you send the good to be trade (buy and sell)
  • close - close a trade relationship.
  • goodPrices - get list of good prices. (get info from the world, no one set price)
  • request4Troops - request help of troops from a alliance city.
  • sendTroops - send the troops to a alliance city.

• Attack: api will implement all the necessary methods to manage a attack, diplomacy relationship only. Possible methods:

  • attack - attack one city, this is the easy one. Send the troops.
  • defend - defend my city, this is the hard one - (I am thinking in just post the result of the battle here)
  • acceptSurrender - only if you don't want to accept the tribute, then you lose the city too.

• Tribute: api will implement all the necessary methods to manage a tribute, diplomacy relationship only. This will reuse the same api in the Trade interface just with the obligation to do it for the player. more Possible methods:

  • GetTributes - get the tributes list info to be accomplish by the defeated player.
  • SelectTribute - Select one of the tribute in the list to be accomplish.
  • GetTribute - get the tribute info to be accomplish by the defeated player.
  • SendTribute - just send the tribute to the other player.

• Immigration: api will implement all the necessary methods to manage a immigration, diplomacy relationship only. I really need to think this more deeply. The immigration could be just be create as always just now affected by the other cities or could be origined from the world in the server which means a total population for everyone and the rest of calculation as always. Possible methods:

  • GetInmigration - It get immigrants from the world.
  • SendEmigration - It get all the citizen that leave you city to the world.

• Notifications engine: api will implement all the necessary methods for the client to recieve notification as: attacks, new trades accepted, diplomacy agreements, notice defeat, etc. and it will be presented to the player as always (popup notifications). Possible methods:

  • newTrade - notice about the new trade from a city.
  • newAttack - notice about the new attack.
    • newTribute - notice about the new tribute after be defeated.
    • victory - notice about the victory or defeat to the player.
  • incommingTribute - due notice about the new tribute to accomplish.
  • incommingImmigration - notice about the new immigration.
  • goodPrice - notice about the new good price change (rise up or down).
  • request4Troops - notice an alliance troops notification.
  • diplomacy - notice an alliance diplomacy notification.

• World engine: any, any statistic calculation economic or any other calc related to the world. All the global variables will be here, all the resources informations like gold mines, forest, etc. on the map in this worlds. So this methods go here. Engine information:

  • All maps info (map info, map status, rules as always)
  • Total raw resources (Mines, forest, shout, clay pits, etc)
  • Total manufacture resources (furniture, wine, olive oil, etc)
  • World population
  • User player account's

• Roadmap - network game expansion:

  • v0.1

    • World engine, map, diplomacy, notification engine and trade

  • v0.2

    • Patch fix

  • v0.5

    • Immigration

  • v0.6

        - Patch fix
    

  • v0.9

        - Attack, tribute
    

  • v1.0

    • Patch fix

• Notes:

• All the response and parameter will be JSON objects, too keep the native game definition as they are.

• I didn't post the parameters or response for this method because I am not aware about the game config info necessary for all of them. It is just no obvious for me.
• The notification system will be PUSH notification approach, which will send the notification from server to client. On every activity response like trade, attacks, Immigration, Tributes, etc.
• Ones this API is establish, it can't be changed to keep backtrack compatibility of the service, just add a new method v2 if it is necessary.
• One thing is about attacks: it should be automatic, so only the player defending could manage his troops, which keep the game as originally design. (For all you thinking on a two player match, it just can't be done now, in the next expand we can think on that)
• There will be one read info map that you get for all players maps info and same one read for alliances members only info, just check the parameters to return the approved data.

[victor sosa]

Seconds thoughts about the networking api, forget about the REST service on server side (this Idea will be implemented for the WEB api, which doesn't need performance), it will be better performance using the basic and simple sdl_net as Dalerank suggested.

There will be two components develop here so the Roadmap changes.

• Networking API - will be develop first and it will responsible for the client and server connection and package delivery.

• Remote API - this will be the actual api that was mentioned in the post before and will has all the methods mentioned and use the networking api to send the data.

• Roadmap - network game expansion:

  • v0.1 - Networking API

  • v0.2 - Remote API creation.

    • World engine, map, diplomacy, notification engine and trade.

  • v0.2.1

    • Patch fix

  • v0.3

    • Immigration

  • v0.3.1 - Patch fix

  • v0.4 - Attack, tribute

  • v0.4.1

    • Patch fix

    • v0.5 - Initial integration with game.

[victor sosa]

Thoughts about the Multiplayer game code refactory. For a multiplayer to be possible a refactory need to be done in the game(This is the part Dalerank doesn't like). I think most of the game have somekind of layer separation, right. Like where is the sound logic, graphics and the players view, etc.

But it isn't enough we need a clean layer separation in the game code, so we can add the manage of different players in the game at the same time. I think most of the code already have it, but some part need to be change and refactory, keeping the the code logic just moving the part to another place or how they are used or called.

This new place will be the new refactor for the game code, where everything should do something related to the layer functionality and responsibility. Ok let me explain the layer. There should be 3 layer so the game can support multiplayer, even AI or remote player will be consider a player in this new approach so that easy you can implement a new AI while keeping the old one.

3 Layers:

• Application layer (Platform layer) : deals with the hardware and operating system.
• Game logic: manage the game's world state and how it changes over time.
• Game view: presents the game state with graphics and sound to the user.

As you guest you can have as many game view as you need to represent any player in the game. Let me explain with a table the different responsibilities of every layer.

This Architecture is obvious and made simple to have a multiplayer game, all you need to do is attach more human views to the game logic. In this case the human view will be remote. As you can see all the communication between the server and client is just events. As in the 3 layers design the communication between the game logic and the game view is just events. No everything in the layers components are necessary like the 3D stuff, I just mention how should be organize and that it.

Side note: By this time the networking api is almost complete, it just need a minor refactory in the buffer inside the message class and some memory safe delete.

The first thing to be change is the event api, it need to be added all the necessary methods to work with the remote api, like getType() which return the event type and serialization functions, to do the transformation before it can be send in the network.

After that we can work on the remote api, which will be all the necessary events to be implemented for the multiplayer communication between the client and server.

Until now the game still running as always, what you need now is the refactory so it can support the multiplayer in the code and for that you need the 3 layers separations. By now everything is OK, now mess with the old code, a new GameView API need to be created(so nothing changes until now the old code just can run as always), which will have infamous player_id which will be used in every event generated. What is player_id, no idea my friend could be anything unique. After this all code is new, nothing was changed in the old code, just the Events API was changed, which can work ok for the old code.

By now the fun start here, the new Game View needs a new GameLogic, so you can keep the old code and do a parallel code or just throw away the old code. The first option is the best because allow you to keep tracking all the patches happening in the old code and can be easily be move to the new.

Something need to be clear the Game Logic in the client is different from the one in the server, so it will be two GameLogic engine.

So let have almost the new multiplayer game done XD, step by step can be done. Yes.

any suggestions???

[victor sosa]

Good new!!! the networking api is completed and integrated to send any event in the game from the client to server and back. Now the next step will be create all the events necessary to the communication between the server and the client. This is called remote api in the doc. the list to be create is above.

Something to note is that the Event api didn't change at all, so in the end it didn't need to be changed, all the necessary methods where there ready to be use. After this we can start thinking about the multiplayer api to be implemented.