Development Hiatus

Due to a lack of funding, Stop, Ampeltime! has been on a development hiatus since March 2020 and will continue to be until further notice.

A test-version of the game with a limited feature-set is almost ready to be tested by supporters of the game, with only a few major bugs left to be taken care of before testing can begin.

Unfortunately, my current work situation makes it hard for me to find spare time to work on Stop, Ampeltime!. This is why development currently remains paused. Stay tuned!

Trams are coming!

Hello and welcome to one of my sporadic posts!

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!

Stay tuned for correctly behaving multi-carriage vehicles coming soon!

Previously on the Stop, Ampeltime! Show…

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.

Stay tuned for more updates soon!

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!

Hi

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.

Talk & Exhibition @ Showroom Z+

On March 7/8 2014 Stop, Ampeltime! was on display at Showroom Z+, an exhibition series at ZHdK’s Dittinghaus in Zürich. In addition to the game that could be played, I had a talk about the development of the prototype and future prospects.

I know I’m a little late on this (as the exhibition is already over). But for the sake of completeness I’ll list it here anyway.

There’s also a flyer and some additional information about the exhibition.

Talk @ Showroom Z+
Philipp Kuhn talking about Stop, Ampeltime! @ Showroom Z+, Zürich

Thanks to everybody who came to visit & listen!

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.