Dev Log 10: Postmortem (Retrospective)
3/13/23
I've heard the term "postmortem" in multiple contexts. Originally I thought it was for a reflection after a failure, but generally I think it can also be used to describe reflections after something is done. That's kind of weird, since it invokes connotations of something being dead. It is true that we are not going to continue development, but Project Movement isn't dead, it'll live forever, in our hearts! So let's just call this a "retrospective".
By the way, the Project Movement source code is now public on Github! Do take a gander at it if you're interested in how we structured our project or implemented some features. The code's not all that pretty, but it works and it is somewhat well designed (enough for our purposes).
Anyways, for this final dev log we'll discuss the development of Project Movement over the course of the Winter 2023 quarter and lessons, takeaways, etc that have come out of it. Apologies in advance for the excess of text on this one.
Convention
The CSE 481D Convention/Demo Day was fun! It was really cool to see people playing our game again in person after we had made improvements to it. We hadn't actually seen people physically interact with our game since it was just a grey rectangle jumping around a single level all the way back in Dev Log 5, which was ~5 weeks ago. Players seemed to enjoy the game, with most people playing through most of the levels. We even had a good amount of players attempt and complete the final level of the game, "Pillars". Something about us saying it was the last level and it was hard made people want to try to beat it. Some people got frustrated, but it also seems like they felt sucessful after completing it. So may be we succeeded and people had fun.
It was also cool to see the other teams in the capstone with their games. Go look at the team websites for the capstone course to find links to their games. The other teams had enviable posters and put a good deal of further polish on their games from the last time I saw them.
Godot
Using Godot was good! I can't think of any complaints or limitations caused by the engine itself. Now that the CSE 481D logger script has been re-written in GDScript we hope that future teams in CSE 481D will be able to use Godot. The Godot experience is pretty nice, and it is quick to test out new features. To future teams, we developed in Godot 3.5! Godot 4 not be compatible with the translated logging script. I would also recommend waiting for Godot 4.1 if you want to use Godot, since some features are missing from the 4.0 release.
Git and Godot
I will recommend that if you do use Godot and also collaborate with Git/Github, it is
worth being careful with how that interacts with Godot. Godot saves scenes and resources
in text-based formats (.tscn and .tres), which makes it more friendly
to VCS. But, merge conflicts can cause these to diverge, and if you don't resolve merge conflicts
very carefully, stuff will break without sounding any errors. One particular instance that
happened during development was that stuff just stopped working after resolving merge conflicts.
Turns out that Godot's .tscn files have external resource declarations at the top, which you
can think of like importing other files. Only, the way they are declared attaches them to a numeric
identifier, and it is this number that is used for all further references to the external resource in the scene.
Merge conflicts where external resources have been added in both base and incoming versions will have those
resources with the same ID number! Carelessly resolving the merge conflict by accepting both changes
will mean that only one will get loaded with the ID, and the other simply won't work, and no errors will be indicated.
A small point of frustration with using Git and Godot is that sometimes Godot appears to cache
a version of project.godot in memory, and periodically dump it to the file on disk.
This doesn't happen on save, it just happens regularly. So if you use Git and change to a version
of the project where project.godot is different, Godot will silently override
it with the a now incorrect version, even if you select to reload it from disk. The only workaround
I could find is to quit the editor back to the project list, then change around project versions with Git,
then open the Godot editor project again.
Also, if changing branches with Git deletes scenes, they will still be open in the Godot editor since those are kept in memory. If you are in the habit to just spam CTRL+S like I am, those get saved back to disk again, effectively un-deleting stuff. So be careful when you change branches.
Art
Here's a spiel I wrote while reflecting on the art of the game not long after we implemented art assets:
One of the things that our game lacked in early builds as any semblance of art. For the longest time, it looked like just a prototype hacked together. Even when we had playtesters play it, the game's visuals still only consisted of colored rectangles.
I think that this was a pretty big impediment to our game's development process and experience to players. If you boil it down, playing a game is just looking at an array of colored lights and periodically pressing some buttons on a board based on the lights. That sounds really boring, but it is essentially what playing a game is, physically. The important aspect that makes games engaging is what is in the players head as they are looking at the array of colored lights. How the colors are organized and how they change and what visual patterns they evoke in the player's mind form an experience beyond just staring at colors and pressing buttons.
This is why our game felt weak for the longest time, and why it feels much better after adding art. Art is fundamental to a game, and we should probably have prioritized it earlier. Even not making our own art, grabbing a tileset and character animation pack from someone else on the internet may have helped our game's experience and our experience of the game by leaps and bounds. Having art means the game can evoke images and themes in the player's mind. It's easy to understand an animated character moving around, since we are used to humans moving around and characters normally look like humans. It's less visually appealing, and therefore less of a familiar experience to just see a grey rectangle moving around. This decrease in familiarity likely leads to players understanding the game less, and feeling like the experience they get from it is weaker since it is not as immediately obvious what is happening. As one of the developers of the game, I do understand the intricacies of what is happening when the grey rectangle moves because I implemented that, so even early on, Project Movement did feel like a game to me. But to others, who don't know the inner workings, can't tell what is going on, or how, or why. They don't know how their actions influence the world, or the character, and they may find it hard to associate and learn because they can't associate the visuals of what they are seeing with an actual character and actual world.So basically, our game created a weaker/lesser experience for players when it didn't have any art, and this was a significant issue since it engaged players less, and they may have been less attentive to other aspects of the game.
Collaboration
I remember one of my earlier courses at UW tried to teach us how to do group work by deciding roles like driver, notetaker, and so on. It felt unnecessary for the work that we were doing, so we mainly ignored the roles and did group work like always. However, I can see how this might have been useful after working on Project Movement. Projct Movement was a markedly different type of project because it spanned many weeks and involved our own designs and initiatives. Since it had a larger scope, keeping track of what was said, driving meetings, and keeping people accountable for their work seemed to be more important, and since we didn't have any roles or clear divisions for work, our effectiveness wasn't great.
We also couldn't find a time to meet regularly each week to check in and re-orient. A lot of the time it was easy to focus on work for other classes and not communicate about progress or not make progress for extended periods. I think it would have definitely been better to have set some time, but our schedules just didn't work out this quarter. Inconsistent workload for other classes and a slew of more difficult/work intensive courses for all the members of our team led to us making less progress than we could have.
Especially early on, we had made verbal agreements to do work on different parts of Project Movement. That didn't work too well because some of the other parts depended on core parts being finished or at least prototyped first. We also had some struggles with getting Git set up correctly. I had gotten affirmation from everyone that they were OK using Git and Github, but I didn't consider that some team members' level of familiarity with doing larger projects wasn't the same as mine in that they had not previously worked alognside many others in a single Github repository. We also had members of the team using Git in different ways. For example, I like to commit small changes as long as I think they are atomic, and then push early and often. Other team members preferred to make a significant amount of progress and only then commit and push. Since backing up data is not a main reason we used Git, it's not an issue that some team members don't commit and push often. Still, it would have definitely been warranted to have a discussion on how to use Git/Github and perhaps establish consistent practices for collaborating using those tools.
Games as Systems
I think it would have been interesting if we had more time to consider game design formally. Even so, what we saw from people playing our game and giving us feedback was a sort of system design experience that was totally new. Not only does a game form a system in the way that mechanics interact, but when a player plays a game this also forms a system which includes the player and the experience of the player is another aspect of the system. In this way, the many design decisions and tradeoffs involved with developing a software system apply in a unique way, where there is no rigorous set of requirements, and the testing of the system doesn't just result in a binary pass/fail. This was therefore an utterly unique experience in creating software, and I think it was a valuable one to have.
Since the games capstone resides in the CSE program, I think it would be potentially valuable to have explored games as systems more formally. I learned about the MDA approach, which is a slightly more rigorous approach that I think might have been useful to consider when we were designing our game. We did have aspects like intended player experience in mind, and what sort of mechanics would lead to that, but we didn't have anything concrete. As we got more feedback from players, we had a more clear of how the dynamics of our game impacted player experience, and adjusted the mechanics in order to address it. Overall, we realized that when many mechanics are combined in the same system, there are many more configurations for the player-game system. Some of them aren't as desirable. We saw players often moving in unintended ways, breaking our game or not getting the experience we wanted them to have. Like the MDA paper illustrates, since the creators of a game fundamentally see it from a different angle than the players, what sort of knowledge is intuitive changes completely, which changes how developers and players interact with a game. Desinging an experience without being able to experience it is truly a difficult problem, and game creation an complex task as a result.
Indie Games
CSE 481D wasn't about game design though. Even though we designed a game, the course also focused on the other processes surrounding creating and releasing an indie game. Stuff like social media presence, building hype, getting people to play, generating marketing and visual materials, all of that was very interesting to see. Particularly I would want to compare it to trying to make an indie game without even learning about what we did in this course. That would require studying other indie games closely to see exactly what visual and marketing elements they create and then trying to do the same thing without any guidelines. That would be really hard. So, I think that having the knowledge from this course could be very useful to have when seeking to make and properly release an indie game.
Although, making stuff like the key visual, Kickstarter mockup, presskit, social media presence, and website wasn't really as much fun as working on the game though. So I can see how those important things might be ignored by game devs. I think I might have gained the equivalent of a year or more worth of experience and knowledge about making indie games from this course relative to if I were to try to set off on my own and make an indie game without having taken this course. That is very valuable.
Thank You
If you are still here reading, commendations to you. Thanks for reading my rambling dev log writings. Hopefully there is some worth to the thoughts that I've put out above here. I'm not sure if I said everything I wanted to say in the way I originally wanted to say it because I had thought about some of these topics a while before this dev log. But now it is all laid bare, hooray. With this dev log now finished, I think that will mark the end of work on Project Movement. Again thanks for reading, thanks to the course staff for the support throughout the quarter and for running the course and giving us the opportunity to develop a game.