Making Spooky Fast Enemies in Half-Life 1

It’s my birthday today, so I decided to write this tutorial as a gift of sorts to any readers who might find it interesting.

What I’m going to teach you today is to how to make zombies in Half-Life faster, in all aspects, which can result in some interesting enemies for Horror mods. The best examples of this trick can be seen in mods Afraid of Monsters and Afraid of Monsters: Directors Cut, made by Andreas Ronnberg. With that done, let’s get down to it.

To complete this tutorial you’re going to need some tools.

Jed’s Half-Life Model Viewer (The main program we will be using)

Studiomdl (Model Compiler)

Mdldec (Model Decompiler)

Notepad++ (Not required, but it makes editing the QC file easier)

Once you’ve gotten these, we can begin.



The first thing we are going to do is find the model we want to change the speed of. For this tutorial, we’re going to use the default low-def Zombie model from Half-Life 1.

To find this model, we need to go to the following location in our files.


When you arrive, select the following models…


and copy/paste them into a separate folder. Make sure this folder is empty, as things are about to get crowded.

Once that has been done, open Jed’s Half-Life model viewer.

Before we do anything, we first need to set the locations of our extracted studiomdl and mdldec executables. To do this, click on the “Tools” drop down menu at the top of the screen and then select “Configure Tools…”.


This window will show up, though the boxes will be empty. You can now navigate to where your executables are and select them, setting the path in the box. Click OK to close the box.

Once that is done, we’re ready to decompile the model.

Click on the “Tools” menu again and select “Decompile Model” to be brought to a navigation window. Navigate to where you created the folder that holds the copies of the models and select only the “zombie.mdl”. You do not need to select the other models, but they need to be in the folder otherwise it will not decompile.

Click open when you have selected “zombie.mdl”, and a command window will show up briefly and then close. Your folder will now be filled with .smd and .bmp files. Ignore these, and look for “zombie.qc”.

CaptureIf you downloaded and installed Notepad++, simply right click on the “zombie.qc” file and select “Edit with Notepad++”. If you did not, you can select the “Edit QC File” option under “Tools” in Jed’s Half Life Model Viewer and navigate to the QC file.

Once the file is open, ignore the stuff at the top and scroll down until you see “//44 animation sequence(s)”. This is where we will be doing our editing.

Now instead of editing any specific speed value, what we are going to be doing is editing the fps value of the animations of the model, meaning that the actions will be carried out faster.

CaptureEach value in the unedited file is around 15-22 frames per second, meaning that if we want to make the enemy faster, we will need to increase the value.

Now if you simply want your enemy to move fast, the only values you need to edit are the following.

$sequence “turnleft” “turnleft” fps 20 ACT_TURN_LEFT 1
$sequence “turnright” “turnright” fps 20 ACT_TURN_RIGHT 1

