When I was at Electronic Arts there was a legend about a function in FIFAÂ called DoBestKick. It was the ur-function for determining what kick an AI player would do. The story tells that no one really understood the inner workings of the function and that the mandate was “no one touch DoBestKick.”
I have a similar function, WhichWall. It determines, based on the orientation of the walls in a square and the orientation of the walls in the neighboring squares which wall to draw: inner corners, left corner, middle, solo, etc. There are 52 possible combinations with dense conditions such as, if this wall is north facing and there is an east wall and the western square has no east wall and the north-western square has an east wall then this wall is an outside corner skewed to the left. If at all possible, I did not want to revisit that function. We don’t always get what we want.
There were two new features being added to the map editor; 1) adding map objects that are not walls or floors, and 2) saving and loading the maps as XML files. These two forced me to touch WhichWall.
Simple UI added to the right-hand side.
(Click to enlarge.)
During the re-factor of the map code, I concluded that storing the wall conditions as properties of the map square wasn’t very efficient. Moving them to an array of booleans let me access the walls with the same logic I use for pathfinding movement. This let me greatly simplify all of the wall handling. This meant reworking WhichWall.
Adding arbitrary objects to the map meant adding a new class to the map squares to hold those objects, both for rendering and for storing in the XML files. It made sense that the walls would also be part of this list of objects. Reason two for revisiting WhichWall.
The in-game map with columns.
(Click to enlarge.)
At last, success. Though I only have one type of extra object at the moment ( a column), I can now add non-wall objects in the map editor. I’ve also done the calculations for which wall in the editor and save that information in XML file, eliminating the need to determine which walls should be added when the file is loaded.
Time to layout the Big Map in the new map editor, 12 minutes. Not as fast as I’d like, but much better than editing by hand. I have some specific ideas to speed up map editing, but those will have to “go on the list” for now. I have enough of the basic features in place that I have to dive into networking.
oh, networking fun
every time i read an explanation for why something was done a particular way … i remember why i steered clear of anything more complicated than database work
efficiency sucks and requires too much math … bring on the quantum computing
12 minutes is a very good time for the size of the map.
My memory is that GMs are not building maps in real time. Could almost be an option at these speeds, although they’d be basic.
Typically, I don’t expect that maps will be done in real-time, but there are times during play that you’ll want to be able to do that. When the players wander into some location you weren’t prepared for, you’ll want to be able to “sketch” a quick map.
The biggest boost in speed that I will get is adding “carpet bombing” of floors. Rather than click-dragging and adding a floor tile at a time, it would be click-drag to opposite corner and the floor would be filled in.