Diabolus in Musica Postmortem

Diabolus in Musica is a horror visual novel I made in a month for the Second Annual Spooktober Visual Novel Jam hosted by DevTalk+.

In this article I’m going to discuss what went right, what went wrong and my plans for future development. I’m also going to include some critique of the work – I’d originally planned a separate post for this but I’m finding it difficult to separate the two.

Scope

Everyone’s favourite topic – scope! I’ve generally gotten better at scope over the past couple of projects I’ve done – because I’ve actually finished them! This jam lasted a month and all materials barring concept work had to be done within the time frame.

With Diabolus in Musica, the actual amount of content I aimed to deliver within the timeframe was well scoped. My initial plan of five character routes was immediately taken to two, and when I realised I was running out of time I cut the number of endings from four to three, ensuring the remaining content would actually be finished.

All five characters – only two have routes within the game.

However, I wouldn’t call the project well scoped. The story I wanted to tell didn’t fit well into the one month creation period. It needed time to breathe that I couldn’t give it. The audience needed to see how the mc’s relationship to their five friends developed – how they met, how they became friends and how the relationships changed as it became clear that mc was no more than fodder for Niccolo’s plans.

My major influences were books where the plot and themes revolve around characters who at first seem glamourous, untouchable and admirable, but through the eyes of a naïve outsider, the reader learns the dark truths behind the glamor. This sort of tale just can’t be told over a half hour visual novel. I needed a far larger project to convey my meaning and create an engaging experience.

Based on the positive responses from friends I’m considering maybe continuing the project in the new year, but I want to finish up other projects and see how the streamers from the jam react first.

Time Management

I had absolutely zero time management for this project. I worked on it whenever I felt like it, got distracted and did things like try to write my own particle system which was abandoned, and spent more time on the sequences I liked than the ones I was less keen on. It was a bit of a disaster that led to a hurried last week.

There’s a lot of value in playing around and experimenting, but not when you have a deadline!

The last time I did a game in a month I spend an hour on it every morning before work, then a little more at weekends. This was a good pace and one I’m going to employ for further projects with this time frame. I do think a month is a good amount of time – its enough that you don’t crunch, is long enough to make a complete product but also short enough that if it doesn’t work or you don’t finish it wasn’t a waste of your time.

Another note on time management is that that last game jam was completed in March. For obvious reasons my mental fortitude was significantly higher at the time, and that had no small impact on getting the game done.

Pipeline

My general pipeline for working on visual novels has been…not to have one? I write all my dialog directly into my IDE and add expressions, effects and sound at the same time.

From talking to other VN devs it appears this isn’t common practice, and most write their dialog and narration in a separate screenwriting program or in something like twine before then copying into their game code.

This isn’t to say I don’t plan anything – I have outlines and diagrams on paper but its all fairly loose.

I’d like to try planning in an external editor and see how this affects my process and productivity.

Another issue with my pipe for this was file organisation. Because this game was more route based and less linear than my others, rather than numbering each scene and separating them out, I made files for each of the characters. This was beyond confusing and I wouldn’t take this approach again.

Writing and Characterisation

Something that I felt undermined the overall quality of the game, in conjunction with making it more difficult to write, was that both my mc and the characters they interacted with lacked consistency. This was in both personality and tone/word use.

The expositionary narration and the actual character’s dialog didn’t match up.

When I was writing January Edwards: PI, I had some strong characters who had been bouncing around in my head for a while, so I had a good idea of how they would talk and react to situations. With Dream Dilemma, the characters were less defined but they were heavily based on archetypes and the game had a theme of density vs willingness to make your own decisions, so I got away with a lack of depth or solidity in their characterisation. I’m now realising that I did a lot with DD to make it easy for myself!

I think if I had made this a longer project as mentioned above, I would been able to develop the characters though additional scene writing and them just living in my head over time. I suppose with this sort of timeline my best bet would have been to make some upfront decisions about speech patterns, basic personality, etc. that would then be used throughout.

The largest issue with character was with Niccolo – I would have liked to set him up as shy and awkward, then drip feed his true nature to the player, so they feel like they work out he’s bad just as the game reveals it.

