ec2-44-220-44-148.compute-1.amazonaws.com | ToothyWiki | ToothyGDL | RecentChanges | Login | Webcomic

The most recent set of compiler/game files are:

These will always be in sync with the current versions used by the Wiki itself, since they are links to the same actual files.

ToDo / Feature Requests

Compiler / engine / language:
Presumably, that would also allow the inclusion of non-BNF pages?  A general include directive would be useful to be able to separate off chunks of code.  One tricky bit though would be making it so it can include from both web (for wiki) and local files --K
Perhaps. It would whittle away at the state logic / display divide. It would introduce the need for type matching, which I had been skirting around. Bear in mind also that JS string manipulation is horrendously slow. What are you thinking of using it for? - MoonShadow
I'd like to be able to display a box with content { msg }, and then set msg to various things in the logic section. I guess it would be possible to have multiple boxes in the same place with content while_active, or presumably even one box with multiple overriding while_active statements. I don't know Java at all, I'm afraid. --CH
..one could construct an array of integers in the logic section that one then uses to select message parts from a string table in the display section. But I guess that's quite messy to read/write. I'll have a think about how to integrate string processing. - MoonShadow
I'm coming to the conclusion that forming the message from numbered bits might be possible, if a little tricky; it might even be the best solution when forming strings like "The <creature> <action>s you. <Maybe you die>. <Other flangy stuff>". I don't know whether setting the string up is architecturaly better done in the display or the logic, though. You can probably consider my request backburner at most. --CH
Well.. conceptually, the divide is supposed to be "something happens to our game state" vs "tell the user what happened in a way they can understand". Once I allow include directives, one thing I wanted to be possible was complete reskinning of other people's logic by supplying new display sections without having to touch any of the logic. I suspect it's not gonna be feasible to get it that clean in practice for projects with any level of complexity, though. - MoonShadow
Just a quick thought, if that kind of separation is your goal, then you should probably move all the variable definitions to a different block ("state"?).  That way, the "logic developer" and the "display developer" would both have the same interface to work with. --K
As an addition, thinking about your goal of multiple user access to the same game state, you probably want to separate out "shared state" since you probably want some state to be local (e.g. in chess, each player's rotation and character set selections shouldn't be shared) if possible. --K
In the general spirit of "do the smallest possible amount of work required to get stuff people can play with running first and fix it up from there" that actually got ToothyGDL off the ground, I've been wondering what the absolute bare minimum required for that might be, actually. I was wondering about having a system similar to the way save slots work - having the engine fill in the value of a variable, maybe called something like _player, with a value guaranteed to be unique for each client running the game; the logic could then use this in when and if statements, array lookups and so on to bootstrap concepts like private state and the idea of it being a particular client's turn at any one time. However, we would indeed want some syntactic sugar for practical, rather than merely academic, use. I'll have a go at drafting up some syntax suggestions for people to comment on over the next few days, and implement stuff based on that.- MoonShadow
In terms of "smallest amount possible", the real requirements are the method of sharing state between two (or more?) computers.  Everything else is sugar (with the ability to actually distinguish players by computer being the most important sugar).  At it's most basic level, how are you planning on dealing with the problem of "pushing" data?  Are you going to have the clients periodically check the server for a new state? (thinking ahead again, we might need some OnStateChange? events that we can use, but that's back to the low priority sugar) --K

To a large extent, the game logic doesn't actually need to know, the same way that it doesn't need an "I've just loaded a game" event - although such an event might be useful for sugar (in particular, to hide the "load a game" button until the player does something). The server fits neatly in between the logic and display layers. This is what the single-player engine does currently:

