[ Content | Sidebar ]

Archives for traingame

Train Valley

December 16th, 2015

I’ve been playing this game Train Valley a lot recently. It’s a train puzzle game where you build tracks between stations and then madly switch the points around to route trains to their destinations while avoiding crashes.

train_valley

I think it really captures the aesthetic I was going for with my somewhat moribund Train Game. The puzzle mechanics are really fun though – wish I’d come up with it!

New TrainGame release

September 8th, 2012

It’s been ages since I did much work on my unimaginatively-titled train driving game. Surprisingly some people have actually been trying to build the last release and it turns out anything using Boost bit-rots at an alarming pace. So I’ve bundled up the latest working version as TrainGame-0.2.2.tar.gz.

It’s not all build fixes though. Looking through the log for the past few years I’ve done plenty of optimisation and prettied up the grass as I explained previously.

To build and run after extracting the archive you’ll need to:

cmake .
make
./bin/TrainGame play figure8

You’ll need a recent-ish GCC or Clang and Boost.

More or Less

April 10th, 2011

I love More or Less on Radio 4. I did squee so much when it came back for a new series. It isn’t easy to make statistics both fun and intelligible.

Also, I got horribly sunburnt yesterday :-(. But only on the top of my arms and face and not where my watch goes so is both daft and painful. Grr.

Also, I have a TrainGame-derived maths problem: let’s say I have a three-dimensional Bezier curve (X(t), Y(t), Z(t)) defined for 0 <= t <= 1. In my case this defines a track segment and works admirably for rendering the track. However it also determines the position of the train on the track at some time t. The problem is, with the train travelling at a constant speed, it appears to speed up or slow down depending where it is on the curve. It turns out that most of the time this doesn’t really matter, but sometimes it does.

What I would like is for the t parameter to be linearly related to the distance travelled along the curve; so if A is the arc length between two points A(0, s) = s * A(0, 1). Unfortunately, Bezier curves don’t possess this property and there’s not even a closed-form solution to A. So I’ve had to write this crude and slow approximation to such a curve given a normal Bezier curve as input:

http://git.nickg.me.uk/?p=traingame.git;a=blob;f=include/BezierCurve.hpp;#l84

It works by assuming that (X(s), Y(s), Z(s)) should be sL units along the curve, where L is the length of this track segment. It then approximates the curve by lots of little straight lines and moves t along the curve summing lengths until it reaches sL. Then we evaluate the curve at (X(t), Y(t), Z(t)).

So the question is, mathematicians of the interwebs, is there a better way to do this??

TrainGame updates

February 19th, 2011

I’ve been quite silent about TrainGame recently, but it’s not dead! I have been working on it a little bit – here’s an up-to-date screenshot:

The most obvious change is the new green train! Eventually there’ll be multiple trains driving around and you’ll have to take care not to bump into each other.

I’ve also been trying to make the ground look more realistic and less dull. After a few failed attempts I’ve settled on using a procedural noise texture to make the grass look more interesting. Seems to work quite well for little overhead.

A bit more subtle, but I’m slowly replacing the various existing track types with a single spline-curve track element. This means the track is no longer constrained to travel along the X or Y axis – you can see the train travelling along some diagonal track in the picture.

TrainGame 0.2.1 released

June 6th, 2010

TrainGame 0.2.1 is now available! This version is functionally identical to 0.2 but the scenery and track rendering code has been almost completely rewritten to improve performance. You should see an increase in frame rate of around 2x with a low-end integrated graphics card (e.g. Intel GMA) or 3-4x with a GPU which performs hardware vertex processing. The downside is that a lot more memory is consumed, both system and GPU. However, the overall memory usage is still fairly low so I’ll implement a caching system when this becomes a problem.

A crash when saving a map in the editor has also been fixed.

Download the source code here: TrainGame-0.2.1.tar.gz

See the TrainGame page for instructions on compiling and playing.

Train Game 0.2

April 18th, 2010

I feel it’s about time I released another version of Train Game: so here it is, version 0.2! Like it’s predecessor this version isn’t really playable in any sense, but you can drive the train around a bit. Here’s a screenshot showing the two major new features: trees and uphill track:

Building and Playing

This version is source-only and will only work on Linux/*BSD without significant tweaking, although I do plan a Windows version at some point.

First, download and unpack TrainGame-0.2.0.tar.gz.

In the TrainGame-0.2.0 directory, run:

cmake .
make

You will be notified of any missing dependencies. Note that FLTK is no longer required. Do not run make install! It’s currently designed to run in-place.

To play:

./bin/TrainGame play demo

You can substitute “demo” for anything in the maps directory such as “figure8” or “uphill”. If you want to create or edit a map do:

./bin/TrainGame edit mymap --width 32 --height 64

The controls are quite simple:

  • The up and down arrow keys control speed.
  • The “b” key toggles the brake.
  • The “r” key toggles reverse but only when there is no power applied.
  • The left and right arrow keys change the direction of points when you are near some.
  • The tab key switches between bird’s-eye, floating, and fixed camera modes. Use the mouse to move the camera in floating mode, then hit tab to lock it in fixed mode.

Plans

So, I’m thinking of where to go with Train Game now since the project seems a bit direction-less and perhaps that explains the slow progress.

My current thinking is that there will be two game modes: “challenge” and “trading”.

Challenge mode involves you completing various train based tasks. There are two sub-modes:

  • Timetable – drive a passenger train along a route trying to stop at stations at the correct times and also make the passengers’ journey as comfortable as possible (i.e. no sudden starts/stops). This style of game seems very popular in Japan.
  • Delivery – you are given a series of increasingly difficult delivery tasks to perform with a strict time limit. E.g. “collect 10 units of wood from X and deliver them to Y in 1 minute” or something like that.

Trading mode is a bit more open-ended and also has two sub-modes:

  • Capitalism – you buy and sell goods at different stations. There’s a simple market economy which fluctuates with your actions. It’s a bit like a train-based Elite. With the money you earn you can buy new trucks, upgrade your train, etc.
  • Socialism – there’s no market but you score points for heroic actions such as transporting goods over long distances at high speeds. There are also randomly generated “quotas” that work a bit like an extended challenge mode. The details still need to be worked out…

In both these sub-modes you compete against other AI controlled trains, or maybe even other human controlled trains.

I’m also considering renaming it DoofTrains to make it sound a bit less generic.

What do you think, readers?

Trains on hills

March 5th, 2010

After a flurry of Train Game development the train now goes up and down hills!

Unfortunately all is not quite right in train land as sometimes when going up or down a steep hill the train intersects the waggons or goes way out in front as if on an invisible elastic band rather than a rigid coupling. More work needed I think.

Some thoughts on trees

February 27th, 2010

I’ve been wondering for a while now what is the best way to add trees to Train Game. Trees seem fairly important for a train game seeing as trains mostly travel through the countryside where there are trees. (Except for my daily commute to work through Slough where there are no green things.)

Anyway my first attempt was to use flat quads with an alpha-blended tree textured onto them. These are commonly called “billboards” if you didn’t know. The quads are then oriented to always point at the camera, hopefully giving the illusion of a fully 3D tree. While the maths to calculate the billboard orientation is a bit tricky, these trees are incredibly cheap at runtime. Blodgett was kind enough to use its artistic talents to produce some tree pictures for me:

While these trees look quite good from a distance, when you get up close and especially when look from above the rotation and obvious flatness is a bit disconcerting.

So next I tried a completely different approach to tree rendering. Inspired by examples of procedural plant generation e.g. here and here I implemented an L-system tree generator – albeit a much simpler one than in those examples. Here’s a screenshot showing some examples of trunks and branches:

I think these look rather good. Unfortunately there are two problems: rendering them is incredibly slow, and I found it very difficult to generate decent looking leaves. Since trees are only scenery and I’d like to have a lot of them on the screen at once, it’s not really acceptable to have them use more of the render-cycle budget than the train itself. Simplifying the branch structure and using square leaves, plus some OpenGL performance tricks, gets them running at a reasonable speed, although they don’t look nearly as good:

Incidentally, these screenshots are showing the new map editor which ditches FLTK and replaces it with my own home-made XML GUI toolkit. I’m rather pleased with it design-wise and it plays much nicer with the rest of the game (it renders directly onto an OpenGL texture).

Anyway, back to trees and my conclusion from the L-system experiment is that I didn’t like them that much, they were expensive to render, and perhaps most importantly, they didn’t fit in with the rest of the artwork in the game (in the “childishly cartoonish” style). So I abandoned the code in a git branch and went for the simplest option: make some models of trees.

Thus far I’ve made two tree models – a pine tree and an apple tree – both around 80 polygons. They are very cheap to render – cheaper in fact than the billboard trees since I have an optimised VBO-based mesh renderer.

I really do like these trees! I think they’re cute but I’m a little worried other people will think they’re daft. Anyway, I’m sticking with them for the time being.

In a month or so I will tidy up the code in git and release another demo/preview version. Hopefully there will be some useful features by then ;). In the meantime you could look at my gitweb if you’re curious or clone http://www.nickg.me.uk/~nick/git/traingame.git.

Thank you muchly to blodgett for assisting with tree evaluation!

Train game update

May 23rd, 2009

A screen shot from the latest version of the train game. I’ve added smooth shading, water, earth, and more realistic colours for the ground.

screenshot_mountain

I’m currently trying to think of a name: “Trains!” and just “Train Game” I’ve considered. Not entirely happy with either. Unfortunately “Trainz” is already taken.

A game about trains

May 18th, 2009

I’m currently writing a game based on driving trains. The idea is that you will be able to collect cargo, drive it around, and deliver it for profit. Winner is the one who makes the most money in the time period. You’ll be able to select the engine type: bigger engines are faster, but you need to buy more coal and water for them; and select the number of trucks: more trucks carries more cargo, but the train goes slower. Controls are fairly simple: shovel coal and adjust the throttle/regulator, but you have to be careful not to let the boiler pressure get too high or low or disaster strikes!

It’s in the very early stages of development at the moment, but I have a working map editor and you can drive the train around a bit. Here’s a screen shot of the current state:

Train game early screen shot

More info soon!