我成功地做到了，尽管花了不止7天，但是相差不多。这款游戏不是我做过的最棒或最精致的游戏，但也不能算最差。游戏名为《Grey Out》，在这款配对游戏中，你可以看到各种形状的灰色调物品。游戏灵感来源于浴室的地板。严格来说，你有多少次在工作时尝试从瓷砖铺成的地板上寻找灵感呢？这种事情我做过很多次，有些与我交谈过的人说他们也会这么做。所以我觉得这里肯定可以挖掘到某些内容，于是《Grey Out》就诞生了。
这个过程很麻烦，因为我在该方面的经验较少。声音对游戏来说非常重要，而且要做好也很难很费钱。正是基于上述考虑，我决定不在游戏中使用背景音乐。音乐要是做好了会很棒，但要是做不好会让人感到厌烦。最好还是别去动这块内容。音效提取自旧音效包Last Level Games，这是以前做另一个游戏时购买的。虽然不是很完美，但够用了。与音乐不同的是，有普通音效比毫无音效要好。
最后的步骤是将游戏提交给苹果。这个过程会有些棘手，情况有可能会更加糟糕，当然也有可能很顺利。提交游戏后，你所要做的是等待苹果的审核。需要注意的是，某些Unity制成的游戏在iPad 2上运行可能会出现错误。尝试使用4.2 SDK来构建xcode 3.2.5。确保配图准确，而且游戏网站上需要有支持页面。正是上述要求导致我们首次提交失败。
Making a Game in 10 Days
A few weeks ago, while talking to a couple of friends online, I decided to issue myself a challenge. I wanted to see if I could use unity to build and submit a game in a week using Unity. I hadn’t had much prior experience with Unity, and largely it would be a learning exercise in exactly what it would take to get everything done.
I managed to pull it off, too. Not exactly in 7 days, but pretty close. Not the finest or most polished game ever created, but certainly not the worst either. I made Grey Out – a pattern matching game where you find shapes using like colour shades of grey. I was inspired by my bathroom floor. Seriously. How many times have you sit down doing your… umm… business… and tried to find shapes on the tiled floor? I do it a lot – others I spoke to did it too – so I thought there must be some meat there, and Grey Out was born.
I’ll start with a small caveat – I had some prep work done before I started. While on a long flight back from Brazil to Australia, I had plenty of time to work on some design. I also had a prototype I’d thrown together in about 6 hours, months earlier. Buggy as hell, I threw most of it away. I also had help from my business partner and girlfriend with content creation. Roping in others really saved my arse. This describes the basic process I went through to go from start to end in a very small time frame.
1. Snap game design
No time for lots of prototyping concepts and seeing what works best. I used my best judgement to quickly decide on what had the highest likelihood of creating a fun experience. My earlier prototype and design was a time attack style game. Decided it would be safer to go with a more traditional level based game with unlocks, which would also give me an opportunity to teach the game transparently.
2. Pick a theme and run with it
I wanted to be careful with my theme – I needed to be able to do the art myself, and I most certainly am not an artist. I very quickly chose a black and white film theme. The assets would be easy for my to create and fit with the black, grey, and white mechanics. I know it wasn’t too closely tied to the action, but damn it, close enough. Once I picked it, I stuck with it. I also decided iPad only. Not enough time to design two interfaces and level sets.
3. Mock up with near-final art
I don’t have one of those fancy expensive artists. I have me and my wussy photo-shop skills. I wanted to get the look and feel of the game nailed down now. No point spending time mocking stuff up and fixing it up later. It also firmly solidified my concept for the game. Using a combination of original art, and using existing art as a reference point, I managed to very quickly put everything together. Slice it up and export it, and that’s most of the art work done.
4. Create the core mechanics
Now I had my art, I needed to put it to use. Using Unity, SpriteManager2 and EZGui, I spent a good few days getting the input working nicely, solution scanning, the matching working and the scoring. Being a puzzle game, this wasn’t too difficult. There aren’t too many systems interacting with each other here. Unity was great because I could quickly and easily throw it in a web browser and get some immediate feedback from my friends.
5. Write the content framework
Once I had my board all set up and running, I needed a way to get levels into it. I could have taken the time to create them all by hand in Unity, but really, too much work – also not flexible enough. It’s much easier if I can configure everything in XML. XML is very easy to create and parse. I created a library to read in and display level content using external files.
6. Hack together some tools
Tools. These were what really got the whole game done and dusted so quickly. Because my levels are defined using XML, I very quickly hacked together a level builder using C# and WPF. The level builder allowed me to very quickly create and tweak content without fighting an editor, or having to manually hand craft the level files.
7. Create the menus and supporting game mechanics.
So now I have a few test levels? Okay, I need a way for the player to move through them. Next I spent time on all the boring, but very necessary, menus, splash screens and title screen. I created scenes in unity for the high level groups of levels (called Reels) and the levels themselves (called Scenes). The first Reel and Scene would always be unlocked, and be unlocked through successful play.
8. Tutorial, Levels and Feedback
I’m now reaching the point where it’s starting to feel like a game. With my level builder and supporting game mechanics, I can start creating content. I spend the first two Reels starting slow and teaching mechanics, then create a third Reel of some simple puzzles. Now I have something people can play! At this point I started getting people to play it, get feedback, then tweak and add important features. I highly recommend using TestFlight for this – it’s a great service for managing your test builds on iOS devices. Also, you can just share the web version! Unity is awesome, and not everyone has an iDevice.
This is a tricky one, because this is something I have the least experience with. Sound is something very important to a game, it’s also hard and expensive to do well. With this in mind, I decided to not bother with music. Music done well is awesome, music done poorly is annoying. Better to just not bother. Sound effects were dug out of an old sound pack Last Level Games had purchased for another title. Nothing perfect, but close enough. Unlike music, average sound is better than no sound.
10. Content Sweatshop
Content creation is exhausting. If I hadn’t enlisted the help of girlfriend and business partner, I couldn’t have created all the 130+ levels to go into the final game. This is where the tools really paid off. It was something that required no detailed knowledge of the game to use, and even my non-techy-girlfriend could use it. This was easily the most stressful and tiring part of process.
11. Test and tweak
Content done! Game done! Before finally submitting I spent some time (not as much as I would have liked) testing and tweaking levels. The core game seemed pretty stable at this point, and we had all play tested our levels, this was just spending a little time making sure it all hung together.
12. Submit to Apple – and wait.
Finally, time to submit to Apple. A mildly painful process, but could be worse. Could be better too. Once you submit you start waiting for apple to get around to looking at it. Couple of things to be careful of – there is a bug where some Unity games can crash on an iPad 2. Try building with xcode 3.2.5 with the 4.2 SDK. Also make sure you’re icons all match up, and you have a support page on your game’s website. We were rejected on our first submit for those reasons.
And that’s it! It was an altogether exhausting process, but I learned an awful lot about what it takes to get something to market from (mostly) scratch. The game isn’t perfect by any means – the difficulty is a bit over the place, there is no iPhone version, the sound isn’t so great and the art looks like a programmer did it, but it’s there, and still fun! We’re selling it for 99c, and if we get enough people actually playing it we’ll look at an iPhone version and regularly creating new content as free updates.
If you want to, you can check it out. I’m curious to know what people think about it. Do you think it was worth the effort? (Source: Gamasutra)