This week we shall start revealing our game to the world.
Starting this week we will begin revealing the details of our first iOS game to the world. Please stay tuned.
4 Things that starting teams forget about the Game Design Document
If you’re trying to create video games and have already went further down the road of how to plan ahead, then you probably heard of the Game Design Document. That wiki or document which contains every aspect of the game from story, graphics, AI, and well everything.
As an indie startup team you probably did your homework and investigated everything there is to know about this document and may have created one, but there are a few things that often happen in new studios that you may forget.
1. Everyone should participate and everyone should approve the GDD only after reading it entirely or at least in any part where that supposed person plans to have an opinion on in the future.
So this guy from the Tech department or a programmer has this great idea that he discusses with the planning committee in the early stages of the creation of the GDD, and then he for whatever reason misses one of the meetings when said idea is turned down. This information is in the GDD, but since our buddy here is pretty confident he know the GDD because he participated in the meetings he doesn’t read it. Then, at some point in development, he randomly starts coding that particular piece, and when someone who read the document finds out all sorts of hell break loose as he exposes his idea again and explains it and defends it while everyone who read the document is either contaminated by his thoughts or blaming him for not reading.
Certainly there are parts that could be skipped by certain members. For example an Art Director is probably not going to understand the more technical aspects of the GDD, but he should have them available anyway.
A GDD is a big document, but the worst thing you can do with such hefty work is invalidate it by not having everyone agree with it in the first place.
2. You have to update the GDD as you work.
Maybe you think that if you set up your GDD perfectly, then it may not change at all during development. But face it, projects change as they are built and so should your GDD. Take the time to review it and update it accordingly. Keeping your GDD up to date is essential for the inclusion of new personnel in the middle of a project. It’s essential to keep everyone on sync. If you don’t keep your GDD up to date your might end in useless discussions about stuff you simply forgot.
3. Your GDD has to be as complete as possible from the very beginning of production.
Maybe you think that you can skip to development and maybe not have the complete level details, or that the Art Bible will take too long to complete and maybe the programmers can get to work already. There are several parts in the GDD that may or may not be essential to begin production, but a healthy, full GDD before production will relieve you of many mistakes. So maybe only when you have some hands doing nothing but waiting for the GDD to be ready you start, but if you can afford it, have a complete GDD.
4. Keep your GDD in a wiki. Not as a document.
You might have taken the hint from the top paragraphs, but here it is again. Do it in a wiki. Wikis were practically meant for GDD’s. A gigantic word document or even a google doc are not the best options for this service. If you don’t believe me try it. It will suck. Whether you set up your wiki internally or on the cloud is up to you and your needs regarding security and accessibility.
If by any chance you don’t have a GDD or don’t even know what it is, do yourself and favor and get this book It contains one of the best explanations on all the areas of the GDD.
Why not? here’s all the RAGE vidocs
Rage is probably one of those games that hopefully will be a breath of fresh air that the majority of players and even developers look forward to seeing in this saturated FPS genre, but I think it is something well known among all.
On the other hand Id Software manages to make us happy by launching the famous vidocs which are becoming a trens mainly to create hype, and secondly IMO, to share a little of their knowledge amnd adventures when they take on the challenging task of developing games.
So here are the vidocs of this game that have been released so far divided by:
3 essential Corona SDK tutorials for begginers
Corona is certainly an exciting platform for game development. Just 5 months ago the number of tutorials available were counted in tens at most. But today there’s an increasing number of them and so, before it becomes overwhelming i’d like to compile a list of the Corona tutorials that have helped me the most to understand the power of the engine.
Before we start i’d like to exclude the included examples. They are awesome if you wish to learn how to use a specific feature. Keep that in mind.
1.– Make a Game in 8 minutes
Even though the title is kind of a lie because only the first part is 8 minutes long and the rest in the series varies, this series is the perfect entry point into Corona Development. Going through these series you’ll quickly master the art of creating objects, dealing with physics and even create a simple game, which may not seem like much to you, but a variant of it(Float) has managed to sell a lot, and i mean a lot.
2.–Rafael Hernandez’s Screencasts
Rafael Hernadez’s screencasts are something you have to do early on to get the best out of them. If you wait too long, you’ll probably be wishing he goes much faster with some of the basics so go ahead and take them right after you go through the above tutorials.
3.–Understanding Lua tables in Corona SDK
If you’re just getting started with Lua and Corona you may not know yet that one of the fundamental aspects of the language are indeed the tables. You are guaranteed to use them at one point or another. So please, understand them before you start on any project because failure to do so might lead you on several paths of unnecessary burden.
The tutorial linked in the title is one of the most comprehensive ones on tables that you will find on the net. So take your time and read it entirely. And you may want to look further on this topic.
This concludes our list of the essential Corona tutorials. IF you really like tutorials you can go down into http://learningcorona.com which is a complete resource of all the tutorials on Corona up to date but a word of advice. Once you go through the basics, start a project, even a simple one and put all you learned into practice and that which you don’t know may be found in the API reference.
Why Mobile? Why Corona?
Might as well mention that we are not affiliated with Corona/Ansca in any way, but we will talk about it a lot here, because it is the engine we chose for our game. The reasons are explained briefly in this post.
Skip this paragraph if you already know why mobile game development is a great choice for starting indie developers looking to turn a profit. I might as well say the obvious. Mobile games are a platform that requires less investment than most others. That is probably the most important reason. And when i say investment i’m referring not only to money, but also to experience, time, and man power. There is also the fact that many indie devs have found gold mines in this arena and in comparison it appears to happen much more often here than in PC games, XBLA or browser games which may be the other areas where indies can enter easily.
Why did we choose Corona might just be a slightly more interesting question since there’s plenty of engines for multiplatform mobile game development and there also the choice to not use one at all. We researched the following engines before settling on Corona. Disclaimer: This is mostly how we felt, and maybe we didn’t dedicate enough time to each platform, so.. there.
Native: Objective-C + Xcode: We certainly tried looking at this platform since it obviously may have the advantages of not dealing with SDK limitations and taking full advantage of every up to date iOS SDK implementations instead of having to wait for the Engine to implement it. But we found it too complex for the project we wanted to do. And felt like the learning curve was too high too. Then again the rise of Android has given great strength to an engine that supports it without having to rewrite your code.
Cocos2d: Cocos2d seemed like a great idea, but the community we researched always seemed to place Corona above it. Our own research was that we couldn’t find much of a community and felt like even though plenty of hooks were placed to make thing easier, you still had to learn all the tools of the trade of iOS development to start messing with Cocos2d. Even books mention that in their introductions.
Game Salad: We quickly discarded this one because of its “No code” philosophy. All of us are from a technical backgrund and we didn’t feel the need to evade code. I could hardly mention anything about this platform.
Unity for iOS: Is your game 2D? Go Corona!. Is your game 3D? Go Unity!. That’s what the blogs and people are saying. We knew our first few games would be 2d so this was a strong reason but not the only one. Licensing costs for Unity are not high. They are… mid range. Our group however is low range. And we didn’t feel like taking a limited iOS License instead of an iOS Pro which is worth $1000.
So therefore. We chose Corona. One of the things i really liked about Corona, personally, was that i managed to do massively more in Corona than in any of the other platforms in the same time. Also the LUA programming language felt much more natural than the Objective C platforms we looked at. Corona also supports Android which is booming right now even though its app sales are still way behind iOS’s.
We are 2 months into development now with Corona and we feel like it was the right choice, even if we sometimes have to put up with certain limitations, which we will adress later, i’m pretty sure we would go the same way again.
So there you go. Hope this helps out people choosing to get into Mobile Game Development. This may be the last post that dwells too much on story
Starting our own game development studio
We were cruising trough the half stages of college when we first thought as a group that we wanted to start our own business. Plenty of teachers had suggested it in different ways so the idea was kind of growing on us, but the idea of joining this group of friends with this objective only become clear then. The difference was from starting 5 separate businesses to starting one stronger team of 5.
Back then we all wanted to be game programmers, but the entry points of the industry seemed too high to get without good experience or plenty of investment. So we went trough several business ideas mainly dealing with web services. This wasn’t too bad, but one of the core teachings of entrepreneurship is to create a business that you would enjoy doing day in and day out.
Plenty of business plan’s later we reached the end of college and since we hadn’t built a sustainable plan yet, we went separate even tough we continued to see each other. After trying several jobs, in different industries we started to feel like we wanted something different. We wanted to be game developers.
And so the idea was passes along to everyone in the group and we decided it was worth the shot.
This blog is going to talk about this. 4 guys sitting in front of each other trying to create video games.
12
