top of page

Description

For the progression of my study and as a vital part of my growth as a game designer, I had to search for an internship where could learn and work that would span around 6 months, or 100 working days. After a long search I found Studio MX, a serious game company located in Hoofddorp, the Netherlands. 

Studio MX is a game development company that focuses on making serious games by assignment of various clients and companies. however, compared to other serious game studios within the Netherlands, Studio MX separates itself by creating games that are primarily made with the thought of fun in mind. A lot of serious games tend to focus more on the learning aspect of the game rather than the fun factor. The educative part is incorporated as metaphors, motifs and mostly used to spark conversation after a game session. Due to this ideology when developing games, Studio MX creates educative games that are fun and engaging, which is one of the primary reasons I wanted to work there as an intern.

This page is dedicated towards documenting my journey at Studio MX as an intern. I'll discuss the multiple projects I've worked on and my contributions for these projects. I'll try to update this page on a bi-weekly basis, talking about the projects I've worked on, the obstacles and problems I faced and the lessons I've learned.

Rangers of the Lonestar

Twine lonestar.png

Scope of the Twine for the game with the branches for each planet

Twine funi npc.png

The Twine for the game, where the players are given the tiles for the game board to physically lay them out. They can also meet NPCs and obtain resources.

I was asked to help out with an already ongoing project during my first few weeks of internship; Rangers of the Lonestar. It was a game about a group of space travelers that needed to journey to multiple planets to catch criminals and deliver them justice by finding judges.

 

The project was regarded as a hybrid game that worked with both physical assets as well as a digital game made in Twine. I was responsible for developing the Twine project further. My company coach already provided an example on one planet (the game existed of a total of 10 planets), so by following that example I could work out the rest of the game without too much trouble. After all, I was quite acquainted with Twine already.

This was actually a rather fun project to work on, as was also given permission to use my creativity to add dialogue to the NPC's in the game as well as add flavor text. My company coach made clear that I had a lot of creative freedom in designing and creating this dialogue, which made it all the more fun to work on the project. After a two week period that spanned around the whole of september (first two weeks development with a little bit of polish in until september 23), I delivered the Twine build to satisfaction.

Overall, this was a cool and interesting starter project going into my internship period with Studio MX, as I got to learn about the company and their workflow. It certainly was great to work out all the scenarios and dialogue in the Twine and it was a good sign for the rest of my internship period.

Period worked: Sep 1 until Sep 23

Projectra 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

​The game takes some inspiration from the game Pandemic, where fire (disease in Pandemic, representation of variables that can pop up and cause problem in real life processes) will spawn in the game which can spread further to other zones on the game board. These are the major hazards of the game and the players must coordinate how they will finish a process while taking care that the fire won't spread too much.​

​The game is meant to educate someone on how it is to work in a process where you need to cooperate with other people and are dependent on one another. Things can go wrong during such a process, and this will create stress and difficulties that people have to hurtle over. The game wants to put those players in such a position where they can really see how such a process can take a turn in the wrong direction and how you can remedy this. 

​The result of my endeavours can be seen to the right. As can be viewed the game is still very much a prototype, but this was to be expected.  My skills with programming were quite under par, and working on this project has helped me much in the way of getting a better understanding on how to script, even if it’s visual scripting. I got a better feeling on how functions and the overall structure of a script is made and how it works within a program. With Projectra, I feel like I’ve created a bigger foundation for my skills as a more versatile designer.

14 October

During my time at Studio MX, there was one project that I worked on through the course of the whole internship; Projectra. Projectra was the core project I worked on while I wasn’t contributing to other projects.

Projectra is a game where 5 or more people will be placed on a planet where they have to go through a certain process to determine the safety and demand for a product before it will be mass-manufactured. Each player will take on a certain role in this process that will grant them a unique ability. These abilities are necessary to win the game, just as much as working together with you team and communicating with them thoroughly.

 

