Art & Sound Retrospective - By A Programmer Who Does Neither
Happy review-period everyone! I just completed my first jam as a duo with my old friend Rob, and for the first time ever I took a backseat from programming and tried my hand at being the asset-man. I even bought a big fancy tablet thing and a microphone in preparation. I thought I'd write about it here, or forever lose the lessons learned.
Our aim with this jam was simplicity and polish. We were hoping for the two-button game, and so we ended up making one anyway despite making our life, well.. you know - currency.
Before I dive in, if any budding UX designers, illustrators or sound engineers would like to trade feedback, leave a comment and check ours out here - thanks!
Breakdown
Art
Tools Used
- Photoshop CS5
- The first free concept art brush pack I could find on Google
- Discord for Source Control (yikes!)
Planning
We started with whiteboarding as per usual, and then made a greyscale UI wireframe to help us lay things out in the Unity editor. This got the mechanics mostly nailed. I can't emphasise enough just how important doing these little bits of extra work are early, as opposed to just eyeing it later - I think it saved us a lot of hassle.
Then, I sat and wrote a manifest. A manifest is an easy way of rattling off all of the individual assets you think you'll need - mine looked something like this:
- Icons
- Attack
- Defend
- Timer
- Containers
- Action
- Speech Bubble
- Buttons
- Left
- Right
- Go
This evolved over time, and essentially became my mini issue-tracking TODO list that I ultimately used to help us cut features.
Lesson Learned: The programmer will recognise plenty more assets needed than you anticipated, such as 'generic' assets to be able to adapt in an Agile way to the necessity for small tips, different kinds of button states (up, down, active, hover, disabled). Account for this time to adapt.
UI
I prioritised the UI since the game didn't strictly need the character art to function. Although you use a keyboard, the UI is the most important part mechanically as the game was to feature a shop. We also wanted it to work cross-platform, so making things big and bold helped.
Lesson Learned: Keep a consistent stroke-width between assets on the same layer! I had to re-do the health bar at one point because, although it looked pretty, it's fidelity brought some inconsistency that I believe is called 'noise' into the scene that meant the player's first look at main game loop would be overwhelming. Account for this time to be fussy or you won't be happy.
Old health bar:
New health bar:
At one point I accidentally added a drop-shadow to my UI folder, giving shadow to every UI element. The result made me groan, because it was much better, and cost me an hour re-exporting them all, and Rob an hour re-positioning them since their sizes all changed slightly.
When sending my stuff across, I also sent a screenshot of my Photoshop layers. I knew we were short on time, but keeping things organised really pays dividends, and this structure helped Rob order his scene graph in the Unity editor.
Character Art
This ate the majority of my time. I'm not an animator. I remember playing around with Flash in the Newgrounds days, but I have no idea if Photoshop support 'onion-skinning'. Either way, I settled for drawing an idle state (2 frames), an attack and a hurt outline for each character, and then colouring them in a background layer. I had to flit between the idle images in my file explorer and just hope. I have a lot of respect for actual animators.
Lesson Learned: There's a reason some disciplines have whole University courses dedicated to them, and I do not want in.
Thematically, the idea of our game is that you're a big tentacle monster and people are stumbling across you over the course of history. That being the case, we decided that the characters should reflect that - basically only weird, exotic, or world travelling things should find us and try to kill us. This meant we ended up including things like Roman Legionaries, a time traveller, and more abstract concepts like climate change. We knew we'd have to cut some ideas - each new character required new sounds and art, but since the game was content driven those decisions were able to be made lucidly, at the very end.
Lesson Learned: Taking your work less seriously and designing things to be data-driven can give you a lot of creative wiggle-room.!
To my chagrin, I proved all of my primary school teachers correct during this project - with practice, my style got more confident and consistent. The first enemy I drew was the mushroom, who had lighting. Then I drew a Royal Beefeater without any outline. Then, I drew a T-Rex, who, with a lack of consistent reference images on Google images, ended up looking like an escaped zoo animal from Chernobyl.
With those done, I realised I preferred characters with outlines, and bold, bright colours to contrast the moody background. I made their attack images way more vibrant, and I was for the most part pretty happy.
Fonts
I used DaFont and found a license-free sketchy font that fit in so we could say farewell to Arial.
Fluff
Saving a million Photoshop files meant that I could re-appropriate assets. We found that the control scheme for the game was a little esoteric, so I was able to make some tutorial graphics pretty easily.
Additionally, we made an app-icon for the good look-and-feel, using the main squid monster's face as a motif.
Sound
Tools Used
- Cubase
- Audacity
- Open Source SFX Sites (listed)
SFX
I used OpenGameArt and FreeSound for all of the UI sounds.
At one point, people came around to watch Game of Thrones, so I rushed upstairs with my microphone and garbled a bunch of character intro noises into Audacity. Hopefully you hear them and think they're charming... ;-)
Music
The game is sort of a rhythm game - enemies attack on beat, once every second. Doubling that with some hard mental-maths to get 120bpm, I composed a short instrumental that sounded emptier on the attacking beat, resulting in some fitting ambience that aligned itself with your play, but wasn't too distracting.
Since during the game you move through the eras, I thought it would be fitting if the music changed - but alas, it's only a game jam, and there's only so much time. Cleverly, if I do say so myself, I cheated and went back into Cubase, changing the three instruments used to period-appropriate ones, and turning our one monotonous track into a whole soundtrack!
Lesson Learned: Working smarter and not harder is a epithet that only makes sense during lightbulb moments at 2am
Conclusions
Being creative for long periods of time is hard. We all do it in any role, and so this has added to my ever-expanding list of things that are hard. You end up cutting corners, your arm aches...
But it's worth it.
The comments coming in are so positive, and it makes me so happy to know that I've made something better than it would have been. It wasn't essential, but it took a game jam game and made it something I would be proud to put on Steam (albeit for free). That said, I don't think I'm looking to change career any time soon.
My biggest takeaway was that Rob ended up deferring most, if not all of the design decisions to me. By his account, he preferred it that way, because it meant he could concentrate on building the damn thing, and we went toe-to-toe on mechanical decisions. I almost felt like I was requesting features through the design lens - asking to make things clearer, brighter, more spaced out - small tweaks to add up to something that, if I did it right, you don't notice at all.
That's not to say it's perfect - who doesn't end up with a laundry list of stretch goals by the end of a jam? We can pre-empt some flaws, but the rest...
...is up to you! If you enjoyed this break-down, or learned something, consider playing our game! Thankyou!
