First, the data structures of the game will be created; Area (or Level) and Tile. An area is a collection of tiles. An Area can have a three dimensional collection of tiles. This will allow more vibrant dungeons where things on one level can trivially (in terms of game engine design) affect things on other levels. It allows for some interesting things to occurr ('You fool of a Took!') that “normal” roguelike games simply will never be able to accomplish. However, normally I expect that levels will be flat (one floor) for most of the time. That will be like 'classic' mode, and then people will go to a special area and 'bang' it will hit them, the whole world is alive!
Anyways, Tile will hold an inventory array and it will dispay (look like) the top character. A lot of this design comes straight out of the Java version of NetWhack. The intent is to copy, or translate, the functionality of the Java code into JavaScript. This will not only demonstrate my knowledge of Java and JavaScript, but my practical ability and experience to translate codebases quickly, accurately and efficiently, when required.
Second, the update() function will have a projection function which will copy the active Area map, centered on the px,py location, onto the Terminal. However it will also display msgline1 and msgline2, which will be handled by the msg() function to provide proper word-wrap or hyphenation and a –more– prompt (which is a special game mode called 'moreprompt' which waits for the user to press enter. There will also be a message history array required.
As well, the update() projection method will also write character data at the bottom of the screen, like in NetHack or other roguelike games. The window size will be autocalculated and only what will fit in the map box will be projected from the Area class. This is already in Java NetWhack so the algorithm is already known.
We will also need functions to load areas from textfiles. The way this worked in Java NetWhack is that there is a text file (or string) which is it's own processing language. The string is split by lines and line by line processed. Keywords such as “MAP 10×10” or “MAP(10,10)” or “MAP”, “10” and “10” on three lines, will start the map loader, which will read characters in and create a standard map based on those characters. So the file will contain a rough visual outline of the map. The, commands such as MON(type,x,y) or DOOR OPEN (x,y) or ITEM (item, x, y) and so forth will allow changes to be made to make the map more interesting. STAIRSUP(x,y) and so on can all be added as a map programming language.
We will also need some random mapmaking methods, which can create the sort of strings above.
We will also need a way to load and save map information (and so forth). In Java we tried to use Serialization and it kind of worked, but there were many subtle bugs that turned out to be implementation problems. Next we tried pickle in Python and it was ok but not what we wanted.
For JavaScript things seem easier since we have access to strong JSON compatability. The idea will be to create a function that dumps data into a JSON string and another that loads that same data. The data itself can be sent to a PHP script on the server which will do the heavy lifting of disk IO or My/SQL connection.
There are a lot of little things, like combat, turn priority (action points) and so forth that need to be implemented. And then, you will be able to play the game, in the sense that there is some kind of game world and you can move around in it and interact with it's rules. At that point we move to the content stage.
Content will be drawn from a large number of sources, but will shortly overtake the codebase in terms of size. Variety, do not forget, is the spice of life.