Projectra stands out from other projects as the focus of the project was not necessarily with the design of the game, but rather the scripting of the game. I was asked by my company coach with making a foundation for a digital game based on a concept they have used in the studio before, which meant that I needed to program the game. This was both exciting and anxiety-inducing, as I have scripted before, but my skills were not on a level that I am capable of scripting a whole game from scratch.

I was not expected to make a whole game during my internship period. It wasn’t even expected to make something complete; the important part of this assignment was that I needed to familiarize myself more with the programming side of game development. My company coach knew that I will be communicating and working together with people from other disciplines as a designer, and therefore it is vital for me to get a better understanding of the language that both artists and programmers speak.

poerjectra.png
le cumstruct.png

Prototype of the Projectra, made in Construct 3

Visual script in Construct 3 for Projectra

"PECO"

Stage_Shattered_censorted.jpg

Whiteboard photo of brainstorm session

hexagons_noBG.png
Maze_noBG.png

Examples of the minigames I made for the prototype, left is a hexagonal puzzle where the pieces are shuffled together and every white line needs to be connected, the right is a segmented maze where one passage connects to every segment.

peco thing.png

I designed the second board of the game 

1 November

While working on Projectra, I was asked to help out with prototyping for another project of Studio MX, a board game codenamed "PECO". Me and my company coach sat down together to discuss the overall gameplay- and learning goal for the project and decide how we can translate that to a fun game during a sprint. My company coach taught me how this part of the game development works at Studio MX. On the left is a photo of our brainstorm sprint.

 

My job for this project was to think of some minigames to be used within a paper prototype. These minigames were fun to make and design, but it was quite different from how I'm used to designing a game. the most challenging part about designing these minigames was that I could not make use of a digital environment to design the minigames, as they are meant to be played with a physical game board, so the minigames needed to be preferably physical as well. We also steered clear of dice and cards for our minigame due to a few reasons. One is that it should be feasible for someone to finish a minigame in around two minutes (time is also a mechanic in the game). Dice and cards create too much random elements so that we can't bank on it being completable in a certain amount of time. The second reason is that we weren't using dice and cards in the game to begin with, so we didn't want to add them in just for a minigame.

 

This was the first iteration of the game that my company coach presented during a playtest, one where our ideas where completely obliterated by our testers. While the minigames were not lambasted, we still needed to part ways with some other ideas and decided to change the mechanics of the game with a new concept. The concept that stuck out to us was the idea of having two game boards, one where most of the game would be played on first, for the players to then flip the board on its back and play through a second and final board. I was in charge of making the second board, with the idea being that the players needed to make use of all the resources and insights they’ve gained during the first part and make use of it on the second board to get the best possible outcome. The prototype iteration of this board can be seen on the left.

 

We play tested this iteration with a group of students and two of their teachers. This playtest was met with resounding success, with the students being much more positive towards the prototype apart from a few feedback points.

Other contributions

File by the Sea 

I was brought into this project long after its development was finished, as nearly everything of the game was already designed and created physically (as the game was a board game). This project offered me something different however, as my contributions were more fixed on preparing for the first play session with my company coach and the clients before we would hand over the game. My contributions for this project therefore included making the game manual and assisting with the play session.

My company coach placed me on this project in order for me to obtain experience while working with the clients directly, which allowed me to get a better feeling on what our target audience was like. This allowed us at Studio MX to better adjust the game towards both their preferences but also to their past experiences with games, as most of the attendant players during the session had very little to no experience playing games. This was important to keep in mind as I needed to adapt and write the manual which would explain the rules and flow of the game with this in mind.

Dossier aan zeeboy.jpg

Me with the huge board of the game

Your Career Tour

Your career tour was a very small project where I worked together with my company coach and the composer of the project to make the music for a game where you’d walk around a company workspace and interact with the environment. I was only included in this project as a way to emphasize how important it is for a designer to speak a bit of the language of the other disciplines in game development, as this makes the development much more streamlined. We did this by talking with the composer on the music that we wanted the players to experience and the feelings attached to them.

loopbaanboy.jpg

Me and my company coach with the composer in a zoom call discussing the score for the game

bottom of page