I've been doing some more digging and found that if I want to do an online
tiles client right (meaning send game information to the client and not tile
information), we'll need to implement most of tilepick.cc in the Javascript
client. Parts of tilepick.cc know too much, so we'll have to dumb-down the
information, that's not a problem.
So for example, for a pile of gold on the dungeon floor, we'll send
'item=15', which is 'enum.h::OBJ_GOLD'. In the client tilepick.cc it will
translate OBJ_GOLD to TILE_GOLD.
Getting the TILE_GOLD enums into the Javascript client will be easy. It's
just a modification of the tile utility. Getting the enum.h enums into the
Javascript client is a bigger pain. I see three choices:
1) Type in all the values by hand. Not good because they will always be
out of sync.
2) Write a parser to read enum.h and output Javascript. Possible, maybe
fragile and has some dependencies on keeping enum.h around.
3) Wrap all enum.h enums in a macro so it can be optionally compiled to
emit Javascript. Nice, but makes enum.h look a bit messy.
What do you think? Are there better ideas I haven't listed?
Also, if I ever get some code that should be committed, what is the process
to get git access? Are there code reviews or are commits approved?
--Jeff
On Wed, Apr 13, 2011 at 1:08 PM, Jeff Johnson <jeffjohns...@gmail.com>wrote:
> Hello All,
>
> I've put a little thought into the Online Tiles data format (the JSON blobs
> from Henry's idea) and was hoping to get some feedback on it.
> I've been putting my ideas here:
> https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:internal:clientserver&#online_tiles
>
> So far, I have some modifications to the crawl source that outputs the JSON
> blobs to a file per frame. I.e. the first call to world_reacts() will write
> the data to JSON_00000.js, the second to JSON_00001.js, etc. Also, I have a
> Javascript web page that will look for these files in sequence and display
> them, one per second. The tile display works, but the mapping is
> incorrect. I wish tilepick.cc could be simpler. :) This framework gives
> me a less awkward debug cycle for modifications, and it lets me know the
> idea generally works.
>
> Anyway, I'm hoping to get some ideas on what I'm missing and some pointers
> on new directions to explore so we can develop and improve what we have so
> far. Any feedback is welcome, I'll do my best to incorporate it into the
> Wiki page.
>
> Jeff
>
>
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