$sequence “walk” “walk” LX fps 22 loop ACT_WALK 1 {

A good value for a speed increase is 50-70 fps.

If you want to make your enemy attack faster you will need to edit the following.

$sequence “attack1” “attack1” fps 15 ACT_MELEE_ATTACK1 5 { event 1 10 } { event 2 19 }
$sequence “attack2” “attack2” fps 15 ACT_MELEE_ATTACK1 1 { event 3 6 }

These values shouldn’t be increased exponentially unless you intend on making your zombies more difficult, as them attacking too fast essentially means instant damage to the player once they are in range.

If you want to make your zombies faster in everything they do, like in AOM, increase all of the values (except death animations, they look kind of dumb if sped up) to around 50-60.

Once you are finished with the file, save and close it.

Now it’s time to go back to Jed’s Half-Life Model Viewer!

Once you’re back in, click on the “Tools” drop down menu and select “Compile Model…”, then navigate to the location of your decompiled model and select the “zombie.qc” file that you edited. It will then recompile the model and you’re done! Open the newly compiled “zombie.mdl” and run through a few animations (located in the “Sequences” tab at the bottom) to see how you like them.

Place them in your mod/models folder or back up the existing Half-Life zombie and place it in your valve/models folder to test it out in game.

You should be set!




A summary of my experiences in Studio 1

This has been a very interesting and busy trimester, probably more interesting and busy than I’m used to which made it even more interesting and more busy. I learned a lot and worked on quite a few games over the course of the trimester which I know for sure is going to benefit me in the immediate future.

What did I work on?

Out of all the things I worked on this trimester my very first game, “Light Rider” was probably the easiest. It was a short arcade style racing game in which the player had to make it to the end of the level while avoiding the obstacles and out of bounds areas. I didn’t spend as much time as I should have on it however which meant that the final product was substandard in terms of both gameplay and performance.


The brief for this game was centred around a perpetual motion mechanic, fairly easy as far as briefs this trimester went and not difficult to develop for. The most interesting part of development was making the track out of splines in 3DS Max, something which allowed me to create both the background for the track and flawless triggers which made it extremely easy to tell when the player was in the track and when they were out of the track.

The next game I worked on was Virion, a project which honestly took me by surprise. Virion started as an extremely strange and difficult game but quickly evolved into something that was found enjoyable by playtesters and tutors alike. It was our first group project, and though I wasn’t heavily involved in planning it was a fun and educational experience to watch take shape.


Virion was definitely an enjoyable game to work on. My roles mainly consisted of level design and particle effects along with creating some models (spyware model and environment model), and some very minor UI things (placeholder instructions screen). One of the best things about working on Virion for me was probably how well organised it was. We had many online resources which helped us know what we were meant to be doing and when to have it done by, and we had semi-regular skype meetings which cleared up any confusing before it could seriously hinder the project.

The third studio game that we worked on was Sibterfuge. Sibterfuge was very difficult to work on, mainly because of the very restrictive and specific brief, something which I feel reflected itself in working versions of the game. To specify, the brief stated that the game was not to be based on any of our favourite genres, had to have a child as the player character, could not contain any writing, could not contain any UI, could not contain any words from any spoken language and had to make the player feel “wily”. The biggest issue of design was figuring out how to achieve the “wily” feeling, something we needed external help to figure out.


Sibterfuge was less enjoyable than Virion to work on purely because of the many design issues we faced that plagued us for a very long time. There were however more things for me to do during the project as there were only two designers (as well as two animators) working on it. My roles in Sibterfuge were mainly level design, audio creation, implementing animations into the game itself, documentation and some extremely minor scripting roles. I learned quite a bit about audio creation and a little about asset creation in 3DS Max.

The “final” thing I made, a game called Sight, doesn’t exactly count as Studio as it was made for CIU, but I’m going to include it anyway. The project was quite different in terms of both what I am used to working on and what I have worked on in the past. It was a short game based around a blind character who would use a unique skill, echolocation, to “see” their surroundings. The game was meant to focus on the character and the fact that they would be one of the first people in the world to receive bionic eyes so they might be able to see for the first time in their life.


Sight was definitely interesting to work on despite the limited time frame. I didn’t exactly learn anything new, but I was allowed a further opportunity to explore level-related asset creation in 3Ds Max as well as a first foray into audio. Unfortunately I didn’t have enough time to add any real story elements to the game, so as it is the game can be quite confusing if the player doesn’t know what’s going on when they’re playing for the first time.

What did I learn?

The first and foremost thing that I learnt in terms of non-skill related stuff would be the importance of documentation. Well done documentation is extremely useful when creating games, as it is essentially what you want your game to be in written form. I’ve already started writing Game Design Documents for pre-existing projects that I have been working on and I already have a better understanding of what I want them to be. Project planning, things like Gantt charts I have also found to be useful as it’s a definitive layout of what needs to be done, how important it is and when it needs to be done. It gets rid of the confusion and makes things seem more manageable in the long run.

In terms of hard skills, the biggest and most important (in my opinion) things I learnt were related to Audio, 3D model creation and Unity.

Audio creation was a necessity for Sibterfuge, as it was my responsibility to create the voices for the Siblings. I had to learn a little bit about Audacity, an audio creation and editing program, and use it to make my voice sound nonsensical, and also to make it sound like it belonged to both a 13 and a 7 year old. I faced a few challenges while completing this task, namely getting the voices to sound “right” and to remove as much noise as I could from the background. To get the voices sounding as young and cartoonish as possible I had to change the pitch and speed multiple times, making adjustments as necessary so that they would just sound cartoonish and not too much like chipmunks.

3Ds Max was something I already knew at a beginner level, but I learnt quite a bit in relation to plane modelling, which I used for both Virion and Sibterfuge. I also learnt how to animate, which was a massive step forward to me. I used plane modelling to create the environmental area in Virion, which was never used in game but was created nonetheless. The environmental map was essentially meant to be a futuristic sort of arena that looked partially like a Tron city and partially like a motherboard. How well I succeeded in that task is arguable, but it helped further my understanding of using plane modelling to create structures and very rough architecture/aesthetic features. I also used plane modelling to create the rooms in Sibterfuge, an easy task by comparison, but a task that was greatly assisted by the use of knowledge taught to us by our tutors. The knowledge consisted of setting the unit scale within 3Ds Max to metres, so that we would be able to create our models to a set scale so nothing would be too big or too small when we imported it into Unity. Creating the rooms was greatly assisted by this, as I didn’t have to guess distances or anything, and when I imported the rooms into Unity they were all the same size and ready to be put together. Animation was something I briefly delved into and achieved a limited understanding of. It was something I was learning for Virion, as I had wanted to animate my spyware model. The animation process at it’s most basic level was far easier than I expected to be, though I am not sure if I will pursue it further. Another thing I learned in 3Ds Max was how to texture things roughly via material channels, something which helped in both Virion and Sibterfuge.

Unity was a tool I thought I knew pretty well, but there are some functions which would be used for pretty much any game which I hadn’t touched until now. What I learned exactly was how to implement animations into games with Unity’s animation tool, as well as how to create spritesheets. This was an interesting process, aided by a tutorial and a lot of guessing. It took quite a while to learn fully, and then quite a while longer to get the animations working well enough in game, but it was worth it and now I know another thing about Unity.

As for soft skills, I feel like my ability to talk with others improved significantly, which also helped with my confidence. I think this came from having an extremely small class, which forced me to get to know the others in our class which in turn helped me with things like open day, in which talking to strangers was a requirement. Open day also helped me with that, for reasons I just stated. I also find myself participating more in class, answering questions and giving input when I feel it necessary. All in all, I feel a lot more involved and confident than I did last year, and even last trimester. I even feel like my ability to talk in front of others (speeches, etc) has improved slightly, even if I still have some trouble with it. Any progress is good progress in this case.

Where to from here?

The holidays are going to be quite busy for me, as I will be working on many personal projects as well as Virion. I do have some things I wish to focus on on the holidays however.

  • Continue to write documentation
  • Set up adequate project planning
  • Find an easy and immediately accessible way to set up a to-do list
  • Continue to work on level design
  • Learn how to use UDK, continue to learn how to use Doom Builder 2
  • Investigate player psychology

These things mainly relate to my personal projects, but I feel like they are necessary things to learn and know in general. The most important out of these for me is to continue to work of my level design skills and to investigate player psychology as that directly relates to level design. Learning how to use UDK is a close second and something I very much look forward to doing.

In trimester 3 I hope to mainly improve my scripting skills. Out of everything I know and do in game design related things, scripting is the thing I am the worst at. A notable trend with my scripting skills is that with each project I do, I learn a single new thing. While this isn’t necessarily a bad thing, it’s probably the slowest way to learn things ever. I have no motivation to learn scripting, so making use of the pressure of studio in Trimester 3 seems like a good way to start. I also need to start learning to ask for help, as that is another massive problem I have. I will spend forever trying to work something out, wasting time when I could just ask for help and solve the problem while learning something new. One thing I am afraid of in relation to this though is making it seem like I am asking others to do the work for me, as I do get stuck when scripting very often.

Sight Asset-Post

Due to the fact that the main character in Sight was visually impaired, the game itself required minimal visual assets. The main areas I focused on in sight were the scripts and the levels, as they were the biggest and most key components to making the core game work.

Aside from a slammed together document detailing my intentions and plans for the game, the first things I created for Sight were the scripts.

This is a list of Scripts I made for Sight.

  •  echoEmitterScript.cs
    • The script that controlled the spawning of the sphere as well as the cool down between activations.
  • esScript.cs
    • The script that controlled the expansion rate, speed and maximum size of the sphere.
  • closetScript.cs, fdScript.cs, showerScript.cs, officeScript.cs
    • Each of these scripts were for triggers that control various objectives and the text that displays on screen when the player touches them.
  • gcScript.cs
    • Script for the Game Controller, controlled level changes and mouse cursor visibility/lock state.

Not many scripts were needed overall, though I had issues creating the objective/subtitle system as I was attempting to put them all into one script and had misunderstood in a lapse of judgement how the OnTriggerX system worked. I did however find the multiple scripts more manageable in the end.

The next assets of Sight I created were the levels.

There were two real levels in sight, the House and the Hospital. The third level was a simple scene with no gameplay elements, just what is essentially a bare doctors office where no movement is allowed or houselevel

These were the level plans for the Hospital and House level respectively.


And here are the completed assets in Unity. You may notice the lack of a driveway/car in the House level. It was removed as I felt it was unnecessary, and would imply that there is someone capable of driving also living in the house (which is, according to the documentation, true, but I didn’t have enough time to plan out and make a second character).

I also created textures for the final “level” of the game. They aren’t anything fancy but they look good enough and are able to achieve their purpose.

carpet grey_plaster woodwhite_plaster

They are from left to right; Carpet, Ceiling, Wood and Wall.

This is what they look like in game.


The final asset I created was the Cane Tapping sound which would play whenever the player clicked the mouse button. It is the sound which signifies the creation of the echolocation sphere.

This sound was created by me tapping my iPhone charge cable against my iPhone case.

Sight Post-Mortem

Sight was a short game I made as my transmedia project for CIU. It is a game about the life of a visually-impaired person on the day of an operation in which they will be one of the first people in the world to receive bionic eyesight. The amount of time I had overall to make the game was 6 weeks however the time the game was actually in development was 4 days, an extremely limited amount of time for a proper product to be produced.

The game as it is “completed” is essentially nothing more than a prototype with minimal story elements, place-holder mechanics and an extremely short completion time which fails to deliver the “point” of the game.

What was Sight originally meant to be?

When I first wrote the project proposal for what would become Sight I had a much larger project in mind. Unfortunately, that project was most likely beyond scope even with the full six week time limit. The original project was centred around the same theme as Sight, transhumanism and cyborgology assisting people with disabilities, though there were going to be multiple playable segments for different disabilities. This would have required me to make multiple mini-games which more likely would have ended up trivialising the issue by turning each part of the game into more of a traditional “achieve the goal” thing which would have in turn robbed any real emotional experience from the player. I also had the challenge of trying to portray the disability of each character as something that didn’t hinder them personally in day to day life. Their disability would have to be something they had overcome and learnt to live with.

To combat each of these issues I decided to make Sight focus on one disability and go from there, making the story about that one character and how technology would assist them and make their lives easier. I had played games that featured visually impaired people before and had used a unique ability, “echolocation”, to make up for the players inability to see. This wasn’t just a cheap work around either, as echolocation has been used by visually impaired humans before in real life so that they may “see” their surroundings via making noises and judging distance between them and surrounding objects by where the noise would “stop”. I decided to make use of this in my game, overcoming the issue of having the main character be relatively unhindered by their disability.

What went right?

The concept of the game is something I am very proud of, and I think, given more time and work, could be something that delivers an experience worth remembering. The initial ideas I had for the then unnamed Sight were going nowhere and I was worried that I was going to have to cut even my initial idea down into something that would have been downright terrible in both concept and execution. Coming up with this concept saved me that issue, despite the fact that the execution of the concept could have used a lot more work.

Asset creation was another aspect that went very well. Not many assets were needed and the assets I did create were done with ease and very little trouble overall. I used a very simple method of plane modelling to create each level and another method to create the final level. The other assets, the textures and cane sound, were extremely easy to create and looked/sounded perfectly fine in game.

What could be improved?

To avoid a blanket statement saying “everything could be improved” I’ll try to single out the most important things first and foremost.

The concept was something that was fine in the planning stages, it worked well and would have told the story just fine. However, the execution of the concept was severely lacking. The game now has an almost non-existent story, as the limited time frame only allowed for me to work on assets and mechanics as opposed to the story based content. In hindsight, the story was ultimately more important as the player has no idea as to what is going on until they finish the game. They are not told who they are or what they are doing. They are only given short term goals which have no real relation to the overall plot of the game, nor the point the game was trying to make. This was a time management issue overall, though more focus could have been put on relevant aspects and not on more unnecessary things (even if it would have lowered the quality of the game more so).

Time management was a weird issue during this project. It was definitely an issue, but other circumstances made this particular project a secondary thing for me until the week before it was due, which was when I seriously started thinking about the concept I had come up with. The base planning for the project should have been done earlier despite priorities, time was just not used effectively enough. It would also have been useful as I was left with an absolutely minimal amount of time consisting of half-an-hour before it was due to fix bugs.

Sight could have used a lot more work, as the “finished” product left a massive amount to be desired. While the actual creation of the game went over smoothly the planning and time-management side of things suffered greatly. Sight was enjoyable to work on and the concept was interesting, but it definitely could have used more work.

Virion – Asset Post

For Virion I mainly focused on Level/Board Design and Aesthetic elements of the game, as well as some place holder work on the Instructions.

One of the first things I did for Virion was board designs. I came up with a multitude of board designs for potential use in game, each with a unique aspect that was an attempt to set the levels apart and to prevent any of my levels from being too “generic”.

One of the first levels I made was Chasm, the level that playtesters played during the first playtesting session.


Many of the playtesters liked Chasm, and I think it allowed many of Virion’s core mechanics to be showcased very well during play. Chasm is a level that forces conflict very early in the game, mainly through the use of spawn location and the blanked out islands running through the centre of the level. The location of these islands creates an invisible line which marks “my side” and “your side”,  which creates an interesting battlefield, especially through the use of reverse symmetry.


This is an ugly picture detailing the various areas in the level. As you can see, the space in Areas 1A and 1B is limited, and as this is a territory control game, players will be wanting to expand outwards to capture more territory and control more space. Units in Areas 1A and 1B will be forced to move over the line if they want to expand, effectively breaching the other team’s Area 2. If the (inexperienced) player wants to move the Trojan out, they will be drawn to the “mid” corners of Areas 2A and 2B as that is the location of the most free territory. This will provide an attractive target for the other team, a target which they will be willing to move pieces in through the centre of the levleto capture. Both of these scenarios create conflict, and force the players to plan their moves carefully but aggressively to capture as much territory as they can to win the game.

Another level I created, “Duo”, for another playtest was based off of the idea of a tutor, and features a split across the middle. This creates two separate battles on each side of the map.


This level was interesting to design. The decision to have two Trojans in the centre of the map facing off against each other was one derived from feedback saying that the Trojan was the most useless unit during the middle and end of the game in Chasm. I wanted to make it so the Trojan was a unit not confined by its spawn point but also immediately relevant/in the fight. I gave the Trojan three escape points so it could never be trapped, though using those escape points would usually lead to the other Trojan gaining control of the centre of the map.

Having each side separated from each other made me worry slightly, as I was afraid that matches would end in a stalemate and a conclusion would be nigh impossible to achieve. Upon a suggestion from our team’s programmer to open the back so units can pass to the other side that problem was mostly bypassed. In the games I saw where this map was played, conflict was prolonged but a stalemate never occurred.

I also made 4 other maps for Virion, though those did not appear in either playtest and are not finalised so I will not talk about them in this post.

Another role of mine was to create the Spyware model, an easy job thanks to the concepts of one of our team members and previous experience with 3D Modelling.

The spyware was a unit designed to look fast and dangerous, befitting of it’s role in Virion. It is comprised of a single sphere located in the centre of the model, two sharp pincer-like objects at the front and three small cubes floating at it’s back.


Modelling the unit was easy enough, as was rigging and skinning the model for animations (which we weren’t sure about having at the time).

Eventually the spyware unit’s rotation was altered, so now it looks like this.


Kind of like a rabbit, which fits the Spyware’s “fast” role a bit more.

I was also responsible for particle effects, not all of which had been implemented for the playtest. It’s hard to show all the particle effects exactly how they act in a screenshot, but my best attempt was made to make all effects fit their roles. I also gave blue particle effects a greenish tint (partially visible in Hit effect, takes place at different times from when screen was taken for most of the others) and the orange a red tint to make them more distinguishable on the game board.

Hit – Explosion outwards symbolising destruction of enemy unit.

Cap Unclaimed – Stream of blue or red going downwards to signify the player capturing the unclaimed tile for the first time.

Respawn – Rising blue or red coming out from the spawn tile, beneath the unit.

Move – Blue or Red trailing units as they move.

Cap claimed –  A carpet effect which is meant to cover the claimed tile as it converts.


I also created the placeholder instructions screen, something I tried to make as brief and to-the-point as possible, but also easy to understand. I think I did a moderate job, as most people who read them were able to play the game without issue. I did miss out on some crucial elements such as holding to win, which was a pretty bad mistake considering it’s how you win. Keyboard controls were left out, another mistake which came from me not thinking about the possibility that people might not be playing with controllers.

Virion Post-Mortem

Virion is a game that took me by surprise. When we first started coming  up with ideas for what it could possibly be we had made a game that was overly complicated and not exactly a friendly experience for players. With that said, it was kind of weird how an idea for a game that was so confusing and difficult could turn into something that turned out as well as it did.

From here on, I’m going to refer to the pre-tuned version of Virion as E.V., or Early Virion for the sake of simplicity.

When we first started brainstorming ideas for what Early Virion could be, it felt like we were attempting to think of a game with too many mechanics but not enough space, if that makes sense. Players would gain Action Points for performing certain actions, things which would determine how many things they were able to do per turn. Units would have health, something which created awkward contention around the areas which granted players AP. Some units had over the top abilities, things that seemed to have no real place in a strategy game. In short, it kind of felt like we were making Early Virion a really really awkward fighting game as opposed to the strategy/tactics territory game we wanted it to be.

Luckily though, we underwent a process which allowed us to refine our idea, strip the excess mechanics off of our game and give us the game we ended up creating.

What Went Right?

A massive contributing factor to Virion’s end result was the process of project tuning. It helped us strip all the “fat” from our game so we would be left with something that was less, but still more. We were forced to ask ourselves why we chose to take the path we did with Early Virion and also analyse and question parts of our game we thought we were fine with. We were going to attempt to create a game that was fine in terms of scope, but still too big for our core idea. Our units had no meaning or symbolism at the time justifying how confusing or over-the-top we were trying to make E.V., and as the game’s territory is comprised of Hexagons there was no real symbolism to that either. Our Units weren’t soldiers trying to capture land or defeat an enemy in defence of their kingdom, and our territory wasn’t signifying anything. It felt too simple to have so many extra things like health, action points and control points tacked on.

Prior to the initiation of development for Virion we assigned roles to each of our team members, with no one person focusing on a specific role. We were able to tell each other what we could and couldn’t do which allowed us to assign roles accordingly and prevent any major roadblocks in terms of ability. Where we lacked we were willing to learn, and we would ask for each other’s help if we thought we needed it. The members of our team were also skilled in their areas of expertise. This allowed the development of Virion to go smoothly, with minimal setbacks occurring.

What could have Improved?

Our biggest issue from the brainstorming stage to just before the final playtesting session was definitely communication. While development of Virion did go smoothly, we barely talked or conferred on anything aside from class time or the occasional Facebook post. We had a total of 2 Skype meetings which proved to be immensely helpful in terms of having tasks set and concerns/questions discussed, but a lot more could have been gained from bi or tri-weekly meetings instead of the two we did have over the multiple weeks of development.

Virion turned out as well as it did because of good project planning, documentation and each of the team members working to make the project as success. While it may have run some rough ground in the early stages of planning, the core idea was what allowed us to create the current version of Virion that exists today. Virion was an enjoyable project to work on with a result that has been very rewarding.

Virion and playtesting

So a couple of weeks ago we were given a brief to make a discontinuous game that could be played by two players locally with controllers. For those of you who don’t know what a discontinuous game is, it essentially just means turn-based. Our first idea was confusing, disjointed and as a result kind of difficult to play. We stuck with it for a week before scrapping the idea for something similar, but much more simple and fun. The new idea was a game similar to chess, where two players would face off using 5 different pieces of 3 types, with the goal of using those pieces to capture as much “territory” as they could to win the game. We made a working version of the game in a week, and from the reactions and feedback of the people who came in to playtest, as well as the feedback we’ve had from our tutors, it seems we’ve been successful in creating something that fits the brief and is also very fun.

The playtesting session was very interesting to watch. People were laughing as they played, talking about moves they had made and generally seemed to be having a good time. The overwhelming majority of people who started a game played until either someone had won or a stalemate-like situation had been going on for a long while. Players were able to figure out what to do very easily without aid (some without even reading the instructions) and aside from some very small, minor bugs, the game itself ran smoothly. The feedback we got was also very positive and helpful, and the footage we received of gameplay was for the most part entertaining, and also quite enlightening.

We still have some more work to do on the game so it can only (hopefully) get better, especially now that we have certain knowledge that our game is in fact effective at what we made it to be and people find it enjoyable. The feedback we have received from both our facilitators and playtesters  has also given us a very good idea on which areas to focus on and what to do next.