Reality Sets In (Loc Part 10)

December arrived, not nearly as cold or as snowy as it should have been.

And while the assets for the new UI system had been completed the functionality portion was not. We all knew that there was no way for us to ship. So we said tentatively, let’s shoot for the end of the semester. At this point Marguerite suggested Kickstarter. I spoke about this earlier here.

So we entered our spring semester full tilt. Our senior production game had survived the round of cuts, leaving our game and four others left. Once again, we had a split focus but we realized that we needed more than just a game to be a company. We created a facebook page, a twitter account, a website, and Marguerite made this gameplay video for Loc.

http://www.youtube.com/watch?v=h3Kd9E9czuk

And then suddenly March arrived and Marguerite and I flew out to San Francisco, stayed with a friend of hers and attended GDC. Wow was that an experience. So many dev’s in one place it was overwhelming, but the underlying message we felt was that now was the time be an Indie.

We returned and Loc development went into overdrive. Every week we had a wholly new build that was just steps beyond the last one. We were probably working more on Loc than our school project. Within a month, just one month, we finished…

The game was release on April 4^th, 2012, 11 months after we started.

During that last week we had a weekend testing day, where we invited any and all to play the full experience. We wanted to identify any lingering problems, which naturally there were, but it went smoothly for the most part.

The kids I had been working with all semester came back on a weekend to see us through. Any Champlain EGD student who put in five or more hours into QA for us was added to our credits list. They were an invaluable asset to the team, which ensured a high standard.

Meanwhile, back at the ranch (Loc Part 9)

While all the level work was being done we were continuing to push forward in all directions. One of the biggest challenges for us to overcome was UI and Menu design. Matt was in charge of creating the functionality for nearly menu in the game, which was a colossal task, especially since we scrapped and recreated our UI mid way through development. The image to the right was how our original section select screen was arrayed.

And to be frank, it was a terrible cluttered mess. Through testing we discovered how bad it really was, so early on we sat down and began a massive redesign. One of the most important things you have to do as a developer is look at how other games do things. We turned to Cut the rope and Angry Birds, two extraordinarily successful iOS games, for inspiration.

From those two games we drafted a new design which underwent one more minor change before the final version. Here is the evolution of the art for the section select screen.

And the Main Menu:

One of the major additions we wanted to include to show that Loc was a polished and industry level game was achievements. We were all fans of getting in-game steam achievements and wanted to create the same kind of experience in our game. Mike headed up this project and six months later Loc shipped with a total of 18 unique and interesting achievements.

The cube itself underwent a total of 6 changes over the course of development. Originally we had these uneven very rough sides. While this proved to be visually interesting, it proved to be a problem while moving tiles. The tiles themselves would clip into and sometimes disappear into the cube. We tried again and again to address the problem, but ultimately we just made a perfectly flat cube and leaned on the normals to make the texture more interesting.

The Magic of Analytics (Loc Part 8)

This stuff is sooooooo cool.

And here was the first ever graph we made! It, in essence, represents the difficulty curve of Loc. Really, it’s just the average time of our testers per level. Getting a real difficulty curve, which measures how hard it is to move all of the tiles on certain faces, potentially certain patterns that could be harder or easier would have been amazing to document as well, but we didn’t have the time.

So we stuck with average tester time to determine difficulty. In addition I was present at every one of these play sessions so often I would sit down and watch them attempt to solve a puzzle to try to pinpoint a particular weakness in certain levels.

But this data was invaluable. Nearly every two weeks I generated a new one, trying to examine the changes made from one two week cycle to another. In this method I slowly ground through the sections of the game, starting at section 1 and moving to section 6.

From the beginning I had a vision of what I wanted the difficulty curve to be. A series of small hills that go up, flatten out, dip a little, than rise back up again. Why this kind of curve? Well, I didn’t want to do an exponential one. That does not fit a puzzle game, I wanted to keep the game challenging, but not so much that the player would tire from the experience. Throwing in those easy puzzles every once in a while was a method of keeping the player engaged.

And it worked… Somehow I was right. Testers and players of the game called it addictive. “Oh, just let me finish this level.” Or, “Just one more. I think I know how to do it.” Were common compliments which justified the horrible amount of time it took to create each level.

So how close is the actual average time graph to my prediction you ask? Well here it is.

All New Challenges (Loc Part 7)

The end of October swung around and with it the deadline for the student IGF. Mike, Matt and I sat down and at the on that Halloween weekend hit the ground running. We worked seven hours straight that Saturday and pulled off a build about 4 hours before the deadline. That was a crazy push, especially since we had been in the lab the night before working on our own game for school, and we went back again on Sunday to work with the rest of our team on that. After submitting, we took a well deserved break, letting Loc sit for a while. We really just needed to refocus on school work.

During that time I went up to Montreal and attended the Montreal International Game Summit (MIGS). It’s a great little conference I had been attending for the past three years and is like a micro version of GDC.

Every year I see one or two really good talks that change/affect my views on game design and last year was no exception. Caryl Shaw, a developer with ngmoko gave a great talk about game Analytics. The concept blew my mind. I had always been interested in graphs and stat tracking, but never had we talked about that it could do for Game Design. She broke down why it was important and how their built in analytics engine fed them data.

