Description

An in-development complete modding/development tool for games made in the Clausewitz engine by Paradox Development Studios, intended to provide a graphical user interface for creating mods / content for games.

ClausED is intended to be a complete tool for viewing and editing game files with the minimal amount of intervention of any text editor for all Clausewitz engine games. It features a modular architecture for implementing game-specific functionality and interfaces with minimal effort.

Some of the current functionality includes:

• Reading scope files of the Clausewitz engine and converting them to easy-to-use structures using C#'s Reflection featureset
• Easily defining structures to use aforementioned data for easy display in various user interfaces
• Integration with AvalonDock for customizable screen layouts, allowing separate pages to be put side-by-side or even float outside of the main window
• Automatic reference checking, allowing a property in a viewmodel to automatically be seen as a reference to another element, and also notifying the other element it is being referenced
• A modular architecture allowing for all windows and functionality to be made game-specific, while allowing other components to be shared between subsets of games

While not close to being finished (see Lessons learnt), it serves as a proof-of-concept and practice grounds for tool development. ClausED has allowed me to dig deep into the featureset of C# and several accompanying standard frameworks to build a tool in.

Lessons learnt

Rather than targeting specific problems with this application, this project was started with a shotgun approach with more shotguns being fired out of its shells: There was no specific focus, and the Time-To-Feature-Creep was as close to 0 (no matter which unit) as you can possibly imagine. This, in retrospect, turned out to be a tremendous mistake for delivering an actual project on any timeframe. Despite this, it did result in experience in a large number of areas. From extreme flexibility using C#s MEF framework, to embedding Win32 windows for native C++ rendering, to various attributes and classes making certain functionality surprisingly simple and flexible to implement.

With next to zero experience in using WPF before starting this project, I had next to no clue how to architect most of the application. Next to the aforementioned problem of lack of focus, this proved quite interesting and time intensive to overcome. Multiple complete passes over the entire project have lead to the current iteration, and several known problems at this point require some substantial reworks to work out properly.

However, the most important lesson learnt was also the one this project was primarily meant to accomplish: Practical application of using WPF to build experience with using the framework to make an actual product. It gave me insight in the working of WPF, MEF, C# and tool development in general, and has forced me to make a set of recycleable scripts and concepts for future tool development. As such, if a company were to require a complete toolset of any kind, I have much more of an idea as to how to set it up, requiring significantly fewer manhours (and therefore costs) to set up such toolsets.

Description

As part of the Samsung VR Jam 2016, we participated as team EZPZ Buddy Allocator with the theme of "Senses", and created a prototype of a Samsung Gear VR receiving skeleton data from a Kinect to allow the player to hit balls with all of their body.

When we heard there was a VR jam at our college, we decided to join in as part of the first game jam I've personally ever participated in. The jam's theme was Senses as was announced on the jam, and we decided to try and create a better sense of hitting objects in VR games. The game revolved around hitting spheres slowly approaching the player with their body.

VR platforms such as the HTC Vive have multiple "shooter-type" games in which you are supposed to shoot baddies and the baddies shoot back, but the baddies will hit you either when they hit your head, or some "body". The problem is that VR systems such as the Vive are only aware of the head position and orientation, plus the position and orientation of the hands. We decided to incorporate the Kinect into the equation to do the following:

• Positional tracking in the Gear VR: While the HTC Vive and Oculus Rift provide some positional tracking, the Gear VR lacks similar functionality. The Kinect would solve this by tracking the position of the head
• Positional and rotational tracking of limbs: The Kinect is capable of determining the rough position and orientation of a person's skeleton, allowing limbs to be effectively used as control input
• Create an active game: We wanted to create a game in which you were on the move, and were comfortable in so doing. Of course, this was constrained to the field of view of the Kinect, which is not a large area. However, due to the nature of full body tracking, we were able to make it feel bigger than it was without ever losing positional awareness

Player feedback was overwhelmingly positive. The relatively active gameplay caught the eyes of audience and jury members alike from a distance, due to the relative static-ness of most products available on Gear VR and on display in the room. This prompted a lot of interest in attempting the game for themselves, and lead to some quite enthousiastic and entertaining displays of people jumping around trying to slam all of the balls.

