Thanks for that. We had a discussion last night and we agreed that all research types can be represented as a graph. I will be putting together the recommendation, and will probably be using your suggested format for the basis of it.
Thanks for the ideas and the discussion. Later Lee On Sat, 26 Jan 2008, JD Marble wrote: > I misunderstood the purpose of the LCA08 wiki page, so here is the > section I added for discussion. > > Research frames > > When, what, how? > > Although it is generally referred to as a research "tree", most games > with unlockable technology actually implement a directed acyclic > graph. A technology that can be researched is represented by a node in > this graph and dependencies on other technology is represented by the > edges. > > A frame describing a research node should probably contain the following: > > * name > * long name > * description (flavor text) > * list of technologies that must be available before this one is > researched * list of resources required to research this technology > * list of universal references of things made available once this > technology is researched (components, other technologies, etc...) > > But it can be very different from that. Some games support > research only one technology at time, some support multiple, some > don't even let the player choose. Some don't have specific > technologies, just "areas" and at random intervals give a component, > ability, etc. So it isn't quite as cut and dried as you have made it > sound. We (mithro and I) talked about it last year and I guess we need > a bit more. --Lee Begg 00:48, 21 January 2008 (EST) > > A research node doesn't necessarily describe a specific technology. It > could represent a broad "area". A research tree made of areas would > look something like this: > > * Biology I <- Biology II <- Biology III <- ... > * Energy I <- Energy II <- Energy III <- ... > * Construction I <- Construction II <- Construction III <- ... > * ... > > A research tree could be arranged linearly if the client is to be > given no choice in what to study. In such cases the only reason to > send these frames would be to allow the client to choose what > resources to allocate to research. A simplified, linear "tree" might > look like this on a client: > > * Tech Level 1 <- Tech Level 2 <- Tech Level 3 <- ... > > As each node is researched it could bear fruit after, for example, the > amount of "research points" allocated to it are spent. Alternately, > the server may not tell the client how long this research will take to > complete. In such cases the time needed to complete a node may be > predetermined, but hidden or simply randomized. Similarly, the results > of completing a research node may be randomized or hidden from the > client. > > Research nodes describe to the client what can be researched, but not > how that research is accomplished. I propose a system with minimal > changes to the protocol and maximum flexibility. In addition to a > "research node" frame described above and a universal reference ID for > referencing research nodes (or perhaps they should be called > "technology descriptions" to be more consistent with other universally > referenced objects), no changes to the protocol are required. > > Clients will tell the server which tech to research by sending an > order that references a technology node. The object that the order is > sent to may differ depending on the game, but will most likely be the > first object belonging to the player with the name "Research" (or > something similar). In this common setup, each player has a single > "research queue". The server may allow research on more than one > technology depending on the resources allocated to each order in the > queue, or research may be limited to a single item at a time. > > Having a default object (i.e. named "Research") allows the client to > have a dedicated research menu or screen as many games do, but allows > flexibility to implement research in different ways. If a client > cannot find the default object, the research screen would be > unavailable. > > Other implementations within this framework are possible. Since each > object can have their own research queue, research could be managed at > the level of individual planets, buildings, "science vessels", etc... > Perhaps each object researching a technology has a certain chance of > completing it on each turn. The more planets, buildings, science > vessels, etc. that are researching that tech, the faster it would be > completed. Such systems would not need to be implemented on the > client. The standard order system would be enough. > > I believe this addresses all the specific situations mentioned by > Lee. It certainly covers all requirements to emulate the games I've > played, but my experience is limited. I welcome any further criticism. > --MidoriKid 17:03, 21 January 2008 (EST) > _______________________________________________ > tp-devel mailing list > [email protected] > http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