I came back and told the others we HAD to do this. Loc was a prime target to be analyzed. Matt jumped on board and together he and I led the charge on the analytics front. I had a nice beginner knowledge of MySQL after trying to rig together a database Server for Champlain College, but Matt was the true heavy hitter having years of experience creating databases. Looking through everything I created a list of all the variables we would want to catch and together we planned it out.

Using this system we got real-time feedback of how long each user took on each level, the number of restarts, how many stars they got, the average time of their play session, and so much more.

Level Design (Loc Part 6)

This video shows my workflow for Loc. Each level was created as a folded out cube within photoshop. For any designers out there, NEVER DO THIS. While the method worked, it was incredibly time consuming and prone to error. To go back and fix a level took required me to basically rebuild the entire thing.

Each level was created solved first, than each face was unsolved moving every tile individually in order to replicate in-game tile movement.

What we should have created was an in-engine level editor that would have allowed me to move the tiles around the actual space. In actuality after each was level was created in photoshop they were then transcribed into numbers. The picture to the right shows the master key of what every tile meant numerically. I would then go into the engine and plug all of these numbers in. Human error would often result a miss-translated number, which could render a level simply unplayable.

And because my view of each level was so radically different than the players, what may be easy from my folded out point of view, could have been exceedingly challenging for the player. The only way I was able to circumvent this issue was to continually play test the game with my every changing pool of QA testers. Over the course of Loc’s development we had over 400 hours of QA testing to ensure that the difficulty progression was perfect.

So why did we do it? Well, we didn't want Matt and Mike to switch gears from the task of actually creating the game to make a toolset for me, especially since we were not working on the game on a consistent basis.The Loc development was very touch and go, everyone working odd hours when we could squeeze it in. We deemed the difficulty of creating levels to be manageable. Sometimes hard decisions need to be made, that inconveniences some, to help others.

Level Tweaks(Loc Part 5)

Other little details of level design became clear. Loc is basically a group of six 4x4 grids. These grids act independently, as the tiles cannot cross over from one face of the cube to any other. Which means that certain positions are more difficult to move tiles in and out off.

For instance if a tile is in a corner, it only has two options in which to move out from, while if the tile is in the center it has four available options, simple right? Well its not one of those fact that instantly jumps to mind. The following heat map shows the importance of every space on each grid.

I took advantage of this information and used it primarily to select the positions where gated tiles (ones that cannot be moved or rotated) should go. As a general practice the majority of gates tiles fall into the corner, for practicality’s sake. The player would no longer have to worry about moving tiles into  that location, which is the hardest to reach.

Another huge change that all levels underwent was a drastic reduction of the number of tiles that  each face can have. I created a rule for myself to never (except in certain circumstances) leave less than three and often four spaces available for the player to move tiles around with. This was done for two reasons.

1.With too many tiles Loc quickly devolved into a frustrating task of moving tiles around. It sometimes took way to many actions to get a tile where it needed to be. We wanted to distance our game from others like Cogs. Loc is more about the 3D nature of the puzzles, not trying to figure out how to move this tile from A to Z.

2.When a player first starts that game they spin the cube around, examining it, trying to figure out the best place to start. When there are too many tiles in a particular puzzle players often get scared the challenge. Loc just becomes too much and they want to quit. The number of tiles is intimidating. To counter act this response, which gets harder and harder to do in later levels which naturally have more tiles, the puzzles begin to rely more on using the edges of the cube to cut corners in level design and make the patterns (more on this later) each as simple as possible.

Another note that I needed to keep in mind is that Loc is hard; it is a difficult game because of its use of 3D space. A puzzle didn’t need to have a super complex path on the later levels; just making simple lines on five sides of a cube was difficult enough for many people.

The First Delay (Loc Part 4)

Time crept by and suddenly August appeared! Where did the time go?? We technically had a game. Solve was still decently broken, tile movement was a little finicky, but we had something. So we sat down together and looked at our options. Unanimously we agreed to continue working on it during the school year to get the game as polished as possible.

We set a tentative deadline for a new build at the end of October as we planned on entering into the IGDF student category and with that a hopeful launch date of sometime in late December.

School started and instantly we took advantage of it. Champlain required all freshmen and sophomore EGD (Electronic Game Design) students to attend the QA lab. Since all other student games were just getting off the ground we had them all to ourselves. Wow, did it make a difference.

The response from the lab changed everything. I threw out all of my 99 level designs I did over the summer and over the next six months remade them all as a result. The game was sliced down to 69 levels total, eight in the first section, and twelve in sections 2-6. With the final level having its own section.

So here is the first thing I learned from that lab that prompted the complete overhaul of every level in Loc: Make the game as simple as possible!!!!!

Which it became clear I didn’t do. Testers enjoyed the game, but it took a long time for them to understand it without instruction from me, which in unacceptable. Every game will not ship with its own dev-in-a-box who is going to walk the player through the game. So the first levels redone were the 1-sided ones which basically all come in the form of a question to the player. Level 1-0 asks, “Can you move a tile?” and 1-1 asks, “Ok, now that you can move a tile, rotate it.”

And so on and so forth, baby steps are needed before the player can get off and running. The major genre bending mechanic doesn’t even come into play until 2-0, eight whole levels after starting the game! So the reason why section 1 only has eight levels, when the others have twelve, is due to fear. We convinced ourselves that if we had twelve people would get the idea of the game at around level eight and then put the game down thinking they had seen everything.