Until the train game code is working well enough to play an actual game, I’m tempted to do no 3D work. I’ll need an interim user interface and so far, that has not been a problem. It has not been a problem because there has been no real user interface besides what Windows provides and a few point-and-click features. Now I need to think about how the game will eventually work and make Windows dialog boxes and other items that work in the same way.

I’ve already started to think about this and what I have so far is an idea and a rough prototype for using modeless dialog boxes that are positioned to look attached to the main window. If the window moves or is resized, I move the modeless dialogs. When a feature is needed, I display the right dialog and hide the rest. As long as I don’t need more than one at a time, this should work.

The test dialog for this is the train route dialog. I already had a way to create a route but there was no way to edit it. The details for each waypoint were fairly hard to understand but it didn’t matter because I was just testing the underlying code. Now, I need to have multiple line and pictures to go with each waypoint. I’ll show the train as it will appear after all waypoint actions are taken along with descriptive test about stopping before/after/etc. and coupling and decoupling. Or is that UNcoupling?

samplemodeless.jpg

Here, the modeless dialog can be seen attached to the window. It has been placed, using SetWindowPos() to be at the top of the status bar and on the right side of the client area of the window. I handle both WM_WWINDOWPOSITIONCHANGING and WM_WINDOWPOSITIONCHANGED messages so that the modeless dialog sticks to this location as if it were some sort of child window. It is also set to be the topmost window of my process.

I intend to make each of the dialogs look and act like this. Of course there will be some more useful content in the dialog box.

In a final 3D version of the game, the user interface will probably be similar to this and the user will route the train using the 3D window to place waypoints while they use this popup dialog box to review and edit them.

Coupling Issues

If one train drops off cars on Tuesday and another train picks them up on Wednesday, how will the train picking them up know at routing time what cars are there to pick up? This is a bit of a dilemma when it comes to showing the user their train at each waypoint. The code cannot know what is at the specified location, especially if the other train has not even been created yet. I can’t even know what cars are in inventory until they have been bought during a train creation operation.

I plan on letting the player tell the game what cars are expected. The player should see a list of cars in inventory and then be allowed to pick cars that are not yet in inventory so that he can create the route to handle another train that he has not yet created. Yuck. There should be an easier way and I’m thinking that the player should “buy” the other cars at the time the train route is planned that picks them up. Then when the other train is created, the player can see them as being in inventory but not yet used. In other words, cars and locomotives are bought at the time a train route is created and the initial set of units is picked. Units picked up at other waypoints can be picked from the entire known inventory but also from the entire set of units that the player can purchase. If units are purchased but are not part of the initial train, they are later shown as already purchased when the player creates some other train.

Making this a payable game while also working a bit like a real railroad is tricky. I can see why no one else has sold a game like this. It may be a pain in the ass to play!