Yaay, my first Ludum Dare is over, and me and my team managed to push together a playable game. Yaaay for us!

Play Toilet Paper Saga!

Anyway, on to the post mortem:

The Initial Concept

I pretty much knew what kind of a game I would make despite not knowing the theme. I wanted to make a comicbook-like game with a branching storyline. The story would be the main focus, the graphics not so much. Think of MS-Paint comics. I also knew that I could get at least one artist and a story developer to join my team. I also knew that I could have a place to work in. I’d tested out Belle, a WYSIWYG visual novel engine the weekend before the jam, and it worked quite okay, despite the fact that ctrl+z didn’t exist. I also chose to use it because it was free, no coding and I could make the game for browser.

The Changed Concept

After I got together my team, we decided to brainstorm the game and plot together. It changed a lot from what I had in mind, but it didn’t really matter, because I wanted to take a more technical role in the process anyway. We ditched the comicbook style, and designed the gameplay around a map drawn on toilet paper, which the main character was drawing on. We wanted to make some speech bubble -like dialogue boxes to pop up when the player clicks a patient on the map, and animating the stick figure characters would be nice too.

We had many ideas about the “unconventional weapon”, and we thought it could be the patients that the player would use to escape the asylum, or the toilet paper where he scribbles all the locations. At some point we decided that we wouldn’t care if the theme was too vaguely presented in our game –  the process itself was more important.

The Bad

• Living in Europe – It wasn’t really helping, that the jam would begin (and end) in the middle of the night. I lost some hours from the beginning, and lost a lot of sleep from the end. But, it’s not something I could easily change. 😀
• Not REALLY Knowing the Tools – This was probably the worst problem I had. Belle showed its ugly beta face on the first day of the jam by crashing multiple times and not saving the project correctly. I had to spend the first day trying to make Belle work, and finally started to look for other options. On the second day I decided to buy Tyrano Builder as a last resort, even though I didn’t have any experience using it. Luckily it was easy to learn, and the workflow didn’t differ much from Belle or Ren’Py. Nevertheless, I lost a day because of my mistake, even though the other team was doing awesome.
• Not Focusing on the Core Mechanic First – I hesitated to work on the elsif-branching because I wasn’t sure I could handle the scripting language properly. Instead, I worked on getting the story into the project. Eventually, I had to work on the code, and it even wasn’t that difficult. I would’ve saved some hours of sleep if I had started coding earlier.
• Not Realizing the Limits of the Engine (and yourself) – This was probably due to the change in gameplay-mechanics from the start.We ran into a few visual problems early on in the game. First of all, I found that I couldn’t make the speech-bubble like text boxes as easily in Tyrano Builder as I could have in Belle, so we decided to go with text links and dialogue on the side. Tyrano Builder has a way to make parts of the image clickable, but I couldn’t figure out how to make it work, so things had to be changed. The other problem was with changing the images; we could only add images, not remove them, so we had to make patches to the parts of the image we wanted to change.
• The Lack of External (or Internal) Playtesting – We didn’t really have time to playtest the game, and I’m sure there are some bugs (there are some reports in the comments already).

The Good

• Knowing Your Team – Despite my problems as the coder, the team was awesome. Communication worked like a blast, and all the graphics, music, sound effects and game script were delivered in time. Everybody gave their ideas during the first brainstorming, and thanks to that we had an awesome story to tell. It helps to have a team whom you know, strengths and weaknesses and all.
• Preparing for the Worst – From the beginning, we designed the game with minimal assets in mind. The graphics had to be simple, in order to get everything done. The story was branched so that you could omit some parts, and every level was designed so that it could be the last (which was good, since we did finish only the first level).
• Food Supply – I baked a lot of pizza before the jam to last the whole weekend. That way I saved some money, even though I did go to McDonald’s a few times. Also the school where the jam was held had free tea and coffee, which was nice.
• The Workplace/Resources – Me and my team got space, laptops and Photoshop from Laajasalo Institute’s Game Design class for the whole jam, even though we graduated already. It was nice to meet the freshmen there. It was also good to go there and return home to keep the work and the free time separate.
• Separating the Tasks – Having everyone focus on only the stuff they were supposed to do, I think we saved a lot of time and got better quality. If I had had to draw the art as well, it would’ve taken much more time from the coding.

Surprises?

• The Team – I was surprised to find out that I could get as big a team as I did, and I’m grateful for that.  And it was awesome!
• The Technical Problems (With Engine) – I did anticipate some problems with the game engine, but I didn’t expect to have to change the whole engine to another one! It was a bummer.

Final Observations?

Well, the art style changed into a toilet paper map, and the game didn’t have any comicbook elements at all. But, since the team was so hyped up, and the mechanics didn’t seem that different from the original idea, I decided to go with it. I’m glad I did, because it fit the story better than a comic would have.

The story was separated into three levels, with some branching puzzles.

The main change technically was switching from Belle to Tyrano Builder in the middle of the jam. Towards the end even the WYSIWYG aspect lost its importance, as I saw that coding was somehow easier than dragging all the elements to their place visually. Sadly, I couldn’t port the game for browser for unknown technical problems with the engine, so I had to settle with the Windows version.

The only things that stayed pretty much the same were the branching storyline, and the visual novel kind-of engine.

What Next?

Since we already have the story for a second level of the game, I think it would be nice to continue from where we left off with this game. I also think I’d like to find another engine and a coder to make the game work better. Animations would be nice, as well as some extra sound effects. The game also needs to be playable in browser. I’ve already talked with some of my teammates, and they seemed keen on the work too.

If you haven’t, go play the game: Toilet Paper Saga