Tuesday, August 1, 2017

Postmortem of Ludum Dare 39: Running Out of Power



Yesterday concluded Ludum Dare 39, a global game jam in which thousand of participants come together to pair up or fly solo to create a game from scratch. There are two different modes you can decide from: the "compo"(48 hours, solo) or the "jam" (72 hours, solo/team). For the 39th Ludum Dare, my good friend Daniel, artist/composer came to stay with me over the weekend (I went to see him on the 38th Ludum Dare). Meanwhile, our lead programmer was staying at his home.

Weeks Before LD39
The weeks leading up to the event were torturous for me because of the excitement and anticipation of the announcement of the themes. For every event a theme is announced and the timer starts, but beforehand community members can submit their own themes which are then judged by others in the community. After three rounds of judging, the final round begins. The final round consisted of 16 themes, one of which would be announced the theme of the LD39. If there was one thing that I learn from LD38, it was that preparation was absolutely imperative to the success of the weekend.

Days Before LD39
The hardest thing about Ludum Dare is finding a good idea for interesting/feasible game mechanics and story. To help this process along I decided that I would look at each of the 16 themes that could end up being the one and create a "mind-map" for each them. Mind-mapping is an effective technique to have in your arsenal when you exploring the idea of something. I decided I would time-box my approach dedicating 5 minutes to each theme and scribbling down any thoughts or images that came to me during those 5 minutes. By the end of the exercise I had two pages of notes to pull from when the time came to design the game we wanted to make.

My second item of preparation was preparing the workspace, which was the dining room table where Dan and I could both comfortably work. I also cleaned up around the house, doing laundry, dishes, dusting,...etc. so that our surroundings were pristine.

Most importantly was gathering food and drinks for the weekend so that we always had snacks and meals on hand. A big thanks to my girlfriend for preparing most of these meals for us over the weekend!

Now that all the preparations were in order it was time to begin the jam.

Day 1
Of course the theme that was chosen was one of the ones I had the least amount of notes and good ideas for. The theme was "Running Out of Power." We went back and forth on a few ideas and then we came around full circle to and idea. This wasn't good. It was the same exact pattern of LD38, where we damn near scraped the entire project of day 2 and started over. Luckily, I remembered something that had resonated with me from a video I found on YouTube, where concept artist Matt Rhodes discusses the importance of knowing the story of a character when drawing it. I thought to myself then it's really the same kind of thing for game design. I think things tend to work better when you first start with the character instead of the setting. So I told Dan, the artist, to shut up and just draw the first thing that came to his mind. The result was this little service robot. Once we all saw the service robot a very fuzzy outline of a story started coming to light. This was enough to get us started and work on art assets, the main game play system, and the menu UI began. It was just after 1AM Saturday morning when we all decided to go to bed and get back to work at 8AM.

Day 2
I spent most of my morning watching Unity menu tutorials because I'll be the first to admit: I don't know WTF I'm doing in Unity. This project was the second time I had really ever even opened Unity much less actually use it. Lunch time came around and Jordan wasn't feeling well and had to go lay down, Dan and I decided to go take a break and get some tacos from the new local place that just opened up near my house in Knoxville, TN. Once we got back I pretty much finished the UI layout, after much cursing and screaming because I'd thought I'd be a baller and animate between the menu screen. The animation of the camera was extremely frustrating but I'm glad I went through that pain because it turned out pretty nice at the end. I found myself in the evening kind of just sitting there without anything to do, which on one hand I guess its a good thing because I wasn't still trying to build the menu like last time. I got a build from Jordan and started play testing it into the night. Then it was off to bed again.

Day 3
I woke up and decided I was going to start writing a story about what had happened to the power plant and why the robot was in there. Dan woke up from a dream that morning and he told me in that dream he had decided the name of the power company in our game was named "Sunflower." Really for no other reason than it sounded pretty good. I opened up a text pad and the story just dumped right onto the page. I highly doubt I would had been able to come up with anything comparable had it not been for the "sunflower" word. Dan was furiously working on the last of the art assets and beginning to write music. Jordan was wiring up all the game mechanics and I was trying to fix all the grammar and misspellings I did in the dialogue of the game. (Yes, there were plenty of mistakes found in our release build.)