Although there were talks with Samsung NL to continue the project in some capacity, these talks eventually stalled, and the continuation of this project is deemed unlikely at this stage.

Description

As part of my graduation, I decided to write up a complete tutorial to getting started in Direct3D 12 and Vulkan. Around this time, these APIs were brand new, and a lot of information was barebones or hard to find. This guide aimed to solve that.

With primary focus on the implementation of 3D APIs over the years, and the release of Direct3D 12 and Vulkan just around that time, it seemed interesting to me to setup a project using both new APIs around this time. I decided to do a guide and accompanying demo software for the purposes of implementing, comparing and explaining the APIs themselves and their inherent differences into a comprehensive guide.

Direct3D 12 had been available since the initial public releases of Windows 10 around the latter half of 2015. With its various promises to deliver on increased levels of multithreading and low-overhead came new concepts and approaches to obtain the same results. To stay up-to-date on graphics technology on both the Windows and XBox platforms it would be needed to understand Direct3D 12, as a lot of processes that previously had been a very simple, abstracted operation were now expected to be managed by the programmer.

Vulkan, Khronos' open-source multi-platform equivalent was attempting to address mostly the same problems in a similar fashion to Direct3D 12. However, first having become available for public use in February 2016, was sparsely documented and debug layers were rather unreliable, on top of being incredibly verbose. Aside from initial implementation issues, it is a definite step-up from the OpenGL API in my personal opinion, both in terms of the API itself and the toolset. The addition of Renderpasses is also potentially interesting for optimization on mobile platforms, albeit fairly cumbersome to implement in places where the tangible benefit is minimal.

During the project the initial launch problems surrounding Vulkan initially delayed the guide by requiring significantly more time to get even the basics to function properly. While the guide and companion applications were completed on time and to specification, it was only barely so, and the anxiety from this time has made me neglect to polish off the document and applications for publication. The pre-polished version is available in the links section of this page.

Lessons learnt

The most imporant lesson is to start with the hardest API first and switch to the easier APIs when getting stuck to get a break from the more difficult APIs. Vulkan as an API was by far the hardest to implement when compared to Direct3D 12 and Direct3D 11. This is partially reflected by the line count of the implementations of the same application:

• Direct3D 11: ~800 lines
• Direct3D 12: ~1200 lines
• Vulkan: ~2500 lines

The increased complexity of Vulkan compared to Direct3D 11 and 12, combined with the instability of debug functionality at the time, severely delayed implementation and subsequent documentation from about a week, with a weeks room for delays, closer to 6 weeks. Had I started on Vulkan, and moved onto the other APIs later on, more accurate time predictions could have been made when the impact could have been much lower.

Further, I should have reported various issues with the debug layers sooner than I had done so in retrospect. This might have gotten me more assistance with determining the problem and might have prevented it for other developers sooner. The time pressure at the time made this feel like the last concern, which is obviously not very rational.

Description

Moonscrapers is a competetive tower-building RTS. It is played over a network connection with two players. It was built at the International Game Architecture and Design course at NHTV Breda in 28 days.

The goal of the game is to be the first player to get to the moon by building blocks on top of your tower.

In order to prevent the enemy from reaching that point, the player can construct various offensive tower blocks to attack the enemy tower, and to ultimately (partially) collapse it.

Alternatively, the player can build blocks on top of the enemy tower by building sideways. This does not only halt the enemy's upward building progress, but also allows your tower block to rest on the enemy's tower when a part of your tower collapses.

The game was originally meant for the group projects at our course known as Gamelab, but the project was continued for a short while in preparation for display at Indigo at Gamescom 2013 in Cologne, Germany. In the short span of time between final delivery for the course and Gamescom, we implemented a rudementary AI system in order to allow the game to be played by a single person

Role in the project

I joined the project on the 14th week of the project, at which point the first functioning prototype of Moonscrapers was done.

Our task from that point onward was to make a small set of changes to the gameplay, and to polish it.

My tasks involved:

