Category Archives: Blog

Curved Paths

Development has been progressing slow but steady in the last couple of months.

Currently I’m working on the paths in the game (roads etc.) and how they can be laid out. The goal is to provide a user interface that is as easy to use as possible while keeping relative freedom in what you are able to design. So right now it’s a lot of vector math, angles and trying to figure out how to write intelligent algorithms that can connect to points on a path.

Stay tuned!

Development has picked up some speed

This won’t be a lengthy post. I just wanted to note that in the past couple of weeks, Stop, Ampeltime! development has picked up some speed and is now progressing at a slow, but somewhat steady pace. There’s a lot of background work going on – nothing presentable or terribly exciting, but it’s progress!

I’ll keep you posted. And thank you for your patience 🙂

I’m making some progress!


It’s been quite a while since the last update (over a year… wow!). There’s been a lot going on in the last year that kept me from programming.
But now I’m finally making some (visible) progress. So… enjoy 🙂

A gif of the first car movement in the new engine.

First car movement!

My progress is a lot slower than that car. But hey, any v > 0 will eventually get you there!

Switching from Ogre3D to Unreal Engine 4

With the announcement of Epic to offer the Unreal Engine 4 as a subscription service for a very reasonable price, I decided to switch from Ogre3D to Unreal Engine 4. Although I’ve already invested a fair amount of time in setting up the Ogre3D environment and development progress with the Ogre3D engine was ok, the decision was made quite quickly.

This was due to the following reasons:

  • One of the major selling points of Ogre3D for me was the integration of Flash contents. However, the Hikari library I was using was leaking memory heavily so it became unusable. I tried switching to the Akarui library, a similar library based on the NP API, but I didn’t succeed in making it work for my non-managed, c++ Ogre3D build.
  • The Unreal Engine provides a VERY powerful editor that should speed up the game development and content creation process.
  • The quality of the Unreal Engine is top notch.
  • UE4 is a well-rounded package of everything a game needs (graphics, sound, physics, networking etc.) – no need to evaluate a library for every single thing.
  • UE4 has a growing, large and active community.
  • I can live with the 5% royalties.

Being able to incorporate Flash as a UI however is a very important factor for me, so I’m looking to find a way to do this with UE4. There is of course a Scaleform integration available for UE4, but possibly at a quite high price (pricing is done per-project). There’s a Unity3D integration for a more reasonable price, so I’m hoping with UE4 gaining more and more popularity among indie devs, Autodesk may offer something similar for UE4 in the future.

To summarize, it’s a pity that I lost all the time and effort invested in Ogre3D, but I hope the switch was worth it. I could port some of the code to UE4 and the experiences made with Ogre3D are still worth something.

Project Requirements & Plan of Action

Project planning is essential to any bigger project. It diminishes (though not totally eliminates) the chance of losing track of things and helps you to structure your work. I’m not planning in doing this formally correct for the Stop, Ampeltime! project, but I need to do it in some form. This post may be a bit chaotic and bloated with all kinds of different information, but it will be a first crude step to planning things out more structured than ‘just in my head’. So I will try to list all the things I need for the project and provide a general idea in which order I’ll try to do them in. You can think of these items as ‘product backlog items’ as they are called in the agile software development framework Scrum, if you will.

I suppose this plan may have many flaws and errors. Some of them will be corrected and adapted over the course of the project, but if you have any suggestions on things to avoid, things to NOT do like I planned, things I forgot about or any other advice, please feel free to leave a comment!

From a technical standpoint, right now all that is fixed is the graphics engine (Ogre3D) and an idea of what platforms the game should run on (Windows, Mac and hopefully Linux too). There are a lot of technical components that yet have to be chosen. So what else do I need?

  • GUI framework (evaluation in progress, probably Gorilla)
  • sound engine/framework
  • physics engine (vehicle collisions on faulty intersections and maybe a good set of functions that are helpful with other calculations in the game)
  • networking component/library (login to server, highscore upload, level up-/download, betatester-feedback function)

Feature-wise, there’s a lot to do. Here’s a list of some of the features I can think of implementing, in order of implementation:

Basic Functions

  • mesh factory, with the following functionality:
    • terrain generation (flat)
    • street generation (3D spline to x-lane road)
  • basic GUI elements
    • label
    • button
    • text field
  • street building:
    • interface (crude)
    • create vehicle emitting and consuming street parts
  • basic level data structure
    • save & load levels
    • define incoming/outgoing vehicles
  • basic vehicle AI
    • vehicles accelerate, brake, drive to speed limit
    • inter vehicle communication (vehicles react to preceding vehicle’s actions)
  • intersection detection
    • stop marker creation
    • lane blocking & unblocking system
    • right of way detection
  • basic traffic regulating elements
    • traffic lights
    • stop markers
  • visual debugging tools
    • modular 3D info pane for game objects
  • improve vehicle AI
    • stop at intersection stop markers
    • use turn lights
    • use horn
  • basic game stats tracking
    • vehicles that passed through the system
    • traffic jam length (m)
    • total & average vehicle waiting time
  • routing intelligence
    • detect routes & create route list
    • calculate chance of route being chosen based on level data
  • basic game logic
    • start/stop/reset simulation
    • simulation run time
    • evaluate simulation: pass/try again

