All right! Here we are at the end of week 1 of One Game a Week 2019!
After many months of anticipation, I was thrilled to once again be working on One Game a Week. I have to say -- after the first week, it has more than lived up to the hype. I'm really proud of the game I made this week -- maybe it's because I'm working with such incredible art, or maybe this game idea just really resonates with me as a player -- but I already kind of feel like this is better than any of the games I made back in 2014. That's a great way to feel just one week into the project!
I'm very, very excited to share my game with you -- I hope you enjoy it! Before I get to the game link, I did have one thing I wanted to mention first. I plan on releasing all of these articles and games for free -- I want everyone to be able to read this content and play the games. Having said that, if you would like to support the One Game a Week project, I'd really appreciate it. When you go to play the game (link below), you can play the game for free, but there's a button below the game that says "Support This Game" which gives you the option to make a small donation. If you've got a few dollars to contribute toward the creation of these games and articles, I'd be very grateful for that. Thank you very much to anyone who is able to support the project!
Without further ado, I present to you a link to my first game of One Game a Week 2019: Curious Castle!
I've made it available to play right in the browser via WebGL -- you should be able to just click the button that says "Run Game", and once that's loaded you can play right away. If there is any interest in a downloadable version of the game, I'd be happy to also publish standalone builds for Windows, Mac, or Linux -- just let me know if you'd like one.
I'll also issue a SPOILER ALERT!! for the rest of this article!
From this point forward I'm going to be talking openly about the game and some of the twists and clues -- so if you want to play the game before reading any of that material, go play it now before you read on! Game Link right here!
Curious Castle Self-Review
To quickly set the context for anyone who has not played the game -- you are essentially trying to deduce some information about four of the guests staying at the Curious Castle. Each character is staying in one of four rooms, and has requested that their room be prepared with their favorite drink (one of four options) and a box set of their favorite television show (one of four options). None of the options overlap. To win the game, you have to sort through the clues and figure out which person in staying in which room and also deduce their specific drink and their specific TV show.
After working on this game for a week, I feel like it was a resounding success. Some of the things I thought would be hard to implement ended up being easier than anticipated, such as getting my character animated-- I wrote a bit about how I did that for anyone interested. Another one of my goals for this project was to figure out a good dialog system, which I achieved -- I hope to be able to use this in some of my future games and not have to spend time re-creating it from scratch every time I want to have dialog in my game.
It did take a lot longer to create and implement all of the content -- setting up all the individual books and boxes and crates with little text blurbs was more time-consuming than I thought. As a programmer, I think I fall into the trap of thinking "well, once I've implemented the code to be able to do something, it's trivial to go and actually do it!" Setting up and testing the puzzle was the most time consuming part of the development process.
Debugging this castle-wide puzzle was also a lot of work, and I thought it could be interesting to expand a bit on the kinds of things I found wrong with my game and some of the things I did to fix these problems.
Bug-Fixing Deep Dive
One of the things that can be pretty opaque about game development is the process of taking a game in its "almost finished" state and transforming it into its "finished enough to share" state -- what kind of bugs occur? What kind of solutions do you need come up with? I thought it would be interesting to shine some light on this process for Curious Castle.
After about six days of development, I had the core gameplay nailed down for this game -- all of the clues were in the game, there was a title screen, and you could technically play the game from start to finish. However, I had not yet really sat down and properly played through the game. I was a little bit afraid of how many problems I'd find -- and I was right to be afraid, because there were a lot of things that needed to be fixed.
One of the most important things you can do to improve the quality of your game is playtesting -- having another person sit down and play through the game. One thing I've learned in my career is that even if you are very confident you've thought of everything, playtesting will always reveal important problems in your design -- from functional issues (like colliders in the wrong place or typos in the text) to more subtle issues pertaining to assumptions that were obvious to you, but are not obvious to a player seeing the game for the first time. I think it would be instructive to go through the list of bugs that I compiled on the sixth night when I had my partner playtest the game.
We sat down for a playtesting session and ended up spending probably 3-4 hours going through the game. A lot of this was spend on trying to solve the puzzle, but a lot of this was also just going through each room and trying to find any possible problems. At the end of our playthrough, I literally had two pages of notes on bugs I needed to fix or design flaws I needed to mitigate.
Here's a picture previewing one of the pages of bugs we found during our first four-hour playtesting session:
So to say the least, there were a lot of bugs -- this made for a pretty busy Saturday night and Sunday afternoon. To give the breakdown in text so you don't have to read my terrible handwriting:
There were typos in the text ("appreicate" instead of "appreciate").
There were colliders in places where there were not supposed to be colliders, and vice versa, from when I was putting together the castle layout. For instance, you could walk straight through the king's throne.
You could not click on the candles, despite being able to click on basically every other object in the game.
I didn't have anything in-game explaining the controls.
Some of the geometry layout was obscured in some of the rooms.
There was no good indication that some of the things people said to you might not be true -- a player who is new to the game might interpret every clue and every thing each character said to be absolutely true, but I did not always intend this to be the case.
Some of the fixes for these are straightforward and obvious -- I went through very carefully and corrected all of the typo-level errors. I forgot to have any in-game indication of what the controls were. For that -- I was a bit short on time, so here's what I went with:
And just like that, now I had some giant billboards showing the controls and some in-game credits. I also went through and fixed some mis-aligned colliders. These were bugs that made sense and on some level were something I expected. Some other things that came up were kind of unexpected, though.
First of all -- I realized that nowhere in the game did I really formally explain which guests were the ones we were interested in for the puzzle's solution. I'd done so many iterations of the puzzle that I forgot someone could not know this information. I tried to design the clues so that the characters you needed to investigate were a bit ambiguous at first -- for example, there's a clue that mentions the Rock Golem, but he's not actually involved in the puzzle's solution. But I realized during playtesting that even though this was clear to me, the player had no way to be sure which characters were important until they walked up to the king to submit their answer.
To fix this problem, I put a conversation in the game with one of the characters who explains that four guests are extra important. That way, even though the player has to dig around a bit to find that list, there is a definitive answer present in the game. As long as the player has a solid way to find out that information, I thought that was good enough.
Another design flaw that was exposed during playtesting was the arrangement of the guest's rooms. Here was the original setup:
In my mind, I thought it was really clear that even though the rooms were sort of arranged around the perimeter of the sleeping room, it was clear what "to the left of" and "to the right of" meant. In my mind, it was obvious that room 43 is to the right of room 39 -- after all, if you were going around the room clockwise, you'd visit the rooms in numerical order, so I didn't really think about it too much. However, in retrospect, the fact that I thought room 39 was "between" room 23 and room 43 is not necessarily clear -- but understanding that is important for one of the clues. Not great design!
To fix this problem, I actually totally changed the layout of this room -- I made it one longer corridor, with each of the doors directly side by side. That way, the layout is much less ambiguous and hopefully will result in fewer frustrated players.
One of my design plans that just didn't work was the bookshelves. It has always annoyed me in video games that bookshelves always seem to only have one book on each shelf -- visually, you can see that there are 30-40 books on the shelf, but then you click on the bookshelf and it says "would you like to read this book?" as if there's only one single book. How annoying is that? So I thought that I would have Curious Castle be the change I wanted to see in the world -- I would have each individual bookshelf have a bunch of different sections and each section would have a couple of choices of books to make it seem more like a real bookshelf. It's still not 30-40 books, but at least it gives the player the impression that they're leafing through a bookshelf with several options.
For anyone unfamiliar with Unity, the thin-lined green boxes below are colliders. In the original version of the game, each collider was a section of the bookshelf with different books you could read:
However -- this idea did not translate well to gameplay. The colliders are not visible to the player, and I did not have any other kind of feedback for the player to know that there were multiple "sections" of books in each bookshelf. So when my partner was playing, she just read one of the sections and assumed there was nothing else and moved on. That was not the effect I was going for!
So I guess I learned the hard way why games often set things up the way they do with bookshelves -- you need to have some visual indicator of where a player can and can not check, or else they have no way to know. I thought that maybe I could cause the section the player was reading to change color or flash or something, but I decided that was going to take too much time -- instead, I resized the colliders so that each individual bookshelf would contain only one selection of books:
However, I'd already written out all of this text and hidden clues in some of the books -- so I couldn't just reduce the content by a factor of three. So I decided I needed more bookshelves!
I didn't really have the real estate in my current castle design to place more bookshelves, so I decided the quickest way to find a place for these new bookshelves would be to attach another room.
I'll note that this is a bug-fixing strategy that will not work in a lot of games, especially larger projects -- you can't always just add another room if you've carefully planned a building's layout and you are six months in to a project. However -- for One Game a Week, you can get away with this kind of free-thinking solution. Need more space? Throw in another room!
You also might not have any additional art assets to create a new space -- maybe you could re-use old assets, but if you wanted to create a library that might be a lot of work. Thankfully, Meshtint Studio already had a library setup in the Medieval Interiors Pack I bought at the start of the project that would work perfectly for me -- so after a few minutes, the Curious Castle library was officially open for business!
Okay! So now I had room to house all of the books needed for my puzzle to work.
There was one other substantial bug that I've not yet mentioned. I am very embarrassed to admit that I committed the worst mistake a puzzle creator can make. It's not a proud moment for me, but I think it will help me grow as a person to admit this.
I....
I accidentally made the puzzle unsolvable and then let someone playtest it.
Yep.
One of the clues was supposed to refer to coffee, but instead it referred to beer, which made it impossible to logically deduce the correct answer.
The crazy thing is that I went through the game and solved it only using the clues in the game before I let my partner play it. Unfortunately for her, I must have made an incorrect deduction or crossed off something when I wasn't supposed to. She spent a long, long time working through the clues, and totally restarted the game multiple times to make sure she hadn't missed anything. She asked me if I was totally sure that I had made a solvable puzzle and I insisted that I had.
....Yikes.
Thankfully, once I realized my error, she was a very good sport about it. But these things happen sometimes. Hopefully I don't make that mistake again!
So that's it for OGAW 2019 Week 1! Thank you very much for following along, and if you played Curious Castle, I hope you enjoyed it!
Here is the link one more time if you'd like to try the game: Curious Castle!
I had such a blissful, stimulating week working on the game and I'm honestly a little sad to move on to a new project already. I feel ready to craft some more mysteries. But week 2 is calling, and a new game awaits!
I'll be back tomorrow with the theme announcement for week 2!
--Kyle