Built using Unreal Engine 4. The gameplay is programmed in C++ and UE4 Blueprints. Worked as part of a 10-man team.

Project summary

This project is the result of 8 weeks of work by a 10-man team. The goal was to develop a game based on a classic game from around 1985. We chose Bomberman. The project runs on Unreal Engine 4 and is written using UE4 Blueprints and C++.

Most important things I learned

  • Working with Unreal Engine 4.
  • Building a project with a medium-sized interdisciplinary team (10 team members: artists, designers, programmers, and producers).
  • Effective use of Perforce.
  • Building a game from start to finish.

Role:Gameplay Programmer
Duration:8 weeks
Skills:UE4 Blueprints, working in large teams
Software:Unreal Engine 4
Team size:10 team members


The final trimester of my first year at university was dedicated to building a game using Unreal Engine 4. The game had to be based on a classic arcade game from the time period 1980 – 1985.


For the first time ever, we had to work in an interdisciplinary team. This team consists out of artists, designers, and programmers. Even though we have to deliver a game in the end, one of the most important goals of this trimester was learning to work together with other people and disciplines.

As you can imagine, working on one big project with roughly 10 to 12 people requires quite a bit of coordination and management. Especially since it was our first time doing such a project.

Working on this project has been stressful at times, but in the end, it was totally worth it. I made new friends, and just had a lot of fun in general.


We had to complete the project within eight weeks. Everybody started out in with a small team of roughly 3 people, and every two weeks, teams got merged. This meant that there was no real way to specialize yourself within the team, as everybody had to work on various aspects of the game.

At the start of the project, I mainly worked on getting the player movement and barrel interaction working. Just some simple player input, and ways to carry, drop, and light a barrel.

Later, I started working more on the aspects. I also did a bit of UI, music, and physics programming. Eventually, I implemented the chain reactions that occur when a barrel explodes within the vicinity of another barrel.

Once the project was coming to an end, I focussed on QA and bug fixing. This allowed the others to continue working on features and polishment of certain mechanics, while QA and I were fixing things.

So, all in all, I have been working on a lot of aspects of the game. I would have loved to focus more on post-processing and graphics programming in general, but that is just not viable in such a small team.



When I was working solo on a project, I could set my own milestones and deadlines. Now that I was working in a team, I really had to step up my game and start focussing on planning and working under more pressure.

Trello boards were used on a daily basis, and I learned to estimate the time it would take me to complete certain tasks more accurately. This still benefits me, as it allows me to plan my sprints better in advance.


It may sound a bit silly, but finishing a game actually is one of my most significant achievements of the trimester.

Most of my time during my first year was spent on building solo projects. I would not call these projects games, as they were unfinished. Often, these were used by me to learn a specific concept, for instance, a platformer game has taught me how to use axis-aligned bounding boxes and a tilemap.

This game, however, has taught me more about the process of building a game, rather than the technology needed to make such a game.


When I started my first year at university, I was introduced to version control systems. I knew about Git and Perforce, but I had never used them properly.

The first three trimesters were solo projects, so it did not really matter how I used Perforce. All the things in the depot were mine, and nobody ever had to touch those files besides me.

Team projects, on the other hand, requires every team member to use Perforce correctly and efficiently. During my time on the project, I learned loads about Perforce and version control in general: how to structure a commit message, which files to push to the depot, why you should never check out the entire folder, and so on…

I still benefit from all the things I learned about Perforce in those few weeks.



Working together as a team for the first time can be tough, but it was even harder during this trimester because we had never worked with the engine before. The engine is really powerful and complex. I love some of its features, but it is a bit overwhelming when you see it for the first time…

Even though I knew how to write games in C++, it still took a lot of time to get used to Unreal Engine 4 and its Blueprinting system. Especially the combination of visual scripting and C++ threw me off at first.


Another thing that I thought I would not have any issues with is communicating. Generally, I can convey my message clearly to others, but now we had artists, designers, and programmers in one team. This required me to communicate a bit differently. For example, it is useless to explain the inner workings of a renderer to an artist when (s)he just needs to know whether it will look the same as in the editor.

It may sound odd, but it is true. I sometimes explained a mechanic to a designer but had to explain the same thing in a different way when I was talking to a programmer.


I am a programmer. Pitching was something I had never done before. Mainly because I do not need to be able to do it. But, it never hurts to try out new things and step out of your comfort zone.

When we had to pitch the game prototype, we decided that it would be a good learning opportunity for me. So, I went ahead and tried to pitch the game to the teaching staff. While I was talking, I noticed that I do not know anything about pitching. In fact, I think it may have been the worst pitch of all teams.

It was a ton of fun to do a pitch, as I learned a lot from it. But, preparing the presentation and pitching it live was difficult. I never thought that I would have any issue giving presentations, but pitches are a whole other story. There is much more to them than showing cool slides and a fancy trailer.

Leave a Reply

Your email address will not be published. Required fields are marked *