My 6-month, game project is just about coming to and an end and it is bitter sweet. Therefore I'm about to do a game post mortem. This post is going to be a lot longer than normal. This post mortem will follow the 5-5 method e.g. what were the 5 failures and 5 successes of my game development cycle. First of all, let me say that these 6 months have gone in the blink of an eye for me and yet somehow, for the most part, I usually felt in control. The game was created to run on P.C and is a 3D constructivist take on a gravity golf puzzler called ‘Swing’. This platform was chosen because it is an open and free platform to develop for, it has a wide user base and the fact that it is a P.C game means that I didn’t need to manage memory and or project size. Meaning this made the platform suitable for my first solo game. Before we start I do want to talk about a few things that I've learned.
DEVELOPING A GAME BY YOURSELF IS LONELY
Developing a game alone can make you feel isolated and lonely for many reasons. The biggest being that when you have a problem no one is going to solve the problem but you. When you work in a team however, you have the luxury of coming in after a day of banging your head against a problem and someone else has fixed it (This is a rare occurrence). Next, you can miss the comradery of working in a team. Sure, it's great to be able to make a decision at the drop of a hat and not have to justify your position to anyone, but most of the time debate can lead to a better idea then you started with. This is why in my opinion developing a game alone robs a student of learning. When working in a team you learn because you argue and grow your perspective. Working alone did make me learn something, the importance of time management because I had no team I had to stick to a task no matter what. Lastly, if you want to work alone, learn one thing quick "Don’t be afraid to Kill your darling's" this can mean a few things I'm sure but in this context what I mean is sometimes you need to get rid of some of your favourite ideas if they are not working, don’t be precious. Often this is can be because of ideas not being very good but because we see things through rose-tinted glasses we think they are amazing.
IF YOU CAN’T FIX A PROBLEM AFTER A WHILE, JUST CHANGE WHAT YOU ARE DOING AND THEN COME BACK TO IT
I learned over the course of my game development of "Swing" that if you have a problem. Research it, gather information and then take your best crack at the problem. After this has been done a few times when you are exhausted for options and or solutions, rather than ramming your head against a wall for hours, just do another task specifically a short one that can be done quickly. This does two things for the developer one it triggers a feeling of victory in the developer this can alleviate any feelings of stress or depression that the developer may be feeling. Secondly, it can jog the developer's mind. It may sound silly but sometimes when you figure out the answer to one problem your brain just works on figuring out the solution to another problem in the background without you really thinking about it.
DEVELOPING ALONE REALLY HELPS YOU TO FIGURE OUT WHAT SPECIALTY YOU REALLY WANT TO DO
This one is really simple if you decide to develop a game alone you are either going to
A) have one job that you enjoyed much more than you did the others.
B) you may discover that having the lack of a specific job can be really disheartening and remove some of your enjoyment from the development of the game. This can tell you a lot about what you enjoy but also why you enjoy it.
DOING A DEVELOPMENT BLOG IS IMPORTANT BECAUSE IT KEEPS YOU ON TRACK BUT MORE IMPORTANTLY, IT HELPS YOU TO VENT VARIOUS FRUSTRATIONS YOU MAY HAVE ALONG THE WAY
The creation of a development blog and keeping it up to date is more important than you know. At the beginning of the development cycle, a dev blog can seem like a pain and even a waste of time. However, you are wrong, throughout this process I have learned the importance of keeping in line, on track and most importantly accountable. It is so important especially when you're working alone to have a diary that you have to write in every day what you did and why. This technique will be especially effective if you have a mindset of not wanting to disappoint yourself, your superiors or your audience and this will aid you in your quest to making a game. Having a dev blog teaches you how to vent your 'work-place' grievances in a safe environment. If you feel as though someone is bullying you then you have a place you can discuss it and this lets you think. It can also be very helpful to express your technical or design problems to the aether. This is similar in technique to talking to a rubber duck, where you explain your problem to a rubber duck and as you explain it, you figure out the solution. In future, I will try to always keep a dev blog and a physically written production planner simply because it helps me to formulate my thoughts, feelings, ideas and processes at either end of the day when I use my Dev blog or at the beginning of the day I use my production planner.
https://xocdarb.tumblr.com/
1) Planning an assignment six months before you start it is a waste of time.
2) Re-name and organize/ delete things early.
3) Don’t be afraid 'Kill your darlings'
4) Go slow and you will only have to do something once.
5) Don't be afraid to redo something that works.
This is the part of my post mortem that I have to be blunt with myself about my game. The game is 'Fine' and I mean that in both a positive and negative manner. In this paragraph, I will discuss the negative connotations of that statement. When I say this game is fine what I mean is I don't feel it is anything special. I think that it is a fun one-button game that is worth people's time but not their money. This game is in part an art piece it’s a living breathing gallery.
The mechanics of this game are fun but rather simplistic for the simple reason that when I found something that worked I had a tendency to either alter it a small amount or nothing at all. Before I started this project I had planned my assignment down to the wire and then about half a month into the assignment I changed the game and assignments entire focus this proved my prior planning to be a waste of time and resources.
Part way through this assignment I was told by someone that I should delete all of my unnecessary files. I deleted a few over the course of the project and at the end of the assignment, overall though I was so scared of breaking something that I didn't want to delete anything. This makes my game file bigger than it has to be and is more of an irritant than an issue.
The 'Not being afraid to Kill my darlings' issue. I was far too attached to integrating voice recognition into my game for far too long. I should have heard the critique that people were giving me internalized it and then gotten rid of the game's dependency on voice recognition immediately, instead, it took me weeks to come to this milestone. This process did teach me how to cut things that don't work without mercy, which is what I did for the rest of the game's development.
Another big issue for my game was that I rushed things that can't be rushed. For example, the art style that I ended up using for this game was 'Russian Constructivism' this is an art style that requires every angle and colour to be considered. With this in mind at the beginning of my process, I did not do that I just drew something that looked cool and modelled it. I didn't consider how the angles on the inside would affect the bouncing ball. Doing this I made level after level unplayable and worse yet not at all engaging or fun. I did this over and over again until I finally learned, I took my time and I planned the balls angles of bouncing and then after that, I planned the art intentionally around it. This process took longer, every level at the beginning of my project took almost half a week but as I learned I sped up and now it takes a day to make a level.
I would say that my last big failure on this assignment was being afraid to change something that works. This could have many reasons; confidence or skill it doesn’t matter. I am an aspiring junior rigger, I can code and I can model / texture. This being said my coding, modelling and texturing ability is limited. This had an interesting result on my game which is once I made something that worked, regardless of how much time I had to do the task. I didn’t want to re-do the task mainly out of fear that I would break it and not be able to replicate the result. I think this lead to a lot of mechanics, models, and scripts being ‘Fine’. This along with the ever-looming deadline of the end of our project approaching lead to a lot of my work being done up until a point and then having to move on because of time constraints.
Fear was the killer for me on this assignment. I think that my fear of taking risks, or redoing content and even standing behind some of my choices really hurt me on this assignment. With this in mind I know I grew as a person and as a creator over this process but that doesn’t mean I’m not disappointed in some respects. The disappointment doesn’t come from the game it comes from me.
At the beginning of this assignment, I was swinging for the fences, with a 3D narrative based voice recognition game and I examined it and there were massive scoping and technical issues. So I did the wise thing I made something smaller and more fun and while logically I can look at the problem and say I did the right thing. Sometimes I feel playing it safe does leave a bitter taste in my mouth, it’s like admitting to yourself that you don’t think you can achieve the alternative. In thinking about it now I should have also used Git-Kraken from when started. I started using it a month or so into the project and It saved me a lot of time and effort. Originally I was just uploading an individual file to the shared file every day but as the file became larger and larger this became unobtainable. Eventually, I did migrate over to Git-Kraken and get everything set up in the proper manner however once again it was my own fears an uncertainty of self that held me and my project back. I was worried if I didn’t know how the Git Kraken worked or if it broke how to fix the problem, so I choose not to engage with the service. Once I chose to use Git Kraken I learned new skills and could progress at a much more rapid rate.
Twitter: https://twitter.com/xocdarb
1) Planning my production schedule.
2) Keeping a considered art style the whole way through.
3) Making my level designs feel at home in the game's world.
4) Listening to/ sorting through appropriate critique.
Now it’s time to count the ways that I actually succeeded in this assignment. Before we begin I will note that I find it much easier to give negative critique to myself as to me it really feels like I’m gaining knowledge. Whereas when I give positive critique to myself it does feel as though it rings hollow to me. That being said, I think I planned my games development path and then executed on that development plan extremely well. I think that this is one of the single biggest factors as to why my project is in the position it is in during these last few weeks. I would say for future reference that planning out every week’s tasks (including unexpected event weeks) is imperative to an assignments success of any nature.
In the future, I would also use Trello from the beginning as it was instrumental to my success because it gave me a physical reminder to do certain tasks on certain days. In truth, I felt disappointed if a task I was working on could not be completed on time. Next, I felt that I kept a considered art style the whole way through the game, from the ‘Splash Screen’ to the game's menus and then through all of the levels. This was an amazing achievement for me. This required me to dive deep into both the constructionist and suprematism art movements visible in the early 1900’s. I had to learn the art style and then consider what every plain and angle would look and feel like to the player. One of the other big wins for me on this portion of the art was that I think I telegraphed the way that the level should be played/solved well. I used Trello to list my tasks per week in a checklist. Once the week’s tasks have been completed it is dragged into the done folder. This helped me to keep in mind what tasks I needed have done and by when. This method also helped me to keep in mind if I wanted to spend more time on a task what the immediate repercussions would be on the next task.
https://bradcox.itch.io/wobble
Over the course of this assignment, I received a lot of critiques, some of it from leading industry professionals. One of my biggest victories in this assignment I had, is that I finally learned how to control the influence these critiques had over my assignment. To clarify in the past, I have received critique from people and just assumed that their knowledge was superior to my own on the subject and enacted changes without really thinking about the repercussions on the assignment as a whole.
However, in this assignment this wasn’t the case, for example, there was a point that an industry member commented that in my game there should level splash marks on the walls the ball hits and rather wasting weeks trying to replicate the results of an off-handed comment I simply discounted the statement. I took time to internalize the critique and came to the conclusion that the real issue that the person wanted to see remedied was not the lack of paint on the screen but the lack of immediate feedback from the games stimuli. I also think that in this assignment I was more open to critique as a whole because I knew that my process was to listen to what the person was saying and then decide what the true meaning behind the words was. This meant that when I heard something I thought was wrong I was more flexible and accommodating to the critique givers reactions.
The last thing that I would consider a large success in this game assignment for me is how I polished my game. I feel like that this time because I had a clear plan and end goal I was really able to push the quality of my game because of the amount of polish I was able to give it. This gave me time to fix little things meaning I felt relaxed enough that when I did receive further critique on my game I didn’t freak out and or panic that I would not have enough time to fix my issues. Having said that I think one of my biggest successes/ personal growth moments of this project was realising that I label things ‘Good Enough’ and then leaving tasks at that level. This has been a big problem for me in everything from my game design to my Rigging and I do think that now that I have acknowledged this fact I am taking the right next steps to furthering my career and my skill set.
This graph is a measure of the overall engagement of my game over the last month. My return/ replay factor including playtesters sits at about 7 active users. My active users return rate is currently at about 0.67% - 0.14%. This means there is a 0.67% - 0.14% chance that someone on a daily basis is downloading or visiting my games itch.io page. This is a great indicator of how fun my game is. Unfortunately, the trends shown below appear to display spikes in the engagement that happen to coincide with my games significant playtest and or critique opportunities. This graph shows positive expectations for my game upon release.
The graph below represents the number of active players that I have at any one time. The blue line is the number of unique players that I received by the game in the last 30 days, the green line is the total amount of active users I have per day and finally, the purple line is the number of first-time users for my game. This constraint (Even if it is ever so slow) trend of increase in the blue line makes me feel confident that my required audience is being engaged correctly.
https://bradcox.itch.io/wobble
Moving forward is always a difficult part because a lot of the time you learn an important lesson and then you forget it for the first few weeks of your next assignment then before repeating to many of those same mistakes your brain starts working and you remember all of the solutions you learned previously. This often happens to me before any significant time is wasted. That being said, the lessons that I learned here in this assignment are varied. Some of these lessons are personal and have taught me that next time ‘fine’ isn’t good enough. Whether it is a rig, or polishing a game or a model, it is important to note that in future I need to walk away from any project knowing that I really refined my work until it is a cut above.
I think the other big thing I would do next time is to not be so scared of failure. As I’ve said there were times in this assignment where I was worried about breaking something so much that I didn’t want to redo or take time to streamline my processes.
At the time of writing this I believe that I am on the right path to fixing this issue as I solved one of my biggest issues, an error that says ‘Particle texture type read and write needs to be enabled’ by making sure I had a back-up of my project (Keeping me in a measured state of mind) and then going through a copy and deleting each group until I found the group causing the issue. Then I took the items from that group and deleted them one by one until I found the item that was causing the issue. After I found the item I kept drilling until I found the issue component. I think that this shows a mindset shift about the importance of doing whatever you have to, to solve the issue even if that means to rebuild something. I hope this change in mindset is the start of my growth beyond being a junior in my field.
https://xocdarb.tumblr.com/
Twitter: https://twitter.com/xocdarb
Instagram: https://www.instagram.com/xocdarb/
https://bradcox.itch.io/wobble
titsay
dailybridgerton
annaxmalina
yousharknotpass
izzy806
gummygunk