dennis.fokker@live.nl
0611911153
Eindhoven, Netherlands
I'm a software engineer and game designer, focussing mainly on the technical aspects of games.
I started programming when I was around 15, and since then only gotten more interested in the structure and logic it required. Once I discovered game design was a minor in my study, it was a quick pick for me, as I was always interested in how games were made.
During the game design projects, I liked the variety between designing interactions for users, as well as creating systems and watching them come together into a single game. The designing part was something I missed during the software assignments.
Even as I enjoy the design elements, my focus remains in the programming department, creating elements that are usable for both players and other developers.
The Enversed framework is a collection of core systems and modules. It gives each new game a jump start in development and offers consistent interactions where needed. Almost every system works in a replicated environment and relates to VR applications.
The framework is an ever-evolving project; it constantly gets new features, adjustments to improve overridability, and reworks on elements due to new engine features or knowledge about how Unreal works. It is developed alongside other projects, receiving occasional releases to which projects can update. The separation of responsibilities allows us to implement and rework features as needed without influencing projects until it's ready to be published.
Aside from general fixes and reworks, my main contributions are in movement and creating body size calibration (making sure an arbitrary human skeletal mesh roughly matches your real-life body proportions.). The contributions to the movement consist of:
Enversed Home is a distribution platform created for the clients of Enversed to streamline the process of keeping apps up to date and launch multiplayer sessions with specific computers.
Enversed Home was initially developed by me and the CTO, over four months. During this, we performed the initial research and implementation, focussing on the cloud-based solutions and how to handle communications across the computers on the network. Once the MVP reached completion and could be used, the project passed on to the systems team of Enversed, of which I was the lead developer.
We chose to develop it within Unreal Engine to ensure all developers at Enversed could work on it. Making sure specialised developers were always available was not viable at the time. Using Unreal also allowed us to use Unreal's replication system but tended to limit development on the UI as there were no expects in Slate/UMG.
The Proto Invention Factory is a client of Enversed, for whom we produced a collection of games, most of which I have worked on during my internship. All games exist in the same steampunk universe, where some games introduce physical controls to increase immersion. Each game is limited in game-time, as Proto is an arcade-like environment.
The Proto games were developed by a team of about 10-15 artists and programmers, including myself and a few other interns. The games already had a concept describing the core gameplay provided by the client. However, the specifics were up to the developers. For example, the introduction experience: the concept was merely drawing the inventions of the other games. How to draw was up to the development team.
Some games use physical controls, such as buttons, leaning sensors, a bicycle, and joysticks. The client provided the testing hardware. Aside from calibration, I was responsible for implementing the communication protocol between the game and other hardware. The protocol consisted of simple timing-based handshakes and JSON messages. The hardware didn't require overly high data throughput, so the overhead of JSON vs raw binary wasn't a big issue. JSON also allowed us to implement debug data without effort.
I designed and developed the score system shared by (almost) all the games. The principle behind it, was that the average player should have roughly the same score in all games. From that baseline, we defined a curve from the lowest to the highest score. The curve allowed us to create "regions" in scoring, such as making it very difficult to reach a perfect score or creating an island around the mid-point so players would tend to get similar scores.
Aside from the score system, the main features I worked on are: