Conversation with #freelords at Mon Oct 22 19:21:57 2012 on ulf82@irc.freenode.net (irc)
(19:30:25) patton [~patton@151.36.251.245] entered the room.
(19:30:29) patton: hi
(19:30:32) ulf82: Hi
(19:31:32) ulf82: So, to get the code a bit forward, I would suggest we try to go ahead with the start of a new game.
(19:31:37) ulf82: and all the framework around.
(19:31:49) patton: ok
(19:32:01) patton: what about this new coder?
(19:32:16) patton: do not think he know agile way
(19:32:23) ulf82: don't know.
(19:32:31) patton: we will see
(19:32:34) ulf82: yes.
(19:32:43) patton: i started to post here and there request for artists
(19:32:51) ulf82: It is a bit problematic that we do not have a fitting design task for introduction.
(19:32:54) patton: we will see if somenoe wil come
(19:33:11) patton: right now newcomers must study the code
(19:33:20) patton: this is the only way I believe
(19:33:24) ulf82: yes.
(19:33:33) ulf82: IT helps at least a lot.
(19:33:36) ulf82: Anyway.
(19:33:41) ulf82: Back to topic.
(19:33:48) patton: yes
(19:33:52) patton: so
(19:33:53) ulf82: Do you remember the problematic points from the last chat?
(19:33:58) ulf82: go ahead
(19:34:00) patton: game start
(19:34:12) patton: mmm pheraps not all points
(19:34:28) patton: basically we need a lot of things
(19:34:41) patton: - framework to setup scenarios
(19:34:51) patton: - a framework to load the scenario and make a game
(19:35:08) patton: - decide how server sends data to clients and when
(19:35:40) ulf82: What we have so far:
(19:35:51) ulf82: Framework to load scenario
(19:36:11) patton: yes only the scenario map
(19:36:13) ulf82: So with a few lines of code, you should be able to load and setup a scenari oso that the data is ready for play.
(19:36:35) patton: well if you mean only basic data yes
(19:36:44) ulf82: basic game data, yes.
(19:36:46) patton: but then we will cope with graphics, sounds etc etc
(19:36:58) patton: but let's avoid that for a while
(19:37:04) ulf82: Before we get lost in the details: How to structure the discussion?
(19:37:22) patton: we can start talking about tha scenario file directly
(19:37:28) patton: 1) loading of map
(19:37:35) patton: 2) visualization of that map
(19:38:15) patton: point 2 needs us to decide how data is loaded from scenario zip file
(19:38:26) ulf82: what the structure is so far:
(19:38:34) ulf82: the scenario is loaded from an xml file.
(19:38:54) patton: yes right now we have a unique xml file that basically defines the map and game data
(19:38:55) ulf82: there are scenario modifiers that can also be loaded from an xml file and applied for minor scenario modifications
(19:39:07) patton: yes
(19:39:22) patton: pheraps we can decide to split data in various xml files
(19:39:34) patton: for better reading of the xml files
(19:39:46) patton: and decide that the scenario is the whole zipped file
(19:39:53) ulf82: xml files are already pretty nicely hierarchic.
(19:40:11) patton: well yes but they can become huge
(19:40:25) ulf82: In principle yes.
(19:40:34) ulf82: But for now we can keep it simple.
(19:40:39) patton: just think about graphics pointers, music, sounds and many other things as quests and so on
(19:40:42) ulf82: I think it should not be a huge thing to extend this.
(19:41:13) patton: for sure we must decide how to redefine resources for the scenario
(19:41:28) ulf82: Basically, you only have to modify how a scenario is loaded, which is done inside the scenario builder for the most part.
(19:41:31) patton: at first try we can decide to have hardcoded resources
(19:41:51) patton: we can prepare a whole set of resources
(19:41:53) ulf82: Ah yes, let's start with the resources...
(19:42:05) ulf82: The original idea was to have the fixed directory hierarchy for data
(19:42:14) patton: inside the single scenario
(19:42:20) ulf82: and then put data into various directories which can be transparently accessed by a repository
(19:42:30) ulf82: So I would suggest that
(19:42:40) ulf82: a server has a separate resource directory for each scenario
(19:42:48) ulf82: that is sent to the clients when they start a game
(19:43:10) patton: yes
(19:43:19) patton: according to me server should have a path
(19:43:27) patton: let's say "scenarios"
(19:43:36) ulf82: so on the server side in the scenario directory, you have something like basic_map.xml and basic_map.zip.
(19:43:39) patton: inside which we will put the zipped scenario file
(19:44:13) patton: well wait a sec
(19:44:25) patton: we can have 2 ways for resources
(19:44:38) patton: basic resources already installed into the server
(19:44:46) ulf82: brb
(19:44:54) patton: and overridable resources found into the scenario_name.zip
(19:46:09) ulf82: well, my idea would be to transfer the file scenario_name.zip to the client.
(19:46:25) ulf82: The client puts it in some temporary directory, and adds it to the search path of the repository.
(19:46:39) ulf82: inside, the zip has the normal structure music/, army/ and so on
(19:46:49) patton: so you basically decide to "replay" all similar resources
(19:47:06) ulf82: what do you mean by replay?
(19:47:19) patton: let's say we have a standard tileset
(19:47:29) patton: whar do we put the std graphics?
(19:47:47) ulf82: $DATADIR/tileset or something like this.
(19:47:53) patton: if we put it into the zip then we have many copies of the same files
(19:48:08) ulf82: yes, so the zip should only hold scenario-specific files
(19:48:12) ulf82: (specific units or so)
(19:48:26) patton: well scenario-specific and overridable things
(19:48:28) ulf82: if this grows into too much, it can always be made a separate add-on to download.
(19:48:35) patton: i can have new tileset for the new scenarios as well
(19:49:00) ulf82: right, overridable... Mmh.
(19:49:08) patton: so client must search for std tileset and if it does not find it, it will be forced to load tileset from scenario zip file
(19:49:09) ulf82: Yes, looks like a good thing.
(19:49:19) ulf82: Better idea:
(19:49:36) ulf82: When the client starts, it sets up a resource repository that points to all standard data.
(19:49:37) patton: we can achieve it just adding a new keyworkd
(19:49:46) ulf82: (standard files plus standard add-ons or so)
(19:49:49) patton: yes
(19:49:51) patton: then?
(19:50:10) ulf82: when the client starts a new scenario, it receives the zip with the overridden and scenario-specific data.
(19:50:16) ulf82: It puts it into some cache directory,
(19:50:40) ulf82: and creates a new repository for the purpose of the game, which includes the standard repository, and this zip with a higher priority
(19:50:52) patton: yes
(19:50:58) ulf82: so overriding is automatically included.
(19:51:00) patton: but the keywork must be different
(19:51:01) ulf82: kind of.
(19:51:07) patton: for ex
(19:51:14) patton: let's say we have a tag
(19:51:22) patton: <tileset></tileset>
(19:51:34) patton: and inside the keywork for the std tileset
(19:51:41) patton: for ex EUROPE
(19:51:55) ulf82: I think I understand.
(19:51:59) patton: i would not liket to ovverride EUROPE
(19:52:11) patton: but i want a new keywork for AFRICA for example
(19:52:13) ulf82: We basically need another xml file that defines potentially specific resources for a scenario.
(19:52:19) patton: right
(19:52:31) ulf82: Correct me if I am wrong:
(19:52:36) patton: or just override the ones inside the scenario.xml
(19:52:59) patton: what i mean is the if we add new resources we must point to them with new keywords
(19:53:05) ulf82: But the file transfer, receiving and putting into a separate directory, creating a new repository, and maybe the keywording stuff would be a separate design task.
(19:53:33) ulf82: no dependencies on anything else and so on.
(19:53:35) patton: sure
(19:53:47) ulf82: Should we try to finalize this for the beginning?
(19:54:05) patton: we at beginning can just add new keywords and let the clien search for them inside the cache
(19:54:18) patton: as simplest thing
(19:54:33) ulf82: two questions:
(19:54:39) patton: ok try to finalize that
(19:54:50) patton: as first thing the zip file structure i believe :)
(19:54:53) patton: yes?
(19:55:01) ulf82: 1. Do we want to separate the game logic (game map, units etc.) from the resource data?
(19:55:10) ulf82: Because then I would suggest a separate file for this.
(19:55:24) patton: yes sure the xip file can hold everithing :)
(19:55:53) ulf82: So, the zip file would somewhere have a hard-coded file name that defines all the tileset to use etc?
(19:56:03) ulf82: say scenario/setup.xml
(19:56:11) patton: well just define the dir srtucture
(19:56:18) patton: yes
(19:56:34) ulf82: ok.
(19:56:45) patton: i would have for sure graphics dir
(19:56:54) patton: sound dir
(19:56:59) patton: conf dir
(19:57:05) ulf82: well, all the standard directories.
(19:57:31) ulf82: it would, after all be accessed by a DataRepository instance
(19:57:39) patton: sure
(19:57:59) patton: but we can add few more for readability'a sake
(19:59:03) ulf82: Ok.
(19:59:04) patton: ping
(19:59:08) ulf82: So let us try to summarize this one.
(19:59:18) patton: ok let's start with std directories
(19:59:33) patton: ok
(19:59:44) patton: just summarize
(19:59:58) ulf82: 1. There should be a hard-coded file (suggestion: scenario/setup.xml), which contains all resource-related information of a scenario.
(20:00:07) ulf82: No, wait, again.
(20:00:31) ulf82: 1. We need a facility that allows the server to send a zip file (with scenario-related graphics etc.) to a client.
(20:00:54) patton: sure
(20:01:02) patton: just a service that sends binary file
(20:01:11) ulf82: 2. We need on the client side a listener that can receive such a file, put it in a cache directory, and somehow issue a repository based on that directory and an input repository.
(20:01:38) ulf82: Should it be an actual service?
(20:01:52) patton: well it should be a service
(20:01:52) ulf82: Well, at this point I think it would be enough to just have the update defined.
(20:02:11) ulf82: The service is rather trivial then, and I am not quite sure how it will look like in the end.
(20:02:27) patton: a service that reads the data from a fixed dir and send and update with data
(20:02:41) patton: well we cannot load everything in memory
(20:02:44) patton: for sure
(20:02:56) ulf82: Well, a service reacts to a command, usually
(20:03:10) ulf82: also.
(20:03:13) patton: the command is "read this scenario"
(20:03:16) ulf82: I would include versioning here.
(20:03:28) patton: versioning for the scenario?
(20:03:33) patton: or the service?
(20:03:33) ulf82: yes.
(20:03:47) ulf82: So that the thing is only sent if the client does not have it already
(20:04:15) patton: ah ok
(20:04:28) patton: so the client command must do some checks
(20:04:41) ulf82: binary files can be rather large, and would have to be sent whenever the client reconnects to a game or so.
(20:04:54) ulf82: so it seems as if the client should initiate the file receiving request
(20:05:17) patton: yes
(20:05:28) patton: ok we must define a lot of things here
(20:05:36) ulf82: Then we could delay the versioning to later.
(20:05:42) ulf82: After all, it could be done by the client.
(20:06:02) patton: ok lets' say the first version is : client sends a command and receives an update with data
(20:06:08) ulf82: yes.
(20:06:16) ulf82: That would also be the acceptance test
(20:06:19) patton: it saves it into the chache directory
(20:06:25) patton: cache
(20:07:35) ulf82: Then we can also strip the fixed filename and scenario definition stuff, because there is just no use case naturally included in this set of code
(20:08:20) patton: yes we will define a new task for that
(20:08:29) ulf82: ok.
(20:08:32) patton: for now just take a binary thing and save a file
(20:08:32) ulf82: I could try to write it up.
(20:08:45) patton: the update will tell us also how to name the binary blob
(20:08:55) patton: so 2 data
(20:09:00) patton: name.ext and blob
(20:11:19) patton: ping
(20:11:40) ulf82: still writing.
(20:11:43) patton: ah ok
(20:14:55) ulf82: task 135
(20:15:02) ulf82: And you probably have comments
(20:16:01) patton: still loading
(20:16:06) ulf82: ah.
(20:16:14) ulf82: maybe it is faster if I paste the text here. :)
(20:17:30) patton: ehm
(20:17:36) patton: pont b?
(20:17:38) patton: point
(20:17:41) patton: is obscure
(20:18:04) patton: what does it mean?
(20:18:05) ulf82: The last sentence only or the whole point?
(20:18:11) patton: the whole point
(20:18:24) patton: why do the update returns a datarepo?
(20:18:50) patton: it just need to take a datarepo as parameter to save the file into the cache dir
(20:18:52) ulf82: Maybe it is even invalid. Single responsibility and all that
(20:19:09) ulf82: I would actually scrap it.
(20:19:28) patton: the repository is taken from outside
(20:19:44) patton: and the update just saves the new file into the right path
(20:19:55) ulf82: The idea is that when we have a specific scenario, then we would take the generic repository, and add the zip for this scenario
(20:20:07) ulf82: to access all data required for the scenario
(20:20:23) ulf82: But that should probably not be mixed with this.
(20:20:30) ulf82: this listener
(20:20:39) patton: well it will be done in another side
(20:20:50) ulf82: Yes, I will remove it.
(20:20:57) ulf82: Another question just jumping up:
(20:21:04) patton: yes?
(20:21:10) ulf82: You would want to wait for this listener to finish when downloading files.
(20:21:23) ulf82: Should this be implemented already here?
(20:21:41) patton: well yes this must be blocjing
(20:21:57) patton: blocking
(20:21:57) ulf82: Then I will add a note to this effect.
(20:22:03) ulf82: Though this would then block the whole GUI
(20:22:16) ulf82: typically.
(20:22:17) patton: yes
(20:22:19) ulf82: ok
(20:22:30) patton: and the downloading will be monitored
(20:22:33) patton: if possible
(20:22:46) patton: but this is another thingg
(20:23:23) ulf82: ok.
(20:23:28) ulf82: Added a note to point three then.
(20:23:39) ulf82: Now you consider it finished as well? :)
(20:24:27) ulf82: ping
(20:24:31) patton: well yes i believe it is finisshed :)
(20:24:36) ulf82: ok.
(20:24:50) ulf82: Then question: Do we want to continue or interrupt at this natural break point?
(20:25:13) patton: we can interrupt and next time we can talk about scenario zip file structure
(20:25:20) ulf82: ok.
(20:25:27) ulf82: Then when is next time?
(20:25:43) ulf82: Thursday or Friday maybe?
(20:26:00) patton: yes i just need to know when i am alone with childs
(20:26:07) ulf82: ok.
(20:26:08) patton: i will mail tomorrow
(20:26:13) ulf82: good.
(20:26:24) ulf82: I will write up the mailing list notification and stuff.
(20:26:32) ulf82: Another thing with thenewcomer:
(20:26:39) ulf82: Someone should monitor his first design task.
(20:26:44) ulf82: Who does it?
(20:26:52) ulf82: (monitor == be his partner)
(20:27:09) patton: i can try to be there but first i would like him to read the code
(20:27:41) ulf82: Also, this is a nice little design task perfect for introduction.
(20:27:47) ulf82: Anyway, I drift away.
(20:28:00) patton: we can chat thursday i would say at 22
(20:28:12) ulf82: ok.
(20:28:27) ulf82: just write a mail tomorrow for safety.
(20:28:30) patton: this week my wife works all evenings....
(20:28:33) patton: yes
(20:28:58) ulf82: then I am now off for dinner.
(20:29:05) patton: ok so have a good dinner
(20:29:07) ulf82: Have a good evening with the kids. :)
(20:29:14) patton: see you later then
(20:29:17) ulf82: see you