Joris Schroeven @ Linked In

Maze Platformer [2015]

The idea to explore Unity's 2D engine and create a small game around the concept of mazes resulted into the creation of a game with a current working title of "maze platformer". The working title already reveals what it's all about, a game which plays like a platformer and requires the player to find the exit to a maze.

The core concept of the game is to find the exit to the maze while trying to be as fast as possible.
To challenge the player, each maze completed unlocks the next level which is a new, randomly generated, maze that is slightly larger than the previous level.
Every 10 levels completed the player can progress to a next world. Each world has its own theme and there are 6 unique themes to the game.
As the player progresses through worlds additional challenges (besides the increased size of the maze itself) are added such as the difficulty of finding locks and their corresponding keys with up to 4 locks from world 5 onwards.
As the player completes mazes, he is rewarded with bronze, silver and gold coins upon completion of a maze (the maximum amount earned increases every level). The faster he completes the maze, the more coins he can earn. Later on in the game (level 7 and onwards) there is a chance (increases each level) a shop spawns randomly somewhere in the maze. Inside the shop the player can trade gems for keys, coins for gems and gems for coins.
Gems have a very low random chance to be spawned in a maze and a very high spawn rate inside a secret hidden dungeon. This hidden dungeon has a chance to spawn (also increases every level) from level 25 and onwards.
Collecting gems will allow the player to purchase keys in the shop which can be carried across levels to open locks much faster, and thus complete the level in a shorter time span and as a result the player gains more coins at the end.
Once the player moves on to world 50 and higher, there is a chance (increases every level) that a key isn't spawned for a corresponding lock. This poses a new, high-level challenge where players might need to return to earlier levels to earn more coins or gems and find a shop to purchase the required key as it isn't ensured that a shop spawns in an accessible area within that specific level.