• Implementation of an improved particle system
• Environmental effects (planes, zeppelins, cars etc)
• Bug / crash fixes

After the official conclusion of the project, I worked on an improved version of Moonscrapers for display at Gamescom 2013 together with Jurre de Baare. Improvements included the addition of AI for use in singleplayer, as well as stability improvements for several crashes encountered after initial release.

Description

No Man Mayhem is a four-player competetive arcade digging game. It is played over a network connection with three other players. It was built at the International Game Architecture and Design course at NHTV Breda in 14 days.

The goal of the game is to be the first player to get more than a certain amount of gold from treasures underneath the ground, while preventing other players from beating you. In order to get to the treasures, the player will have to dig tunnels towards the treasures, and climb back up with the treasure.

The most notable technical feature of this title was the terrain generation and destruction based on voxels. This was implemented by Sam Hardeman, and allowed not only for the terrain to be generated and destroyed, but also for parts of the terrain to break off and fall individually.

Role in the project

I was the tech lead on this project. My main roles as a tech lead in this team included:

• Assigning the tasks for the programmers to work on
• Ensuring the completion of tasks, making sure the quality is good enough
• Handling communication between programmers and other team members
• Merging and ensuring integration between separate components

Since my main role was not programming itself, there is no notable area which I developed on my own, apart from making the tools for the designers to import their maps. I stepped in on pretty much all fronts with fixes and improvements on the game, without specifically focussing on one single area.

Lessons learnt

This was the first experience with Unity for three of our four programmers. As such, we jumped into the project without knowing enough about the engine in order to develop the project efficiently and cleanly. This resulted in multiple difficulties.

One such difficulty was that for the first half of the project, every change by every single programmer had to be merged into a single project by hand. Only in the latter half of the project did we figure out that Unity has some settings for reasonably supporting version-control.

Furthermore, as mostly C++ developers, we did not expect any higher-level features. As we figured just before the end of the project, Unity has an excellent messaging system for inter-component communication. This is exactly what we would have needed for the project in order to clean up a lot of the dependent code, but as we did not know about the feature, we practically hacked our way around.

The main take-away is to commit more time to properly studying the existing architecture, and making sure said architecture is used optimally. The setup method used in this project and the messaging system has since been successfully used on a couple of side-projects, and drastically accelerated the development process of said projects.

Description

This project was part of my internship at Abstraction Games in Valkenswaard, the Netherlands. As part of the project, I was assigned to assist other programmers in porting Verdun to the PlayStation 4 system primarily.

During my internship at Abstraction Games, the primary project I worked on was Verdun. Verdun is a World War 1 game which had already been around for a while on the Steam platform for a while at the start of my internship, but Abstraction Games was contacted to assist in bringing Verdun over to the PlayStation 4 and XBox One platforms.

Responsibilities included assisting design for porting input- and menu systems the console platforms and implementing these designs. On top of implementation, bug fixes of both the internal workings of Verdun and of technical issues was part of my day to day work.

While Verdun is made in Unity, and theoretically supports exporting to different platforms out of the box, I was quite surprised by the amount of technical work still required to get the game to work on consoles. Fortunately, my primary focus on graphics and low-level workings of hardware and the PlayStation 4 SDK, made it relatively easy to work on the PlayStation 4 portion on most technical issues with some level of autonomy.

While I was not around for the start nor end of the production cycle, I believe to have substantially reduced the burden on the other personell to get the product in a polished shape sooner.

Lessons learnt

First off I would like to thank Abstraction Games for the opportunity for this internship and at short notice.

This project was the first project I have worked on with a substantial codebase at the time where I started to work on the project, significantly more sizable than Moonscrapers. In addition, it was a significantly different project than No Man Mayhem in terms of using Unity in a project with orders of magnitude of increased complexity.

The Verdun codebase was fairly easy to get into and start making additions and improvements to, and while it took a moment to become proficient in working in the codebase, initial implementation of new menu screens and improve navigations in said menus went relatively smoothly. In that regard, Verdun was a good project to get used to the process of porting large products to consoles, and understanding the complexity of the process.