Reflective Blog
- Kartik Tiwari
- Jun 1, 2020
- 4 min read
Every now and then, we as developers should take the time to reflect on what we’ve researched and sum it up for safe keeping. Over the course of the last 9 weeks, I have written 4 research blogs and developed a game with my team. In that time,I’ve researched about topics ranging from lerping a sprite’s colour between 2 values for pulsing effect to photosensitive seizures induced by flashing imagery.
The Blogs
I’ve researched and written these blogs in such a way that i can keep coming back to them to be reminded of the basic design philosophies and ideas used by different developers to make their games exponentially better. Hopefully, these will help me make better design decisions in the future.
Workflow for research blogs
For the blogs that I wrote, I thought about the most interesting topics in game design and dug up a few articles and maybe a YouTube video. Which inspired my ideas. Whenever I started making claims or discussing my own opinion, I went back to researching that specific claim and find out a few examples of games (mostly examples I’ve already played and can vouch for myself too). This workflow might be nothing special, but I thought it’d be worthwhile to make a note of this for future references. Interestingly, many times I even got the conclusion to a blog before I even began writing the introduction.
Major research blogs written
A blog where I talk about a handful of games with an amazing soundtrack that blend in perfectly with the game’s vibe and how listening to the soundtrack which is minutes long, could potentially remind the player of the feeling they felt while playing the game for hours.
A blog where I look into photo induced seizures, major incidents regarding it and what developers can do to avoid it completely.
My longest blog, this was more complicated than I expected. I talk about how games need to be challenging and not difficult. I also talk about how we can go about implementing a good difficulty which makes the game feel fair (at the very least).
This one had so many things to research about, I tried going through all of them but even I couldn’t, so I linked a few extra resources that I did go through but couldn’t include in my blog. I mainly talk about telling stories in the less obvious ways.
How the Blogs Helped me Make Rock N’ Run Better
The first blog I wrote about the soundtracks, gave me the idea of releasing the soundtrack of our game. It serves many purposes; It gives the audio team more recognition, and motivation to make a good soundtrack; It increases revenue if this were a practical studio environment; and lastly, It can potentially also market the game really nicely and could be considered a cool collectible too (Vinyls/CDs).
The 2nd blog about photosensitive seizures helped me tweak our screen flashes and add a smoother transition to the pulsing effect of the lamps. Just knowing that features like these could cause someone problems was enough for me to be really careful with these features.
Other Research Done While Developing the Game
- Implemented Lerping a sprite colour between 2 values so as to give a pulsing effect (used in lamps and the HUD in Rock N’ Run)
- Watched a few GDC talks about sound and music during the concept phase
- Looked into a few 2D games with great animations to help my team with the animation
- Initially, we were going to include a colour blind mode, but we couldn’t fit it in our scope. So, I made sure that the game was less reliant on colours and mostly just reliant on the music and the beats. By that time I had already done some research on accessibility
Lessons Learnt From the Research
Accessibility is always a huge topic topic to consider while developing a game. When I imagine not being able to experience an objectively amazing game it just doesn’t sit quite right with me. Making an inclusive game is always helpful. It’s also a very hard thing to prepare for, so an extended lesson to be learnt is to always listen to the community and be on the lookout for any feature that’s causing discomfort or hindering a portion of people from experiencing the game.
One of the most important things I learnt from the Doom behind the music GDC talk was ‘Change the process, Change the outcome’. My submission weeks have always been stressful since trimester one, this time around I decided to ‘Change the process’ and by putting consistent time and work in my project, I can truly see the change especially in stress levels after implementing this strategy.
I also learnt that there are many games out there who tell their story in the most interesting ways, from bloodborne’s cryptic storytelling to Portal 2 and Edith Finch’s environmental storytelling to Florence’s narrative mechanics. Combine any of these elements with the more storytelling elements like cutscenes and dialogues, and we’ll get even more variety in storytelling.
It’s also worth practicing more art ‘stuff’. We could get only one animator who did some of the art, but all of the other art was done by designers themselves (I only changed the colour of a car from yellow to red in Photoshop though).
In retrospect I realize that this research doesn’t even scratch the surface of the pool of resources available online (not to mention the books one can find in any of the libraries). So, It’s safe to say that I’ve yet to learn a lot about game design/development and that it’s a very hands on and living process. Hence, it’s much better to be in the habit of doing research every now and then and recording them somehow, and Blogs are one of the best ways for doing that.
Comments