I didn't write any line of code, nor did I put down any design document. I spent most of my time doing various abstract thinking about what and how can be done to make EL more dynamic, such as, for example, adding some XML defined menus, which the server can request the client to open.
For example, the server would tell the client: "Open the Yes/No menu" then the client will open it and depending on what type of menu it is, either freeze the whole gamplay until the user presses a button, or just let the game continue. After the user makes a selection, the answer is relayed to the server which will do whatever is necesary.
I am also thinking about what is the best way to integrate the Small scripting language with the EL client. So far, I know that there will be at least two virtual machines, independent of eachother.
One virtual machine will be omnipresent (will be loaded when the game starts) and another one will be on demand, for the current map, if the current map has an associated Small script file.
Due to the fact that the Small VM is slightly different on 32 and 64 bitprocessors, the scripts will have to be compiled at runtime, and then cached, based on what kind of CPU we are dealing with (32b or 64b).
A dissadvantage is that the players will be able to read the script file and even modify it, but since this is an Open Source game, it shouldn't make a huge difference.
Finally, a 3rd VM might be needed for client scripts started at the request of the server. However, the problem is, I do not know how to handle multiple scripts. Normally a VM would be needed for every script, so this might have some negative impact on the performance, not to mention making it more difficult to implement.
On an unrelated note, I posted a rant about the GDnet rating system, rant which was locked.
If you wish to comment about it, please do so here.
