Where we are at with Triage

So as of today (being the 29th of November), we had our last play-test yesterday which should be the more or less finished game with polishing. We have until this Friday night to upload the builds of our game to itch.io.
So here's what has happened with Triage for the past few weeks...

Game Feel

This is something we've had trouble nailing down, we've been through different iterations of gurney movement, map design and control input. First we had a physics related movement system which involved using the mouse and dragging the gurneys in the direction you want them to move. The speed increased over time for the longer the player was dragging it, this is something we've gotten feedback on to switch over to "how far the cursor is from the gurney, should dictate its speed".

Currently, we've ditched the physics implementation that for a controller input method where the gurney's had a set speed they travel at the player simply moves them around using the analog stick. Even this current implementation has it's bugs (The gurney sometimes just wants to only move left and a high velocity).


The feedback received from the play-tests really gave us an idea of what players thought about of the game. Going back to their interpretation of the game from either the pitch or what was explained throughout the development.

Sometimes the changes we made to address a certain point in the feedback created an issue where it wasn't implemented properly, not exactly what the feedback suggested. Or ended up creating more bugs which subtracted from the user experience.
Either way I felt like we never sat down as a whole group and went through what we needed to do to address what we've been given for the next play-test. This did happen to a degree but we've always had at least one or two members away that day and then either they lack catching up on their own accord or we simply get too invested into what we're trying to address.

So for a "next time", I really want to address this with whatever group I'm working with, so we can lay down a foundation that we can build upon for that project. Which lets us do these things with a great deal of efficiency and time management.

Work Load

Something that seemed quite evident with this project. The work load was distributed with our management tool (HacknPlan), but it ended up being that one person was mainly doing the committing this project.
Note: I removed the names and avatars from the cards so it doesn't look like I'm pointing fingers at one person (not that I am). This is more of an observation that I noticed.

#1 held 26 commits being the most for this project. Either the other devs simply compiled more changes into each commit which is a thing that people do in Source Control. Either way, another somewhat large thing to point out is the commit/changes over the month of development. You can gather that towards the end of the project, commit frequency spiked which is a possible symbol of poor time management as you shouldn't leave everything to the last minute.

So from what I'm taking away from this, is that Team Communication needs to be improved, along with Time Management and the effective use of our management tool, HacknPlan.

Tom Lynn

Read more posts by this author.

Australia http://rubbix.net