Conversation with #freelords at Tue 29 Jan 2013 08:24:44 AM CET on ulf82@irc.freenode.net (irc)

(08:24:49 AM) ulf82: Morning
(08:24:55 AM) Kez_: hi
(08:25:24 AM) ulf82: let me just open the kanban board and such...
(08:26:57 AM) ulf82: ok
(08:27:52 AM) ulf82: So the natural next step in the task would be to tell the player what tiles there are on the map.
(08:28:02 AM) Kez_: yep
(08:28:03 AM) ulf82: Unless you have other questions first. :)
(08:28:13 AM) Kez_: no not really :)
(08:28:23 AM) ulf82: ok.
(08:28:38 AM) ulf82: Do you want to try to explain how this would be done?
(08:28:56 AM) Kez_: yeah, I can try
(08:29:19 AM) Kez_: so it'd be another service that responds to the Request Scenario command
(08:29:27 AM) ulf82: yes
(08:29:52 AM) Kez_: and we want to send each tile in a seperate update?
(08:30:19 AM) ulf82: It might be more efficient to combine them, I guess.
(08:30:40 AM) ulf82: Although the overhead should not be too terrible (factor of two or so)
(08:31:10 AM) ulf82: But then, giving a list to the update instead of a single instance is not too much of a hassle as well.
(08:31:18 AM) ulf82: your choice
(08:32:00 AM) Kez_: I'd probably choose a list in one update
(08:32:47 AM) ulf82: ok
(08:33:17 AM) ulf82: well.
(08:33:45 AM) ulf82: I am scratching my head and cannot really find anything more to discuss except the class names.
(08:34:18 AM) ulf82: So maybe you could summarize it already in an item by item way.
(08:34:33 AM) Kez_: what about things that are on the tiles?
(08:34:48 AM) Kez_: or are they being sent seperately?
(08:34:53 AM) ulf82: I would handle them in separate services, yes.
(08:34:57 AM) Kez_: yeah ok
(08:35:37 AM) ulf82: eventually, we will probably combine some of the code when we come to the game itself and have to update the player on the map.
(08:36:21 AM) ulf82: because he sometimes needs to be told about new entities (if he can see them)
(08:36:34 AM) ulf82: mmh., this will probably have to wait until fog of war comes in.
(08:36:37 AM) ulf82: anyway.
(08:36:40 AM) Kez_: yeah
(08:36:56 AM) ulf82: any other issues?
(08:37:07 AM) Kez_: don't think so
(08:37:22 AM) ulf82: ok, then let's go for a summary of what to do.
(08:37:56 AM) Kez_: 1. Create a server service that responds to RequestScenario command
(08:38:10 AM) ulf82: name?
(08:38:45 AM) Kez_: ServerRequestMapTilesService?
(08:39:12 AM) ulf82: Request sounds as if the player actually wanted it.
(08:39:37 AM) ulf82: maybe to be more in line with the player service, a ServerMapTileDataService?
(08:39:44 AM) Kez_: yeah ok
(08:39:48 AM) ulf82: ok
(08:40:39 AM) Kez_: but the ServerRequestEmptyScenarioService should have request in its name?
(08:41:17 AM) ulf82: It could actually be renamed as well, yes.
(08:41:37 AM) Kez_: more like ServerEmptyScenarioDataService?
(08:41:45 AM) ulf82: Yes.
(08:41:49 AM) Kez_: ok
(08:42:30 AM) Kez_: so create a ServerMapTileDataService, that responds to a RequestScenarioCommand
(08:42:51 AM) Kez_: the service takes the current Scenario in its constructor
(08:42:51 AM) ulf82: yes.
(08:43:33 AM) Kez_: and assembles a MapTileDataUpdate to send back to the client requesting it
(08:43:58 AM) ulf82: Do you spot anything that could possibly go wrong here?
(08:44:28 AM) Kez_: no
(08:44:37 AM) ulf82: good. Me neither.
(08:44:47 AM) Kez_: ok :)
(08:45:14 AM) ulf82: Now how does the MapTileDataUpdate look like and behave?
(08:45:18 AM) Kez_: the update has only a list of MapTiles in it
(08:45:29 AM) Kez_: which is passed in via the constructor
(08:46:01 AM) Kez_: and should contain copies of all the maptiles in the scenario, without any objects on them
(08:46:13 AM) Kez_: so only the position and tiletype should be copied
(08:46:22 AM) ulf82: Let's see here for a second...
(08:46:59 AM) ulf82: A map tile basically consists of:
(08:47:02 AM) ulf82: 1. A position
(08:47:16 AM) ulf82: 2. A tile type name, mappable on a tile type
(08:47:26 AM) ulf82: 3. Things located on it.
(08:47:41 AM) ulf82: sorry, did not look at your last line.
(08:48:02 AM) ulf82: So the update would only store the positions and the tile names.
(08:48:29 AM) ulf82: (I would suggest tile names instead of the tiles because this is guaranteed to break immediately if the client side map is somehow corrupted)
(08:48:43 AM) ulf82: tile types
(08:49:18 AM) ulf82: i.e., tile names instead of the tile types.
(08:49:45 AM) Kez_: yeah ok, so send a list of <Position, tileName> pairs?
(08:50:20 AM) ulf82: that would seem natural, yes.
(08:50:36 AM) Kez_: so the client would then have to build them into MapTiles
(08:50:47 AM) Kez_: as opposed to us sending 'blank' MapTiles, as it were
(08:51:06 AM) ulf82: yes.
(08:51:09 AM) Kez_: ok
(08:51:17 AM) ulf82: less room for errors.
(08:52:08 AM) ulf82: and a bit less bandwidth (and the client should be rather bored anyway cpu wise)
(08:52:39 AM) Kez_: yeah
(08:52:41 AM) ulf82: ok. Do you want to write up the task?
(08:52:51 AM) Kez_: sure
(08:53:03 AM) ulf82: ok, post when you are done.
(08:53:35 AM) Kez_: for the pairs, should that be a new class such as MapTileData or somesuch?
(08:53:47 AM) ulf82: you could just send a map.
(08:53:53 AM) Kez_: yeah ok
(09:00:22 AM) Kez_: it's up
(09:00:52 AM) ulf82: ok
(09:00:57 AM) ulf82: looks straight-forward.
(09:01:16 AM) ulf82: Then we can actually come to the more interesting part: Sending the entities on the map tiles.
(09:02:13 AM) ulf82: In principle this is also straight-forward, though there is one complication.
(09:02:30 AM) ulf82: If the entity belongs to another player, only a stub should be sent.
(09:02:44 AM) ulf82: i.e., you have to do again some blanking.
(09:02:48 AM) Kez_: yeah
(09:03:25 AM) ulf82: The question is how to implement it.
(09:03:34 AM) ulf82: Maybe we define it from the user's perspective.
(09:03:54 AM) ulf82: I see right now three types of entities.
(09:04:26 AM) ulf82: Ruins, Temples, Villages are basic buildings with not much internal structure, though this may change
(09:04:56 AM) ulf82: Cities have internal structure (army building capabilities) that should be removed.
(09:05:10 AM) ulf82: and other structure (villages linked to them) that should not...
(09:06:03 AM) ulf82: Armies are more difficult. Their units have internal stats, and heroes can even have items that you do not want to show the outside world.
(09:06:25 AM) ulf82: Ok.
(09:06:54 AM) ulf82: Now we need to have a blanking scheme that, most importantly, you do not accidentally forget to update.
(09:07:26 AM) ulf82: if, say a ruin gets an inhabitant that should not be shown.
(09:08:10 AM) ulf82: Intuitively, we could try to add some function for that to a MapEntity
(09:09:28 AM) ulf82: I am done.
(09:09:43 AM) ulf82: So, maybe as a first step, we could implement the blanking.
(09:10:08 AM) ulf82: ping
(09:10:16 AM) Kez_: yeah ok
(09:10:51 AM) ulf82: I just noticed that I may have thought too complicated, so maybe this rant was not too informative.
(09:10:53 AM) ulf82: Anyway.
(09:11:08 AM) ulf82: We could do this in one go.
(09:11:16 AM) ulf82: or in steps, what do you prefer?
(09:12:01 AM) Kez_: Well there is only City and Army to do it for so one go could be ok
(09:12:06 AM) ulf82: ok.
(09:12:17 AM) Kez_: (and maybe Unit, depending on how we do Army...)
(09:12:25 AM) ulf82: Then the MapEntity gets a blanking function.
(09:12:38 AM) ulf82: Yes, that was the main thing that this propagates a bit.
(09:12:54 AM) ulf82: and it needs to be implemented by all implementations.
(09:13:19 AM) ulf82: So, let's list them:
(09:13:24 AM) ulf82: - Village
(09:13:29 AM) ulf82: what to blank there?
(09:13:46 AM) Kez_: do you want to blank the income?
(09:13:53 AM) ulf82: yes, I think so.
(09:14:05 AM) ulf82: the other players do not need to know that.
(09:14:35 AM) ulf82: that seems to be it.
(09:14:38 AM) Kez_: then I think that would be all
(09:14:48 AM) ulf82: ok
(09:14:52 AM) ulf82: - City
(09:15:13 AM) Kez_: doesn't seem to have anything other than the village list
(09:15:18 AM) ulf82: Right now it does not seem to have any private data whatsoever.
(09:15:19 AM) ulf82: yes.
(09:15:23 AM) ulf82: so nothing to do.
(09:15:26 AM) ulf82: Then Army
(09:16:41 AM) Kez_: do you want to replace each unit with a blank version?
(09:16:49 AM) ulf82: That would be the clean way.
(09:17:04 AM) ulf82: We could add a blanking function to units as well.
(09:17:25 AM) ulf82: so that the army does not need to distinguish between details like unit vs. hero.
(09:17:37 AM) Kez_: yeah ok
(09:17:51 AM) ulf82: Now how should a blanked unit look like?
(09:18:22 AM) Kez_: I'm not sure what data you'd want visible
(09:18:32 AM) ulf82: yes.
(09:18:56 AM) ulf82: So what data would you like to make visible to another player...
(09:20:03 AM) ulf82: One second, need to look up how modifiers were set.
(09:21:03 AM) ulf82: Ok. At least for now, a unit contains only data that is static for a given unit type.
(09:21:14 AM) ulf82: so we would not need to blank anything.
(09:21:20 AM) Kez_: ok
(09:21:23 AM) ulf82: at least in the basic unit.
(09:21:39 AM) ulf82: The hero as derived class should remove all its items.
(09:22:47 AM) ulf82: well, I am not sure if it will survive the movement code design, but for normal units, we could set movement points to zero.
(09:22:55 AM) ulf82: That should be it.
(09:23:21 AM) ulf82: Or do you see further things?
(09:23:30 AM) Kez_: no
(09:23:45 AM) ulf82: Ok, then let me quickly summarize.
(09:24:06 AM) ulf82: 1. Add a function getBlankedUnit() to Unit
(09:24:16 AM) ulf82: This name ok? or better suggestions?
(09:24:22 AM) Kez_: seems fine
(09:24:44 AM) ulf82: It should return a functionally identical unit with all private data removed (i.e., what other players see of the unit)
(09:25:01 AM) ulf82: - for Unit, this sets the number of movement points to zero
(09:25:28 AM) ulf82: - for Hero, this gives the new Hero a fresh backpack and equipment, i.e., removes all items
(09:25:58 AM) ulf82: 2. Add a function getBlankedEntity to MapEntity which returns a public variant of the entity.
(09:26:13 AM) ulf82: - Army creates a new army and populates it with blanked units.
(09:26:26 AM) ulf82: - City just makes a copy
(09:26:32 AM) ulf82: - Village removes the income
(09:26:51 AM) ulf82: That should be it.
(09:27:22 AM) Kez_: should that be an abstract function in mapEntity?
(09:27:36 AM) Kez_: then should MapEntity be abstract?
(09:27:37 AM) ulf82: yes
(09:28:29 AM) ulf82: other things that need to be discussed?
(09:28:38 AM) Kez_: i think that's it
(09:29:31 AM) ulf82: ok.
(09:29:37 AM) ulf82: Then I would write up the task briefly
(09:29:43 AM) Kez_: ok
(09:32:01 AM) ulf82: done.
(09:32:56 AM) Kez_: ok
(09:33:11 AM) ulf82: then I hope you have something to do over the week. :)
(09:33:28 AM) Kez_: looks like it :)
(09:34:08 AM) ulf82: Ok.
(09:34:17 AM) ulf82: Then I would have a brief breakfast and go to work.
(09:34:24 AM) Kez_: bye
(09:34:29 AM) ulf82: bye.
(09:34:34 AM) ulf82: have a good week.
(09:35:00 AM) Kez_: you too.
(09:35:23 AM) ulf82: I will just briefly write up the summary for the list.
(09:35:31 AM) ulf82: but anyway, yes bye.