Things have been busy and hectic at Score recently, as our lack of blog posts may attest to. In the last few months the guys have been creating a rather spiffy engine, the awesomeness and ease-of-useness of which I can only talk about in hyperbole. As part of the process Paul wanted to dig up our old tool, the technology that helped create Flock It! and Piczle Lines, old technology that has lain dormant for at least a year, to show how we handled scripting-based game design previously. This lead in turn to us all being pleasantly surprised how well it had held up; it goes to show if you think about good tool architecture it will stand the test of time.
As part of his research into scripting Karl threw together a prototype of a little puzzle game he had thought up. At first we were all happy that Paul's approach to scripting in the old tool was easy enough for others to pick up, but then we were kind of hooked. With just 3 orso levels, using old graphics (Flock It! button graphics, which have been prototype favourites for some reason) he had us pretty hooked. As we stood around his desk trying to solve these puzzles we decided to migrate to the white-board and within 20 minutes we had a style, design and project.
The following will probably not make much sense unless you've played the game (available from the AppStore here).
One of the whiteboard lists listed possible styles. I am personally a big fan of the minimalist, clean design of games like Spelltower. Initially I thought of simple Scrabble-like tiles with numbers, but this would be hard to communicate. Another option, one Karl suggested himself, was animals, or rather, evolution; combine lesser creatures to evolve them into bigger ones, to keep on evolving over the levels. As the only artist available for this project, and with other important tasks occupying my mind, I baulked at the idea, merely based on the ludicrous amounts of art required. I did, however, like the element of evolution, so proposed a more manageable cell combination affair, and we came up with the name "Osmosis" to go with it.
An initial, scrapped mockup of the graphical style.
Even then it took a little while to hammer down a proper style. Initially I aimed for something quite organic, but it soon became obvious that that too would be too much work. After a few false starts I ended up going for the old reliable "cutesy" style that I personally quite like.
A second attempt, which still proved too complex for quick development.
During the initial (and only) whiteboard session we also discussed mechanics. Walls were a given (area 2) but the others took a little discussing. Soon, though, we settled on a basic set of 4, or rather 3 and the pure "no specials" initial game mechanic. The other gameplay mechanics we have currently left on the table I'm more hesitant to talk about. If the game sells enough and it's worth our while we plan to add a few more areas that will incorporate some of these ideas.
Within our basic set of rules we still had a few things to sort out though. One major point of contention was the "half-way cell", the cell that is created when two single cells are combined, but before a third one is added to make the cell evolve to a bigger one. At first these too could be moved. At one point also we played with the idea of two half-way cells colliding into a single bigger cell, thus "losing" a single cell in the process. Different people had different ideas, and the occasional argument did arise. In the end, though, we created this game like we did all our other titles: one person would be in charge and in this case Karl was gracious enough to let Paul handle the final decisions. After a few playable prototypes and a few tests he decided that combined cells could not be moved until they were merged with a third and thus evolved. This also neatly answered the whole questions about two halfway cells colliding, which is now impossible.
A snap of our old tool, still robust enough.
Another big question was the idea of a "goal tile"; not only did you have to combine all the cells on the board to a single one, it had to end up on a predetermined tile on the board. The main concern was that the game would be far too easy. Indeed some initially thrown together test puzzles were very easy and this was a huge concern. Some thought having a goal tile would make the game too difficult, others thought it'd be too easy (being able to work backward from the solution). In the end our concerns were pretty funny as we ended up making one of the hardest puzzle games available on the AppStore (we've been told).
Karl and Paul set about creating puzzles and some of us playtested them, giving feedback on difficulty. Some were impossible - literally, they could not be solved and had to be discarded, obviously. Others fell in that weird area of being too easy if you knew how to solve them but then being too hard when first presented with them. When a basic set of puzzles was decided they were put into an order we felt was acceptable. We may have mucked it up a little, as most people will talk, with raised fist, about that blasted puzzle 1-5 (if you've played it you'll know what I mean). Because of the difficulty in judging how hard puzzles were going to be we decided to have people be able to play any puzzle they wanted in an area in any order, after the initial tutorial stages, but needing a 75% clearance rate to be able to move on to the next area.
During playtesting I took the initiative of recording all the solutions because, as a player rather than a creator of the puzzles, they stumped the Hell out of me. I knew from our Piczle Lines experienced people would want to be given the solutions to some of the puzzles. I prepared a forum thread, which you can find here, where anybody can request solutions, posting all of the solutions to area 1 as a kick off.
In the end I think Osmosis was another great proof of concept for the Score Studios toolset - in this case our old toolset, but a philosophy that is continued in our latest tech. Simple scripting leading to quick prototyping and iteration, an art tool that can be used independently from the programmers, quick turnaround and, as a development philosophy, minimal meetings, quick decisions and individual initiatives with a single "buck stops here" director. It's a nice little game, easy mechanics and brain-meltingly hard puzzles. From an idea in Karl's brain to the Appstore in record time.