So far a couple of challenges had to be overcomes to make certain game aspects possible.
The first challenge was the one of remembering the maze layouts and all objects (props, keys, locks, etc...) spawned within. From a previous project (Very Small Game "Maze Game", a University project) it was easy to overcome as we could simply store the seed used to generate a specific level. The second challenge was slightly harder, a performance issue started to occur when mazes started to reach level 100 (and become 100x200 in size). Not only does it take a little while to load, unity simply cannot handle the huge amount of objects in the scene. Although they are outside of the camera view, they still caused a huge performance drop. To resolve this, all objects are simply hidden (made inactive) and only those within a certain view area (slightly larger than the camera's view space) were made active. The activation and deactivation isn't checked every single frame as that also causes a huge performance drop. This check is done whenever the distance from the last object-visibility-update exceeds a certain value.
With the performance issue resolved, mazes can, in theory, be generated up to an infinite size, thus allowing and endless number of levels for the player.

The game isn't considered a finished product yet as there are still a number of concepts and game play elements to be added. A playable version (developers build), which has a number of finished concepts in it, has been added and made available to be played.

Play Maze Platformer

Game Prototype "Battle of Britain" (University) [2014]

In a small team of 10 (1 Director, 2 Designers, 2 Artists, 5 Programmers) we created a game prototype using UDK and UnrealScript designed around the events of the Battle of Britain which took place during World War II.

My share in the project as one of the programmers was to implement the planes movement, rotation and attacking behaviors.
At the start of the project I was also responsible for establishing a base structure upon which future features could be built. The base was mainly focused around UDK states and their inheritance.

Graded 16/20 (80%)

Very Small Game "Maze Game" (University) [2014]

The project is a very basic game built on top of the engine constructed during semester 1. The engine can render a 3D environment and is created using C++ and DirectX. It uses some software design patterns to structure the engine and allow possible future reuse of the engine and easy extension of the existing game code. The game created with the engine has a very simple design and objective. You can play it in a singleplayer or multiplayer environment. You’ll be spawned in a procedurally generated maze and the goal is to find the exit. The first player to reach the exit wins the game.

Graded 19/20 (95%) for the Game Programming (DirectX).
Graded 18/20 (90%) for the Networking.
Download Project Report (Game Programming)
Download Project Report (Networking)

Very Basic Game Engine (University) [2013]

The project is a very basic game engine which can render an abstract 3D environment created using C++ and DirectX. It uses some software design patterns to structure the engine and allow possible future extension of the code.

Graded 18/20 (90%)
Download Project Report

Racing AI (University) [2013]

The project is an artificial intelligence (AI) that can be used in a game to control the steering of a racing car. There is a very basic graphical representation to visualize results as the main focus of the project is the AI. The AI technique used throughout the project is a Fuzzy Inference System (FIS) which was implemented using the Fuzzy Logic Library (FLL) made by Dmitry Kaluzhny.

Graded 18/20 (90%)
Download Project Report

Hobby Game Project [2008 - Present]

Development of a hobby game project (based off existing game code) with the goal to learn more and more about game programming every day.

The project consists of a multiple components:
  • Client: In theory distributed to players.
  • Login Server: Runs once and handles all account logins.
  • World Server: Can be run multiple times, it represents a single world and each instance represents an alternate dimension. Handles the Character Logins, Guilds and other world-systems that require to be stored.
  • Game Server: Runs a limited number of maps of a single world, there are multiple of these running all at once. They mainly handle all the game play.
  • Gate Server: Handles communication between Game Servers so they can share certain data or requests with each other.

And some sub-components & tools:
  • Auto Updater: Used to automatically update a player's client files and provide a 3-way handshake to launch the game to start playing it. (Built from scratch)
  • PAK Builder: Opens, Displays and Builds PAK (sprite container) files (Built from scratch)
  • AMD Editor: Opens, Displays and Builds AMD (map container) files.

Improvements & Changes made to this project:
  • (Networking) Packet Class [2008]: Replaced old and repetitive pointer juggling with a nice and neat generalized class that is used in the 4 main server components (Client, Game, World, Login).
  • (Networking) Extended Colors and Player Effects [2012]: Increased the size from 0xF to 0xFF.
  • (Game Play) Summon Event System [2010; updated 2014]: Automated event (created and configured by game masters) that summons (spawns) monsters with dynamic scaling which depends on the number of players present in the event area. This system ties into the Packet class a data must be exchanged (and saved) between multiple components.
  • (Game Play) Advanced Guild System [2012]: Rebuilt the guild system from scratch to allow more guild ranks and multiple abilities tied to specific ranks. This system ties in with the world server as guild information must be saved should be available for the entire world instance.
  • (Game Play) Advanced Party System [2013]: Rebuilt the party system communications between the Game Servers to allow an increased number of players in a single party (from 8 to 16 with the ability to dynamically expand this) along with a visual display of certain details of other party members. This system ties in with the Client and Game Server.
  • (Game Play) Advanced Quest System [2009; upgraded 2011~2014]: Rebuilt the quest system to allow multiple quests to be active at once (was limited to one quest at a time before the rework). Rebuilt the quest conditions, objectives and rewards to allow them to be dynamically expanded. This system ties in with the Client, Game Server and World Server.
  • (Game Play) Extended Item System [2011]: New types of items which decay over time, at a specific date or when their endurance has reached zero.
  • (Game Play) Buff System [2013]: Certain magic spells give buffs for a certain period of time, these received their own icons and display on-screen to make it easier for the player to see when his buff is about to run out.
  • (Engine/Game Play) Virtualized Maps [2010]: Maps that open and close dynamically using identical configuration both Client and Server side. Keeping in mind that each map is initiliazed when a Game Server loads the map configuration it's supposed to host, this change allows the dynamic addition and removal of any map. With virtualized maps the game can now dynamically open maps for events and close them again after the event is completed.
  • (Engine/Game Play) Dynamic Portals [2010; updated in 2011]: Visual portals with certain restrictions (configured by game masters) that allow teleportation to another location. Keeping in mind that teleportation between maps is embedded within the AMD map files, this change allows game masters to dynamically create and delete portals to certain maps (such as virtualized maps where events can be hosted).
  • (Engine/Game Play) Randomized Maps [2014]: Using Prim's Algorithm to generate a random maze and replace a single maze-tile by a larger map-section to create a fully ranomized maze-like map. Along with the use of Dijkstra's Algorithm to determine the longest path some advanced quests have been added as game play elements so players have to reach the end of the maze which'll be different everytime as the maze is randomized at a certain time interval.
  • (Engine/Game Play) PvP Tournaments [2014]: Structure Player v Player events with the choice to play bracket breakdown or in a league. A range of fight setups from 1v1 to 5v5 or even All v All is possible. Even having tripple (XvXvX) or bigger fights is possible. The system dynamically distributes players across fights and fills gaps where needed with an eye towards honest scoring. This system makes great use of the virtualized maps to create map instances equal for each fight while multiple fights occur at the same time. A set of chosen rules (by the creator of the event) are enforced both client and server side to avoid players cheating or not living by the event rules.
  • Several optimizations were made to increase performance of the game and reduce code redundancy.
  • Several other minor features were added to the project in both game play (new magic spells, new items, new maps, GUI optimizations...) and mangangement optimization (SQL configs and log files instead of TXT).

One of the most important and noticable things about this project is the lack of being object-oriented and encapsulation. There are basic objects within the project but there could of been far more advanced OO structures put in place. Encapsulation wise, basically nothing is encapsulated within the code and therefore I've continued this design choice throughout the pieces I've built myself although I am fully aware that it actually should be encapsulated.