Category: Blog

Today’s subject: trams.
Or rather what’s supposed to be and behave like one.

In the last couple of days, I was busy implementing a new system that supports not only cars, but multi-axle, multi-carriage vehicles like trucks, trams and trains.
The first vehicle I built to test this was a tram.

Now, game development can be very frustrating at times. Things don’t work the way you want them to and you have to dig for that one variable you set wrong, that one object that is not in the right place, or that one checkbox you forgot to check. The last couple of weeks, I struggled to get things right with the Unreal Engine physics system, in order for the carriages and the axles to follow the path in a realistic way.
Add a little tenacity and a couple days of frustrating try-and-error, and all of a sudden things start to work!
Well, kind of…

Check out this video of the current state of the trams:

Now don’t worry, this is not the final state. But one that I almost feel sorry for fixing!

Wow, it’s been a while since I last posted here. I haven’t been living under a rock, but I was very busy developing Stop, Ampeltime! in Unreal Engine 4.
It took me a lot of time to set up the base systems of the game, and that part is never much fun to watch. There’s not a lot of visible progress, sadly. That’s why I decided not to post about it and instead use that time and energy for development.

But now I feel that the game has gained enough content to share it with you.

As development in the near future will be much more content-focused (more on that in another post), it will be a lot easier for me and a lot more exciting for you to read about it here.
If you haven’t done so, please subscribe to the Stop, Ampeltime! newsletter to keep up to date about major development milestones and to gain exclusive access to future alpha/beta tester programs.
You can also follow the game on social media:

Having said that, it’s now time to catch you up with the development that happened since the last post.

(in a narrator’s voice 😉 )

Previously, on Stop, Ampeltime!

Since I started developing Stop, Ampeltime! in Unreal Engine 4, a lot of core systems for the game have been set up. There’s a whole bunch of stuff that Unreal Engine 4 already provides, but if it’s not a standard first or third person game that you develop, the initial effort to create the game systems is a little bit higher.

Game Systems

I’ll give you a brief rundown on the current custom systems that are in place right now:

Path System

The path system is a flexible system that allows me to draw paths that vehicles, people or goods can travel on. Right now it is mainly focused on roads, but it is design flexible enough to support a plethora of path types in the future (sidewalks, rails, waterways, etc.). The base unit is a path group that supports one or more lanes grouped together. The lanes can have individual widths, height clearances, speed limits and markings. The path system is the core system of the game as vehicles can use it to get from A to B.

Vehicles

Vehicles all share a common base that contains properties such as capacity, acceleration, top speed, but they also share a base AI that handles how the vehicles behave on a path. The AI currently is at a basic level, so there’s a lot of room to implement more detailed behavior and make adaptations to special circumstances.

The vehicle AI closely works with the…

Routing System

This is one of the more abstract systems in the game. It handles the routes that vehicles, people or goods can travel on. To build that knowledge, it takes all the start and destination points on all the paths and starts to build a map. From this map, it can then calculate routes that lead from any starting point to any destination. It gets a little complicated because there can be more than one route to a destination, and the paths to go there can have several lanes. This system is working for now, but still has a lot of features and intelligence to be added.

Environment System

The environment system handles any objects around the paths that the player cannot control or only has indirect influence on. It’s currently only used to plant trees on the terrain, but in the future, it will also handle houses and other procedurally generated structures.

Vehicle Management System

The vehicle management system takes care of what vehicles get spawned where and decides where the vehicle will go. When it’s time for another vehicle to enter the game world, it takes a look at all the destinations and at the rate people or goods want to go there, then decides on the destination and sets the vehicle into the world.

Intersection System

The intersection system is another core system to the gameplay of Stop, Ampeltime!. The player is free in designing paths and intersections. The vehicle AI and behavior on the other hand are very realistic – vehicles have realistic acceleration and braking distances and if two vehicles overlap, they will crash. That’s why the game needs to be good at detecting intersections and providing the vehicle AI with accurate information on how to approach an intersection. The intersection system is almost finished and only needs some cosmetic improvements.

These are the main game systems that are currently in place. There are some other, smaller systems in the game. Most of them handle visual things, from to 3D meshes to UI stuff.

Current State of the Game

The current game is very close to a first, playable version. The player can create, manipulate, split and join roads, add and remove lanes. Vehicles are driving into and out of the level. They stop at intersections and respect the right of way that the stop markers at the intersections are configured to. So there’s quite a few things that players can already experiment and have fun with.

I’m currently working on making the whole game system more stable and bug free so people can play it at GDC 2018 in San Francisco.

What’s Next?

After I polished all the existing systems and been to GDC, I want to start a ‘content offensive’, where the game and its systems are filled with more content. The game system has been laid out to be very flexible, so I’m looking forward to implementing new vehicle types, new path types, and some new environment objects.

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.

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!

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 🙂

First car movement!

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

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 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)

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.

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.

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!

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!

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!)

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.