Jump to content
  • Advertisement

Toolin' Around, Doom

Ben Walker

1065 views

Post Mortem: Toolin’ Around, Doom

 

Introduction
As part of our practice to make user friendly tooling at SAE Qantm, we were 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). This project was a group project

The requirements were to recreated doom entirely but in unity, considering User stories (i.e. 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

Our main goal apart from making the base version of doom was trying to accommodate as many of these as possible.

 

What went right

1.      Scheduling and task assigning

We were given five weeks to get this done, which sounds longer than it actually is, however from day one we were on the ball, organizing scrum method and channels to communicate on. Tasks were assigned on a weekly basis and split between us. These were followed up by weekly meetings to confirm and assign new work.

 

2.      Learning new skills

Speaking from my personal experience with this project (I’m not so sure about Dan), this was an opportunity to brush up on patterns and learn new skills. This included;

·         The use of Scriptable Objects, both for containing data out of runtime and ease of use for interfacing. 

·         Improving coding patterns, Using the case, commenting and summarizing code

·         Using Events.

 

3.      User Testing

Through hosting successful player testing, we were able to see how are tools were being used and more importantly interfacing issues that they had. Spoiler alert, there was a few issues.. however, players managed to turn our errors into fun.

If you have never rode a tornado of enemies while traversing doom, you’re doing it wrong.  

 

The way we worked

As mentioned previously, this was a group project, however we really didn’t really treat it that way. We would meet twice and week and would rarely message each other outside of that time. Just focusing on our assigned tasks and then showcasing when we would meet up again.

This proved to be problematic  

 

What went wrong

1.      Communication

Even though we did have regular meetings weekly, this wasn’t enough to be effect in the timeframe we were given for the project. Sometimes going as long as not talking to each other for three days. This caused issues both with the speed and which things were completed and ultimately the collaboration between our separate systems.

 

2.      Combining designs

Considering our systems were split and created in their own sections, we had many issues trying to get things working together, normally hacking them together in the times we were meeting. This cut into our design time and generally left us with a lot of unresolved issues.

 

What to do in the future

1.      Communication
Even though we did set up channels to talk to each other, in future using those channels more effectively by working together on technical design, assigning of tasks and completion of tasks in beneficial to the project.
 

2.      Technical design

By working together and creating shared documentation and diagrams, by having a greater understanding of each other designs, issues can be spotted before they are in production and then addressed. 

Having some sort of waterfall method or at least a version similar to that would prevent design and game logic from being changed at a later date. Minimizing the issues related to poor or conflicting design.
 

 

Conclusion
Overall, I had mix feelings about the project, the outcome of it was kind of disappointing. But if I reflect on what the experience taught me instead then it was quite successful. I learned new systems and new skills as both a developer and programmer. 

 

Development stats

·        Developer: Ben Walker, Dan Ackroyd

·        Length of development: 5 weeks

·        Number of developers: 2

·        Development tools: Photoshop, Magicavoxel, Visual studio, Unity  

 



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!