Last night, I was messing more with the automatic rules for placement in the region editor. I got it so it determines if a tile is considered flat or not (there are some minor bugs). In the following picture, the blues are places you can put a tile, red are too steep for a tile.

I also started the scenario editor. The first part of the scenario editor is placing of buildings, this is also used in the game. At the moment, I’m going to just create a “plate” at large as the building being placed and let the player see where it can or cannot be placed. That should give me a good basic start on this entire process.

Ideally, when you move the mouse around (while holding the spacebar at the moment), it will move the plate around and turn it blue when you find a valid spot. You can rotate with the right mouse button. However, there is a little bug with the Irrlicht.NET CP code (that will be fixed as soon as it gets into SVN, I think) that prevents me from finding where the mouse is over; that should be fixed “soon.’ and I’ll be able to move forward with this.

This weekend, I spent a good amount of time trying to figure out how to place buildings in the game. The approach I decided to go with basically creates a “tile” that will match the terrain of the map. The rules of for the tile (such as if it is too steep or if it gives bonuses) will be set in the region editor while the scenario editor will be used to set the default building layouts.

This took me quite a bit to figure out and I’m still not done. The rules for how steep aren’t in there (I’m going to stay steep if all four corners aren’t the same height) and I really want to get the building placement stuff done.

But… some screenshots:

The following screenshots are the retile process. Basically, I just take all the tiles and put them at the highest hight, then drag them down until they hit ground. It isn’t really fancy or anything, but at least approximates the ground layer. The most important parts are when there is one or more tiles at the same level, which there are regions that have that. Those are where the building placements are going to be in the scenario builder. The white tiles won’t be visible to the user in any other stage, this is just for setting region controls.

Being the end of the month, and a few days before GenCon and my birthday, I sat down and trying to see where Turf Wars was going. I got enough of the game to actually see it and, while I was pretty happy with the view, I think I would have trouble making the game “fun” as opposed to just a challenge.

So, giving that view of things, I think I have an idea of how to change the game around so it can be “fun” or at least closer to games that I’ve enjoyed in the past. The micromanaging of the vassals needs to go, that was getting too difficult. The orders will probably stay, but change in their format.

I think I’m going to start with the building arrangement. In the current version, all buildings were 30 meters by 40 meters, but I think I want to have more irregular-shaped buildings, along with the ability to lay them out. Maybe have what you can build based on the businesses in the area (you need a road construction company to make changes to the roads, an aborist (can’t spell) to remove or plant or purchase plants, etc).

I also browsed through the various game engines, it appears to be either Ogre3D with OgreDotNet or Irrlicht.NET. I’m going to start with Irrlicht.NET and see if I can managed to get most of the game out.

Well, in my off hours, I’m still working forward on Turf Wars (TW). This is hopefully going to be my submission to the GameDev’s 4E5 contest. I decided to start with a basic Model-View-Controller (MVC) approach to the development. The model is the internal engine, TurfWars.Engine and related classes. It actually has details for every single game element in the game.

It also keeps track of what players knows what. The main reason for this is to give the ability to have a snapshot view (how much money does my enemy have now?) that doesn’t automatically update over time. So, you might have some “stale” information about your opponents which may or may not be still accurate. Of course, trying to keep up all the details is also hard.

To handle this, I created a series of View classes. For every component, there is one view for every player. Well, technically if the player doesn’t know about it, there is no view for it. This is the part I need to focus on and clean up at the moment, but it seems to be fairly progressive in details. You’ll see from these screenshots that the two windows show different things. Both players know what “AI #2″ has for favors, but not each other.

The other major part of the application is the ability to handle time. I decided that the model is semi-continious. This means that it handles event over time. I set up the front end, however, to be either real-time stragtegy (RTS) or turn-based strategy (TBS). The difference is that the TBS will just advance 24 hours (or 6 or 12, whatever) at a time while the RTS version does incremental changes every tenth or hundredth of a second. I put in a little bit of code that automatically gives money to the user over time, so you can see the results. These images show money over time, look at the “current time and date” bit to see the advancement.

Still encouraging on the development side. I’m going to focus on the model of the application, then work on a “prettier” front end using the Irrlicht engine for 3D graphics. This is a major undertaking compared to WordPlay, but I also think that it is in my skill set and I won’t have to give up “too much” to get it working. Not to mention, it has to be done by the end of November, so I should have enough time.