Day 4
I pretty much idled all day. Went over the dialogue again. Missed all the mistakes I had made again. I gave my menu scene to Jordan to integrate. "What the fuck, man?" was the response I heard when he opened it up. See he had forced the game to play in 832 x 832 resolution whereas I had mine set to full-screen. So to fix that I had to change the canvas sizes and shuffle my UI elements around about 15 minutes later Jordan had integrated my menu to the rest of the game. There was one other slight issue. I had written my UI scripts in JavaScript, mainly because I wanted to sharpen my JavaScript skills to help me out at work. Jordan however has been writing all his scripts in C#, which is the more common approach in Unity.  In hindsight, using JavaScript to interact with GameObjects is kind of stupid and it just feels wrong. Maybe that's the object oriented programmer in me speaking but damn it just feels wrong. So Jordan was able to convert my JavaScript to C# in about 15 minutes, which I think speaks to both of our skills, Jordan being a excellent programmer in C# and me having writing understandable JavaScript. The rest of the afternoon was spent idle watching all the art and music assets getting loaded in until we got a build of the game and began play-testing. I think we ended up with 3 or 4 build before we got the release candidate, which we then submitted as our entry.

Overall, this was a very enjoyable weekend and I had a lot of fun. I also learned a lot of lessons and was able to used what I experience from the last LD to our advantage for LD39. If you feel so inclined you can check out our game at these links below:

Game now on itch.io





Friday, March 17, 2017

Finding Your Headspace

tldr; Increase your productivity by deliberately setting time aside for design, development, refactoring, and personal development. Protect your personal time and stay away from your inbox as much as possible.

For the last few years, I've essentially been a software developer working doing Tier 1 support.  All I could do was react to the business unit reporting the largest issues. One of my true passions has been Agile software development and last year I became a Certified ScrumMaster.   In my downtime, I developed our SDLC processes for the IT department. Suddenly our department was restructured and I was moved to our Software Development team. Now that I'm removed from the daily freak-outs of the business, I find myself actually analyzing and designing systems before jumping into a solution. Additionally, I also find myself refactoring code for the first time in three years.

At first I though this was because I'm physically separated from the business. Interestingly, I've found out that what is actually happening is that the SDLC process actually increased our the delivery of new features and bug fixes at such a rate that the business is running out of things to request. To put this in perspective, in 2016 we had only about 10 releases whereas year-to-date we have had 8 releases. Also, the business units are taking much more time to define their problem space or they modify their business processes to harness the seeded functionality of the software platform. But this has caused a major shift in my day-to-day thinking and overall picture of what is happening around me.

Honestly, I'm relearning how to be a developer. Beforehand, I was essentially acting as Tier 1 support and putting band-aids on the system to just get the ticket board to be quite. Now, I have to learn to adapt because I keep running into walls and painting myself into corners and I realized it was because I was still working in that support mode. I wasn't analyzing the problem and designing the solution. I just furiously Google searched whatever line of code I was working on until it worked (which never did). I was just wasting my time and never getting anywhere and getting intensively frustrated. I decided I was going to find some help and I stumbled upon a blog post that caught my eye:
Design Your Ideal Week-Increase Productivity

I decided to design my week with some themes that I feel are important for a software developer and strategically divided up my calendar to stay focused on my tasks.

  1. Design - Designing the software solution before you begin writing code.
  2. Create - Writing your code and documentation
  3. Refactor - Reinventing and cleaning your code. Paying off technical debt.
  4. Personal Development - Reading blogs, listening to Podcasts, conferences, and reflect.
  5. Not Negotiable - Lunch, workout, remove yourself from your desk and unplug.
  6. Email - Reserved from responding, clearing, or sending email.