Introduction:

Part of our practice to make user friendly tooling required us to make a fully modifiable version of doom. Which has got to be one of the better projects to work on (any excuse to play doom and i’m there)

So our requirements was to recreated doom entirely but in unity, taking into account User stories (ie. Things that users of different professions and backgrounds would want to do with or to the tooling)

Some examples of this includes:

• As an AI Developer, I want to be able to make the game run at an accelerated rate so I can more quickly test my AIs for effectiveness.
• As a Game Modder, i want to be able to change all damage outputs

So our main goal apart from making doom was trying to accommodate as many of these as possible.

Planning:

Planning started with us making a list of basic components and functionality to make the base doom game, with our intent to build up the extra functionality and mod-ability  upon this base. So these were compiled into their own separate tech spec documents, this way we had an idea of what each individual components needed and built from there.

Fast forward a week

Although progress was being made and functionality was being brought to life, it was becoming apparent that once we started to try and combine these components that things just didn’t work.

Why was this? 

Well because we spent time looking at things individually, we lost sight of the big picture and how these things would talk to each other. Which when you have this many components and variables is a serious issue.

What could have been done better?

Honestly our results wasn’t through lack of effort, it was poor communication both in our design and interactions. By making a full Tech spec including all components we could have pre-planned this, i’m willing to say we could have taken this even further with a Uml diagram. At a point it becomes hard to track everything and visual representation is a great way to deal with that.

Where are we now?

Well right now we are in damage control, fixing the issues with have with compatibility of components. However there is a light at the end of the tunnel and things are starting to actually come along.

Functionality:

These are some of the functions currently working in our game:

• Scriptable Weapons, Ammo, Projectiles, Pick ups, Audio
• Player Controller
• Enemy Controller
• Audio Manager
• Enemy AI
• Switchable weapons on Player
• Pick ups
• Player and Enemy Damage
• Ammo

Visual Assets:

We wanted the assets to have a modifiable feel to them and by that i mean accessible to all skill levels of users. So we have been using a simple creation tool, “Magicavoxel”. It can create both simple and complex assets but it simple enough to be picked up in a day.

Watch here

Progress:

Progress has been slow on the tooling with doom, i’m not sure about Dan but personally i haven’t been too invested into the project. This for me personally is because it feels like we have put a fair amount of effort into things with little progress into the total project however today that changed.

Update!:

Today we had our first case of user stories, by that i mean we made the tooling accessible to different audiences based on what their wants and needs would be. So our peers tested our tooling and for the first time got to see the wonders (and horrors) people created from our project.

We have a few bugs that need working out, however for the first time i saw the potential in our work. Which has filled me with drive to create more user stories with more variables.

However this will be put on hold for a few weeks as we have other tooling to create, to assist the others in their projects for the end of trimester.

Audio Assets:

Currently we are just using some place holder audio, Just some lines i read into audacity.

The overall goal was to have a mean sounding player and enemies (trying to replicate the doom vibe) however it should be noted that these are just placeholders currently and have a element of comedy to them. (Ie. saying “Bang” every time a gun fires)

The sound was then processed, first removing clicking noise (The microphone i was using to record it just from a headset so the quality isn’t amazing) and then reduced the speed of the tracks to give a deeper, darker sound to it and then added some Wahwah, which came out a little dark and demonic.

These were then implemented into unity through our AudioManager, Video example below:

Watch Here

Doomin Pivot:

Today we had our first case of user stories, by that i mean we made the tooling accessible to different audiences based on what we think their wants and needs would be. So our peers tested our tooling and for the first time and we got to see the wonders (and horrors) people created from our project.

Not all went to plan, our initial intent was to make a the base doom game and add the user stories and variables to that. However poor planning and subsequent time restraints means that the base game was never completed in time for this testing.
That being said it didn’t stop our peers from creating weird and wonderful things from our incomplete tooling.

Highlights included:

• Raid bosses
• Walking on a tornado of enemies
• Rooms full of bullets

Watching back this recorded footage gave me insight into what we should be focusing on, variables and user stories. After all, despite our tooling being incomplete, people were still figuring out how to have fun with it through variables.

Sure, some of the interactions shouldn’t happen all the time (Ie. being able to “surf” enemies) but why shouldn’t that be a feature that they can choose to add?

This switch in focus has already lead to the creation of new systems, such as Cheat codes, Halo style re-gen of shields and health and with more to come.

Post mortem:

If you want to read my final thoughts on this project go to

https://www.gamedev.net/blogs/entry/2265300-toolin-around-doom/