..and this is what would happen in a minimalistic multiplayer setup:
For each supported game, the server keeps the last known state and also a counter which is incremented whenever new state is accepted. When submitting state, the client must send the last known value of the counter (the ToothyGDL code is not aware of this and does nothing about it; it happens in the engine, and can be replaced with a different mechanism when we think of one); if this is old - i.e. if new state has been received by the server since the submitting client last received state - i.e. if someone else clicked first - the state is rejected; otherwise, it is accepted. This "deals" with concurrency issues by imposing a well-defined behaviour that can be taken into account when writing code. Moreover, for many board/card games it is a model that fits surprisingly well, since for games such as chess, draughts, whist.. exactly one player is legally allowed to alter game state at any one time, and for games such as Racing Demon the correct behaviour is to accept the first input each turn and discard the rest. New clients that connect simply receive the latest state from the server. Note that up until this point, assuming players can deal by other means (such as wiki discussions) with other players trying to cheat, no new syntax is absolutely necessary, and all existing non-realtime games just magically become multiuser. It would, of course, be possible in the setup so far for players to do things like try to move each other's pieces, but one could argue that this is also possible with a real-life board game or a wiki game.
The presence of sugar such as a unique per-client ID allows the client to indicate to the player whether it is their turn or not and also to explicitly disallow actions if it is not in order to stop people being able to fight for control of each other's pieces and also to reduce spurious network traffic. It would be useful for the server to also provide an independent channel (e.g. a chat window) for abitrary messages, so players can discuss what's happening.
There is a class of games for which this is workable but a poor fit - M:tG, for instance, would require each player to be explicitly queried on whether they wish to respond to each thing that happens, in order to make the turns well-enough ordered; similarly, the Bean Game would require a round of "would you like to make an offer?" for every trade. And it is completely unsuitable for real-time games. The server would be continuosly hammered by clients checking for new state; however, they could be checking a static HTML page that the state propagation script updates in place, state for most board/card games is not that large, and for turn-based games a delay of a couple of seconds before seeing your opponent's move is likely to be overwhelmed by your opponent's thinking time anyway, so it should not be so bad (if it does get bad, a Java plug-in that keeps a TCP stream open rather than polling would pretty much solve that). Also, the initial version should be pretty trivial to write, therefore stands a good chance of actually getting done :) - MoonShadow
Thinking from the point of view of Chess, my only objection to the above scheme is that I've pretty much shot myself in the foot with the way I've implemented ranged movement.  Unfortunately, the only way around that I can think of is having a set of 'local' state, but that requires there to be some kind of StateChanged? event and ...  Basically, ignore me, at least for the first version. --K

Should be done now (not tested it; it's a trivial change to the grammar and I should have been in bed an hour ago..) Note that it's syntactic sugar *only* - I'm not actually stopping you assigning to values declared const right now. So this can stay in the todo list until I do. - MoonShadow

Wow! Impressive work - thank you! - MoonShadow
It's because of the hacky way the wiki formatting is applied. First, the wiki escapes all HTML in the source using HTML entities. Then it searches for sequences that would have represented well-nested pairs of legal HTML tags and unescapes them. It was unescaping the wrong pair of pre/nowiki tags. - MoonShadow

Bug Reports

This is a problem with the browser. If a table cell contains nothing but whitespace, MSIE will silently drop everything but the background colour (and occasionally, unpredictably, even that). Slap an &nbsp; in it, and everything works.
Oh, ok. As does FireFox, which is usually quite good at that sort of thing. Thanks! --CH
What do people think? - should I hide this by automatically presetting cell contents to &nbsp; until you explicitly set it? - MoonShadow
I think, possibly, ThatsNotABugItsAFeature?...  If a cell has no content, the cell is not rendered.  Automatically entering &nbsp; can conceivably alter the size of the cell though, so that might not always be the best solution (although I admit it probably is 95% of the time) --K
Grammar bug (the grammar block for detecting an array lookup was using the value 0 to signal the lack of an array lookup). Now fixed. - MoonShadow
Yes, you are. If you have a test case for that failing, I would like to know. - MoonShadow
No, I was just checking that my assumptions held. --CH

Change Log

(so you know what to grab if you're missing a feature from a local copy of the compiler)

Think you might have broken something here.  At a guess, comment lines are counted twice when working out the line number --K

ec2-44-220-44-148.compute-1.amazonaws.com | ToothyWiki | ToothyGDL | RecentChanges | Login | Webcomic
Edit this page | View other revisions | Recently used referrers
Last edited January 26, 2006 1:11 am (viewing revision 42, which is the newest) (diff)