Conversation with #freelords at Sun Oct 28 17:55:14 2012 on ulf82@irc.freenode.net (irc)

(18:00:50) Renn [~ShellingF@93-139-30-245.adsl.net.t-com.hr] entered the room.
(18:00:52) Renn: hey
(18:00:57) ulf82: hi
(18:01:17) ulf82: give me one minute
(18:01:25) ulf82: how was the race?
(18:02:16) ulf82: ping
(18:02:46) Renn: it was ok
(18:03:03) ulf82: sounds like "nothing spectacular"
(18:03:04) Renn: would have been more interesting if vettel hadn't won, but its still ok
(18:03:08) ulf82: ok.
(18:03:11) Renn: ye, for me it wasn't xD
(18:03:18) ulf82: done.
(18:03:34) Renn: did you find time to relax over the weekend?:)
(18:03:42) ulf82: yes, I played for most of the time.
(18:03:46) ulf82: That should count as relaxing.
(18:04:36) Renn: hehe, good
(18:04:39) ulf82: Next week will be pretty busy again, but then I have parental leave, yeah.
(18:05:05) Renn: aha
(18:05:07) ulf82: anyway
(18:05:21) ulf82: last time we finished with the idea of having no fixed terrain types.
(18:05:30) Renn: yes
(18:05:56) ulf82: So before we continue with the map generators, we should probably get this polished.
(18:06:38) ulf82: Let's start with a simple question: How do we in practice define the terrain types?
(18:06:56) ulf82: So imagine some scenario wants to use desert-like terrain, how is this specified?
(18:07:10) Renn: for now, it should have name, MP and icon?
(18:07:31) ulf82: Well, yes, even the icon could be left out for now.
(18:07:48) ulf82: we could put accessibility in, which is now inside the map tiles.
(18:08:40) Renn: yes, we could
(18:08:47) Renn: it should depend on the type
(18:09:05) ulf82: Yes, but I think the actual definition of the tile type is rather easy.
(18:09:20) ulf82: What is more interesting is how to tie it in the rest of the code
(18:09:30) ulf82: So, the two issues that I can see:
(18:09:51) ulf82: 1. The scenario somehow (define somehow) has to specify which tiles exist
(18:10:34) ulf82: 2. When loading a map, we need to be able to resolve the tile type of all the tiles.
(18:11:01) ulf82: In the xml they are only defined by name or so, the code should rather use references to the concrete instances.
(18:11:43) ulf82: ad 1.: specify which tile types exist.
(18:12:06) Renn: shouldn't it just build an instance from name and other properties? so in theory if you change xml you change type too
(18:12:31) ulf82: You mean an instance of the tile type?
(18:12:37) Renn: yes
(18:12:52) ulf82: yes, sure.
(18:13:21) ulf82: However, the map definition will look like <map> <tile> <x>1</x><y>0</y> <type>Grass</type> ... </map>
(18:13:55) ulf82: so when loaded, the map only has the tile names for each tile, but it needs the types.
(18:14:01) ulf82: type instances
(18:14:03) Renn: aha
(18:15:14) Renn: add in separate xml tile types? or can you put it inside the same xml?
(18:15:36) ulf82: Ok, maybe we first define how the tile types are loaded and made available.
(18:15:50) ulf82: and then how they are passed to the various map tiles.
(18:17:09) Renn: we could make some static xml file with list of all possible tile types
(18:17:13) ulf82: probably the simplest way would be to put it inside the scenario xml description file.
(18:17:27) ulf82: But then it would have to be copied whenever you make a new scenario.
(18:17:49) Renn: ye
(18:17:52) ulf82: On the other hand, you could load the tile types just in the normal scenario loading process.
(18:18:04) ulf82: which is extremely convenient and straight-forwards
(18:19:05) ulf82: I would almost suggest this as a solution.
(18:19:13) ulf82: remove the "almost"
(18:19:44) Renn: i'm fine with that
(18:19:47) ulf82: ok.
(18:20:07) ulf82: Then, since tiles only have to do with maps, I would suggest that GameMap is augmented by a list of tile types inside this scenario.
(18:20:14) ulf82: ScenarioMap, sorry
(18:21:18) Renn: only with types that are used for that scenario, yes
(18:21:23) ulf82: yes.
(18:21:36) ulf82: that would solve one problem.
(18:21:51) ulf82: The only interesting issue here is that you cannot create a map out of thin air.
(18:22:16) ulf82: But this can easily be solved by requiring a template scenario/map for all further processing (like random map generation)
(18:22:21) ulf82: </side remark>
(18:22:45) Renn: ok
(18:22:58) ulf82: Now the second part is to load the map tiles with the name of their tile type, but replace this name with the actual tile type.
(18:24:11) ulf82: And this looks straight-forward
(18:24:27) ulf82: because we already have a post-processing facility for that: scenario.map.managers.Manager
(18:24:53) ulf82: or rather, the ScenarioBuilder.
(18:24:59) ulf82: He, this sounds pretty easy.
(18:25:45) ulf82: ping
(18:25:51) Renn: is there maybe jaxb annotation that would do that automaticly? do you know?
(18:26:02) ulf82: in theory, yes.
(18:26:11) ulf82: I think.
(18:26:29) ulf82: But in practice, when we load a scenario, we need to run all these managers on the scenario anyway for post-processing.
(18:27:08) Renn: so you want to do it manually?
(18:27:10) ulf82: so we would just add another manager that does the tile replacement.
(18:27:14) ulf82: Yes.
(18:27:15) Renn: ok
(18:27:35) ulf82: Doing it automatically during the jaxb loading runs into the problm that the tiles are loaded together with the tile types.
(18:27:50) ulf82: So you could only do it as a post-processing hook anyway.
(18:27:57) Renn: aha
(18:28:16) ulf82: so it would not be n annotation, but rather an annotated post-processing function.
(18:28:36) ulf82: Anyway, I think that would already compose a rather interesting coding task.
(18:28:39) ulf82: comprise
(18:29:08) Renn: yes
(18:29:14) ulf82: Do you want to summarize?
(18:29:41) Renn: ok
(18:30:29) Renn: 1) add set(to remove possible duplicates) of tile types to scenario map that is loaded from xml
(18:31:21) Renn: 2) add new class, tile type that has name, MP and access
(18:31:32) Renn: 3) add tile type name to map tile to be loaded from xml
(18:32:25) Renn: 4) add new scenario manager, that connects tile type name inside map tile with an instance of tile type that is inside scenario map
(18:32:49) Renn: so we would also have a xml transient instance of tile type inside map tile right?
(18:33:24) ulf82: yes
(18:33:47) ulf82: I think for 1), you might have to use a list.
(18:33:53) ulf82: Not quite sure if jaxb works with sets.
(18:33:56) Renn: aha
(18:34:04) Renn: ok, list then if needed
(18:34:36) ulf82: and another 5) Propagate changes (ScenarioBuilder, remove Access from MapTile, update the various jaxb tests)
(18:34:58) Renn: yes, that too
(18:35:08) ulf82: Do you want to write up the task as well?
(18:35:55) Renn: sure
(18:36:03) ulf82: ok.
(18:36:10) ulf82: just say when you are done
(18:41:28) ulf82: by the way, it is nice when seemingly complicated things turn out to be so easy, because the code is already there.
(18:42:12) ulf82: brb
(18:42:43) Renn: done
(18:42:54) Renn: yes, that's always nice :)
(18:45:48) ulf82: back
(18:46:29) ulf82: ok
(18:46:33) ulf82: fine with me
(18:46:45) ulf82: I would gladly leave this to you. :)
(18:47:24) ulf82: So with that, we have tile types, which we can also access.
(18:48:01) ulf82: ah, one thing that I would add is a note that the manager should also check the tile types for sanity
(18:48:21) Renn: how do you check for sanity?:D
(18:48:25) Renn: you mean MP?
(18:49:01) ulf82: just that the list/set is not null, does not contain duplicates etc.
(18:49:18) ulf82: maybe you find more conditions for breaking this. :)
(18:50:06) ulf82: With this small detour done, we could go back to the original task of the map generator.
(18:50:18) Renn: ok
(18:50:57) ulf82: So, the generation should start with the loading of a template scenario file, and then running "filters" on it.
(18:51:05) ulf82: (names to be defined)
(18:51:45) ulf82: Is there a better name for the filters?
(18:51:51) ulf82: generators maybe?
(18:52:25) Renn: generators or modifiers maybe better
(18:52:43) ulf82: then let's maybe settle for generators.
(18:52:48) Renn: ok
(18:53:03) ulf82: Mmh. Maybe we should start from the use-case definitions.
(18:53:13) ulf82: How much control should the player have over the map generator?
(18:53:17) ulf82: map generation scheme
(18:53:34) ulf82: Should he be able to select the single generators, or just see a default black box with settable parameters?
(18:54:36) Renn: hm, not sure if we let user choose algorithm per tile type would that be too much information
(18:55:12) ulf82: I mean, in any case there needs to be of course a standard setting, where the user only selects the most prominent features.
(18:55:13) Renn: but then the question is how do we combine different algorithms
(18:55:57) ulf82: The question is whether we should bundle all standard generators into a black box without (from the outside visible) internal structure.
(18:56:54) ulf82: It might not make much sense for the map generation to enable the user to select different algorithms on a tile type basis, but it might be interesting for the higher generators (city placement etc.)
(18:57:15) ulf82: to modify the exact generator scheme
(18:57:40) Renn: ok, but then as we dont' have static tile types, how we define what algorithm will be used for which tile type?
(18:58:35) ulf82: Looks like it becomes complex...
(18:59:05) Renn: we could make it that for now we use only a single algorithm for all tile types
(18:59:06) ulf82: You could transmit this information to the client (load the template scenario, then you have the tile types), but this is indeed rather complicated
(18:59:26) ulf82: and the algorithm just goes through the tile type list?
(18:59:35) Renn: yes
(18:59:55) Renn: so user would be able to select that algorithm
(19:01:06) ulf82: You still need to be able to select the percentage of terrain to be transformed; so in any case, the generator will need the list of tile types in the constructor or so.
(19:01:26) ulf82: to be able to specify how it can be customized.
(19:01:42) Renn: yes
(19:01:46) ulf82: ok.
(19:01:57) Renn: percentage is needed, yes
(19:02:01) ulf82: So let's maybe speak about generators in general.
(19:02:17) ulf82: They should have a generate() function that takes a scenario and does something with it.
(19:02:40) ulf82: They should be able to spit out a list of parameters
(19:02:51) ulf82: And they should have the ability to set parameters.
(19:03:18) Renn: what parameters?
(19:03:36) ulf82: Since the generator is an interface, I would suggest anything that works.
(19:03:55) ulf82: Terrain percentages for the map generators, number of cities for the city placement generator etc.
(19:04:51) Renn: shouldn't that be already set, so the algorithm would just use it and make what it does?
(19:05:06) ulf82: Well, there should be defaults definitely.
(19:05:25) ulf82: but in general, the user can have some control over the generators.
(19:07:07) Renn: that is what i mean, those parameters would be set by user, not generator (algorithm)
(19:07:13) ulf82: yes.
(19:07:40) Renn: i would make generators do only object placing strategies on the map, not setting any other values
(19:08:25) ulf82: could you rephrase that?
(19:08:59) Renn: you said "they should have the ability to set parameters"... did you mean on generators there?
(19:09:17) ulf82: "they" meant "the users"
(19:09:21) Renn: aha
(19:09:24) Renn: ok, then nvm xD
(19:09:44) ulf82: or actually, I meant the generators should have the ability to receive parameters from the outside world
(19:09:53) ulf82: which is the same
(19:09:56) Renn: yes, thats fine
(19:10:45) ulf82: So, I think that should be the basic framework.
(19:11:18) Renn: yes
(19:11:34) ulf82: To make things not too complicated, we could start with a city placement generator.
(19:11:49) ulf82: That comes towards the end of the chain, but as a test case, that might be fine enough.
(19:11:49) Renn: ok
(19:12:13) ulf82: That would also then comprise a coding task.
(19:13:27) ulf82: Let me see: The parameter class, the generator interface, and the city placement generator implementation.
(19:14:11) ulf82: Do you agree so far?
(19:14:26) Renn: yes
(19:14:49) ulf82: Then, for the parameter, we could for now go for only integer parameters.
(19:14:58) ulf82: Until we need Booleans or strings
(19:15:24) Renn: ok
(19:16:05) ulf82: Mmh.
(19:16:12) ulf82: Forget it
(19:16:25) ulf82: A parameter seems to need a name and a default value
(19:17:45) Renn: ok, so you would just put object for value?
(19:18:21) ulf82: I think in the old code, it also had a value, and the generator would then have an internal list of parameters that were queried inside the algorithm
(19:19:04) ulf82: So that the parameter was an enclosed thing that was used directly to store the settings, and also to tell the outside world.
(19:19:08) ulf82: Maybe that is a smarter idea
(19:19:38) ulf82: Then the parameter would have a name, a default value, and a set value.
(19:19:51) ulf82: Sorry, it would not even need a default value.
(19:19:59) ulf82: It is just initialised with the default.
(19:21:08) ulf82: Is any of this comprehensible?
(19:22:16) Renn: i'm just not sure if you want to make it one generic class or many subclasses? like intparameter or something liek that?
(19:22:27) Renn: because if it is one class, how do you set default value?
(19:22:46) ulf82: The latest idea that I had was:
(19:22:56) ulf82: 1. A generator has some list or map or whatever of Parameters.
(19:23:05) ulf82: 2. In the constructor, it fills this list
(19:23:34) ulf82: It generates new Parameters with a name and a value (where the value is then the default)
(19:23:52) ulf82: 3. When queried, it returns this list of parameters
(19:24:10) ulf82: 4. When a new parameter is set, the corresponding value is replaced in the internal list
(19:24:28) ulf82: 5. The algorithm accesses the parameters, e.g., by their name.
(19:25:10) Renn: ok, but then we would have to have a list of static parametres right?
(19:25:38) Renn: well, that makes sense actually, it's pretty hard for algorithm to use a completely new parameter
(19:25:41) ulf82: inside each generator class/instance, there would be a static list of paramters
(19:25:49) ulf82: yes
(19:25:58) ulf82: you have to check for sanity anyway
(19:26:06) ulf82: (i.e., that the parameter is useful for the generator)
(19:27:03) Renn: yes
(19:27:28) ulf82: Then I would suggest to use this scheme until we run into troubles. :)
(19:27:41) Renn: yes, ok
(19:28:01) ulf82: So, a parameter is essentially a pair (String name, int value).
(19:28:04) ulf82: For now.
(19:28:16) ulf82: Then the generator interface:
(19:28:33) ulf82: 1. Set<Parameter> getParameters()
(19:28:52) ulf82: 2. setParameter(Parameter)
(19:29:05) ulf82: 3. generate*Scenario)
(19:29:24) ulf82: sorry, generate(Scenario)
(19:29:58) ulf82: does this sound like a complete interface?
(19:30:02) ulf82: brb, phone
(19:30:50) Renn: i think so, everything else should be inside the scenario object
(19:34:04) Renn: brb
(19:37:25) ulf82: back
(19:37:30) ulf82: yes.
(19:38:13) Renn: back too
(19:38:19) ulf82: And the CityPlacementGenerator should then have 1 parameter (number of cities), and place this number of cities randomly on the scenario map.
(19:38:51) ulf82: Implementing that should uncover the most obvious flaws in the concept so far.
(19:39:27) Renn: should there be any restrictions regarding placing of cities?
(19:39:47) ulf82: Well, the terrain should be accessible somehow.
(19:39:55) ulf82: And they should not be on top of each other. :)
(19:41:16) ulf82: I think these are all restrictions.
(19:41:17) Renn: yes, those are understood :)
(19:41:45) Renn: any other? like min distance between cities?
(19:42:00) ulf82: At least for simple city placement.
(19:42:10) ulf82: Good question.
(19:42:35) ulf82: I would suggest to obsolete the generator by a more sophisticated one in a later stage.
(19:42:45) ulf82: or in other words: no. ;)
(19:42:53) Renn: ok
(19:43:04) ulf82: then I would try to write up this task as well
(19:43:09) Renn: ok
(19:47:20) ulf82: 138
(19:51:25) Renn: it's fine
(19:51:29) ulf82: ok
(19:51:35) ulf82: Then I think we should stop here.
(19:52:32) Renn: ok
(19:52:41) Renn: when are you avaible next time?
(19:52:56) Renn: *available
(19:52:57) ulf82: Well, next week I have only Wednesday free, and then I would like to relax again. :)
(19:53:10) ulf82: So, Monday the 5th onward.
(19:53:17) ulf82: Could we arrange this next week somewhen?
(19:53:35) ulf82: via email
(19:54:17) Renn: sure, np
(19:54:24) ulf82: ok.
(19:54:35) ulf82: Then I would contact you next week.
(19:54:42) Renn: ok
(19:54:48) ulf82: I would also care for the summary in a second.
(19:54:53) Renn: ok
(19:54:56) ulf82: so, feel free to code. :)
(19:55:02) Renn: i'll try XD
(19:55:05) Renn: have a nice week :)
(19:55:13) ulf82: you too.
(19:55:16) Renn: bye
(19:55:18) ulf82: bye
(19:55:23) Renn left the room.