Our Game Mind state is up on itch.io and you should give it a play here.
Another post mortem is here and its time to reflect on how it went and of course what I’ve learnt from issues.
This was something that we had in place before we even pitch to collaborators and this was a great move as we knew what areas that we need to cover and the areas of music and animations. There parts of our project were key for getting our feeling across over the course of the game. We found our audio guys were really appreciative of the longer time to work and get test audio to us and then have time to iterate on this before the 11th hour. With our animator who was making our sprites sheets for all of out character movement and the creation of the player character itself. This early collaboration allowed the tweaking and iteration of getting these to look just right and the way that we wanted. Have both in the design phase of the project had them on board with what we where thinking and allowed them to give input in the design and how to make all the assets for our game. This allowed for a smoother flow of things getting done and room for a lot more iteration.
Scope and Polish
From the start we wanted to keep scope low, well when it come to mechanic anyway so that we could focus on polish and work into the other elements that we felt were going to give our game better feed back for the play. Keeping the mechanics simple for player meant that this didn’t go unnoticed by the players.
Having collaborators early help this become a easy task from the star and allow us to communicate better with collaborator to know what is possible and to allow time for thing to come to a reality. Having clear scope of things that we needed and in the order of importance, we know how far we had to go and had come. this is something that can allow for the addition of extra desirable if a project meets what is need and add to the experience.
Roles and Workload
We gave roles to all our designers to over see the individual areas. This way if someone was working on schedule for example they have other relining on them to get things done so other know certain info of could go on with other tasks. This meant that tasks were completed and communication across the group covered just the area of concern for that individual. Having someone else you had to communicate and work with at different points in the project gave us all an overall idea of where the game was going, as well as our own individual tasks.
Having our own areas of the game that we had to make and also join with other in the team, had us both thinking our our own work but also had it fits in to the project as on a hole. This keep our work grounded and structured considering there were 4 designers working on the different parts at the same time, this was consider at the start of the project so that we would have members going in different directions with the design intent.
Simple is Hard
Lets make the game mechanic simple. Sound easy enough however nailing down what the simple mechanical is and if it is engaging and fun for players. This meant that getting this down early was paramount as our game feel hung on this this core. Designing the level was something that took time as this core wasn’t concert as early as it should have been. This impacted on other task going forward as the main feel of moving through this section wasn’t nailed down.
From this i have taking away the before making anything on a visual level the focus needs to get things move before all else, a rudimentary shapes move around a block to get the core there and then make it look good after that way you have what is need to start. otherwise you are just make a hole lot of pretty thing do really boring things.
Getting this core simple idea or mechanic is the hardest part. Once this is in place the things you add will only improve it only if you are not try to make the simplicity more complex. As with everything there is good and bad adding to a project.
Documentation and Source Control was Good but…
As with every project these elements work..ish. I mean that it has been the best so far but new issues arose. Early in our project this was something that was well planned and that everyone was on top of and contributed to. It was in the later stages of the project once we had gotten to the polish stage, the documentation began to lack behind and i feel this was due to other unplanned issues taking up our attention and time.
Source control work very well considering that we had 4 designers all working on the same project with individual scene and and a shared master scene. As with the individual scenes that worked well and we make prefabs of all assets in scenes so that if issues accrued we had a back of the asset. Doing this made work in our master scene loads easier as our work wasn’t doubled. However there wasn’t much thought put in how this master scene was going to be governed and how the work flow of this master scene would happen as element did inflicted on each other. this was an issue later in the project as several people all needed to work and refine this master scene.
Thanks for reading.