Niccolo goes from sad boi to pure evil in 2 seconds.

Another thing I picked up on during editing was that my labelling for choices was inconsistent. When the mc wasn’t going to say much I usually used the actual line, but when it was longer I condensed it into something like ‘disagree’. In future I think I’d like to choose either a description approach or a shortened version of the character speech approach and stick to that.

One of the choices in the game where what you say is condensed.

It seems that most visual novels speak in second person, addressing the player as you, and are in present tense. I used first person past tense, just because its the way I’m most familiar with writing. This made some things tricky – especially when the player character was surprised or wondering about the future. I think I’d like to try a second person, present tense approach next time!

Art Direction and Use of Assets

I felt that the game lacked a cohesive art direction. It wasn’t bad, or jarring, just unspectacular and lacking in identity. The use of generic, paid-for assets meant that none of the art was created with the themes of the game in mind, nor was it created cohesively. Because I used an asset pack for the backgrounds and a single tool for the characters, there was at least a shared vision between each of these elements.

The character sprites all used the same pose. This is a limitation of the software I used to create them. An improvement would have either been to commission/team up with an artist, use different stock assets that were more disparate or make the art myself.

Its very obvious when characters stand next to one another.

The single commonality seems to be that everything is very blue. This is largely due to the background art and the night-time setting. It makes things too dark, makes locations hard to distinguish from small screenshots and gifs and just gives a depressing air which isn’t what I want to put across. In future games I’d like to have a strong colour scheme that is representative of the themes, tone and genre of the game.

So much navy!

One last thing that I think would have improved things overall is replacing the newspaper clipping end scenes with CGs involving the characters. While I think the newspaper is a neat device, it wasn’t thematically appropriate to the game – where had newspapers appeared before the ending? Nowhere. Where had the idea of reporting and news been in the story? Nowhere. In my detective game that might have worked, but not here.

A neat device, but not appropriate for the game.

CGs also appeal to the type of audience this game was for. A CG of Haydn waiting in the rain or the player leaning in to kiss Niccolo before the big reveal would have driven excitement for the characters and upped the romantic tensions of the game.

The one thing I really liked about the art was the dust particle and the lightning effects. It would be nice to be able to put that amount of polish into all scenes! Generally that’s going to need more time or more people.

Cohesion Between Art and Writing

There are a couple of instances in the game where the art doesn’t match the writing. For example, the hallway made the school feel Japanese and the chairs in the final performance hall didn’t look like you could be restrained to one.

Because the art was fixed, the writing should have taken its ques from the art so that the game felt like a better whole. Alternatively, I could have made my own art or teamed up with an artist, though both of those opinions have considerable impact on scope and production methodology. One of the biggest motivators for me is seeing finished art in the game immediately as it feels like a ‘real project’ and because I have an art background but haven’t flexed those muscles in quite some time there tends to be some confidence barriers that slow me down.

Code and Mechanics

I don’t have an awful lot to say on code – the mechanics of this game were very simple and didn’t do anything beyond the base capabilities of ren’py.

I did at one point attempt to write a particle manager but I scrapped it very quickly – if I want to write things like this they need to be factored into the plan at the start so I have additional time.

One very interesting thing that I did learn from a couple of art bugs however was that I’ve been using hide/show images incorrectly the whole time I’ve been using ren’py – that was a surprise for sure. I had been hiding and showing every image as it appeared, and using file names directly in the show/hide statements without defining them as image variable types. Looking forward to less buggy games now that I know how to use one of the most basic and commonly used functions properly!

From the ren’py documentation.

The Future

There’s a lot of takeaways from this project, but I think the main one is that in order to improve the quality of my games, I need to improve the art. Either I need to dust off that ol’ art degree and draw something myself, or I need to form a team with an artist.

Overall the strongest element of the game appeared to be the writing, which is surprising for me as I have no formal training in that area like I do with art and code.

I’m also interested in creating games with slightly deeper mechanics, so might work on something a little more design/code heavy in the future.

First things first though – some well deserved relaxation, then finishing the January Edwards demo!