top of page

A tech demo for a prototype traffic infrastructure solution


Probably the most extensive and most relevant project I worked on was a technological demonstration demo, made in Unity, for Vehicle-To-Vehicle communication technology, or V2X; something Siemens has helped develop for a few years now. The basic concept behind the system is to provide drivers with additional information while they drive. The infrastructure goes quite in depth into what sort of extra details are provided to drivers. Some of this information is already available and used, for example, for traffic management, and some of it must be gathered using new technology. Some examples of the sort of information you could get once V2X is available are traffic light timings (a countdown to when the light will change at the next junction), speed limit warnings, the approach of an emergency vehicle, advance notice of a queue on the road ahead, etc.

In the demo I developed to show this off, I explored some of these warnings and tips and provided an interactive environment, in the form of a driving simulator, where the system can be tested and shown off to the public at a traffic-themed convention. The idea was to give a sneak peek at what is going to be available in a few years’ time to customers in their motor vehicles, as well as to gain the interest of automotive companies to partner up with.

Challenges and things I learned

What was originally a 4-week assignment to be completed for a single traffic expo gained so much attention that it became my main project during the year, and I have put more than 5 months into its development through 3 major iterations (localisation and content updates).

This has proven to be quite a challenge even on the first iteration. I have made a conscious effort to take part in lot of game jams at university and elsewhere to get hands on experience with project management and developing a game to completion, which has given me a good grasp on potential compromises (who needs audio in a game?) and the importance of planning, but the longest game jam I ever took part in was 48hrs. In comparison, 4 weeks seems like an eternity, and this had tripped me up quite a few times. It took almost the entire development time of 5-6 months to learn to manage my time better and to part with some bad practices I inevitably picked up during game jams, like spending too much time with a single element of the game or underestimating how long something is going to take. I had to convert my brain from thinking in hours to thinking in weeks, which I had found quite difficult. It took me some time to realise that a lot of the company worked on that time scale, and to adjust my project plan to that level myself. Although, with the second iteration of the game, I managed to overshoot in the other direction to where I proposed the inclusion of dozens of advanced features to be implemented in what I had learned later on is not enough time. Some of the ones I did manage to include were a procedural road generation tool that I have used during level design for the game, and a basic pedestrian artificial intelligence system to simulate foot traffic in the virtual world. It took me a few tries to wrap my head around it , but the last iteration of the game I worked on was one where I managed to include everything I wanted in a reasonable time, as I learned to recognise when certain elements of the game were up to standard and save lots of time by moving on before everything was perfect. I expect this will have an effect in my final year assignments and my dissertation, and no will doubt lead to a better quality of work overall.

In Conclusion

Pulling off something like this on my own has proven to be extremely helpful in terms of the experience and skills I developed. My efforts were officially recognised by Siemens when I was awarded a bronze, and later a silver level champion’s award; a recognition of outstanding performance and contribution to the company.

bottom of page