After completing the basic functions, the game should be about on the same level as the flash prototype (regarding gameplay). It I will not directly port code from the prototype, but generously borrow concepts and algorithms from the existing code.
At this stage I’ll try to keep everything graphics and GUI related as simple and open as I can. I plan to collaborate with a more skilled artist than me to create the GUI/menus and the graphics, so I try to put the least possible effort in creating such things at this stage and make sure no possibility is obstructed for creating any type of graphics/GUI.

Advanced Functions & Visuals

  • extend terrain generation
    • use height map
  • extend street building:
    • streets follow terrain
    • bridges, tunnels
    • streets modify terrain
  • extend mesh factory with the following functionality:
    • procedural building generation, simple buildings (place buildings adjacent to roads, use maximum space)
  • enhance graphics
    • screen space ambient occlusion shader
    • create materials for different level elements
  • more vehicle types
    • tram
    • bus
    • train
  • improve vehicle AI
    • change lanes
    • overtaking
  • implement physics for collisions at intersections
  • more gameplay elements
    • traffic counters
    • triggers
    • create tram/bus/train lines
  • level design
  • model 3D objects
    • building parts
    • street parts
    • bridge parts
    • tunnel parts
    • trees
    • environmental objects
  • basic online functions
    • game database
      • users
      • levels
      • highscores
    • user login via game
    • user registration
    • highscore & level upload
    • level download
    • beta-user feedback function (bug reports including screenshots)

The items at this stage are a little less ‘sharp’ and complete, as they lie further away from the current point in time. They will be specified more clearly when this stage is reached.

Finalization & Extra Features

  •  GUI design
  • menu design
  • add sound & music
  • level editor
    • Google Maps integration (create levels from Google Maps imagery and terrain height data)
  • website redesign
    • user login on website
    • purchase game/beta
  • more levels
  • bugfixing

The items at this stage are even less sharp than the previous ones. When the game has reached this stage, many other tasks and to do’s will have arisen.

This list will be completed and maybe re-posted at a later stage of development when substantial changes have been made to it and/or substantial progress has been made.

Tagged ,

Embrace the Social

In order to keep me motivated and potential readers and fans entertained, I will now and then try to tweet about the development of Stop, Ampeltime! in addition to blogging. But please bear in mind that this project is (for now) developed in my spare time and the amount of time available varies depending on my situation at work, family etc.

First Tweet

You can follow me on Twitter right here: TaurusI76

When time has come, I will also create a Facebook page for the game, but this can wait until a playable version is available.

Tagged , ,

Prototype Bugfixing: Roundabouts, Collisions and Music

Recently I got some feedback on the game that motivated me to do a couple of fixes and enhancements to the Stop, Ampeltime! flash prototype (the one playable here).

There was a bug in the prototype code that prohibited players from creating roundabouts. The code scanning the streets and looking for routes for the cars to drive got stuck if a loop was created in the road system. Luckily, it only was a small check that I had to implement. So creating roundabouts should now be possible. Let me know if you still encounter problems!

Prototype Roundabouts

Another issue arising with the new possibility to create roundabouts was the right of way, or the lack thereof. In the current prototype, cars only stop on traffic lights and don’t respect the right of way – something that will be added in a future version of the game. But for now, in order to complete a level with a roundabout in it, you can disable the collision checking in the settings menu. This of course makes the game a lot easier and unrealistic, so only disable if really needed!

New Prototype Settings

A final concern was the music that wasn’t to everyone’s taste and that now can be muted in the settings menu.

I’m not planning on doing any more changes to the flash protoype. Instead, I will focus my energy and time on the new and enhanced 3D version of the game.
Stay tuned!

(Edit: Clear the cache of your browser to make sure the new version of the flash file is loaded!)

Tagged , , , ,

Dev Blog Started

Today I’m starting to blog about the development of Stop, Ampeltime!. Or TrafficSim2, as the project is called internally. Why 2? Because it’s a new chapter, and a new beginning in many ways.

Stop, Ampeltime! in the form that it exists in now was entirely designed and programmed during my studies for game design. It began in the second semester as a project for the Flash/Action Script module and ended up being my bachelor’s thesis at the end of the three years of studies.

The project itself was very interesting and fun to make. And it required a lot of thinking, planning, writing of code, rewriting of code, re-designing of whole ideas. Well, the re- part of things was not planned, of course. But every redesign was necessary to get to the point the game is now. For a long time, I thought that using Flash as a game engine was the right thing to do. It felt cool, because many people don’t like it (despite they use it a lot, unwittingly). Like the underdog of game engines. Well, not exactly, because there are tons of Flash games out there. But not many that go deeper or are more complex than arcade games. I thought that Stop, Ampeltime! could be one of these games that stand out. Now I know that this was kinda silly. Flash has its restrictions, and I knew of them from the beginning. But it was not until the end of the bachelor’s thesis that I was fed up enough to decide to switch engines.

So now this is what I’m doing. Saying goodbye and farewell to Flash and switching over to… C++. I hope that a lot of the ideas in the original Action Script code can be used more or less in the same way in C++, because I created some nice OO structures. And if not, I try to make the best out of it and re-engineer the code for the better.

What am I hoping for the switch to bring?

– faster speed in general
– benefits from multithreading
– better graphics (a blog entry covering the choice of graphics/game engine will come soon)
– more build targets (without the whole Flash being a requirement thing)

So I hope this is the right direction that I’m going in. Further developing in Flash certainly didn’t feel right!