On Thu, Mar 31, 2011 at 3:57 PM, Jeff Johnson <[email protected]>wrote:
> You are correct, that's a better way to do it. I was hoping for a nice > shortcut to duplicate the Tiles GUI easily. :) > My fear is that we end up with a working tiles version and only a working tiles version instead of something that could very easily be extended in some really cool ways. > Are you are proposing to send only the delta's (new state changes) or a > full representation of the state data? Are delta's tracked already or would > we need to store a duplicate copy of each state data object? > It is not much work to submit the deltas and it does not require a lot of extra storage. It is just computation done when creating the updated blob. Personally, I think it is best to send the full data every time because this feels more like an improvement than a design fork but I'm not married to it. > How would we determine what should be sent and what should not be sent? > For example, looking at the player class, should the 'berserk_penalty' be > visible to the user in some form? I'm not sure I can judge properly on many > cases. Maybe we start off very restrictive and only add items that are less > obvious as needed. > This is why I called out defining the JSON format very carefully. People who understand the internals of the game better than I can suggest what fields are known to the user. I don't think berserk penalty would be shown, for example. > For your Step 2 (deltas to JSON), I image it's just a function like: > string MakePlayerDeltaJSON(player * you); > And that function just pick the fields it wants to export and returns a > huge string worth of data. Is that what you are thinking? If so, this > sounds easy enough without me knowing much about the other state objects. > I think you are serializing a bit more than just the player. You also have the map knowledge, messages, etc. I'm also not sure what the best delivery mechanism is. > The message window stuff appears to assume a local GUI, in message.cc, > message_window::out_line() it directly calls 'cprintf()'. This looks > sticky, and I'm not ure the best way out of it yet. > The JSON needs a section for messaging. The existing messaging stuff needs to get wrapped up into a class which can serialize it. > The more that I think about this overall approach, I guess these JSON blobs > could be used to record and playback a game, right? Is there any ability to > do record/playback now? I haven't seen any, but I'm not familiar with all > aspects of non-tiles or online play mode. > Playback is one of Crawl's strongest features. All games are not only playable, but searchable! Pop in ##crawl on irc.freenode.net to see how epic it is. Maintaining this is a concern of mine and one that needs further thought.
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________ Crawl-ref-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
