Developing games
Entry posted by f13rce ·
2,863 views
Haven't written a blog before, but things have always come into my mind about certain subjects.. Figured I should finally start writing a blog.
This blog is mainly about my personal experience and advice on making games in general. Even though I've made some games like Ravage Online (RO) and the potential Grievous Grounds (GG); the games aren't really done and I'll be elaborating how this has happened.
Scope
The scope of both of these games are pretty big. For Grievous Grounds it was a little big too big. But why?
I basically wanted to do something challenging, something I could work on for months and have a super shiny professional result, bursting out of my portfolio website.
The problem here is: I don't have the time.
I got accepted on the NHTV (best school in the Netherlands) and have to prove myself worthy by getting all the ECTs. We have to do a lot of cool stuff like making games, studying history and managing projects (and teams). The scope of RO and GG are way too big where I can show little progression after every session of programming.
I DO like Leadwerks and I definitely want to become a video game programmer in the future, but school has the priority right now.
The solution:
If you want to make games, keep the scope very small. Something that can already have a prototype in a week. You won't be able to make an advanced game like Minecraft in a week. In fact, even Notch started his project small. All you could do is place and remove blocks in the world of 3D Pixels. After that you have all the time to add in extra functionality and increase the scope little by little.
Just look at Minecraft now: Crafting, story mode, mobs wandering around... If you wanted to do all of this from the start, Notch probably wouldn't have finished the alpha in the first place: It's too much work.
Example of a small scope
For GameLab at school (project based learning) we have to make a game where we got two random themes: Chain and Flat. We came up with the idea of a very simple game where you have to blow stuff up (by using chain reactions).
After day one we already got a working prototype with the core mechanics: Place bombs, blow stuff up.
This gives a relieve because you know you can achieve it because you just proved it. The scope it small, it's easy to prototype (to see whether it's fun or not) and you can easily add features to it (like in our case a replay system).
Define a finish line
If you don't define what the finish line is, you'll be running a marathon with no end. You'll get exhausted and bored of your project and disregard it. Make sure you know what has to be in the game in order to be complete. This is primarily the reason why RO and GG haven't been finished.
Working on a project
Progress takes time and has to be rewarded. You nowadays constantly see games rewarding the player for every move he makes. Example:
It might sound really weird, but rewarding yourself for every progress motivates you. Progress in general motivates you - all you have to do is make it visible to yourself that you made progress: Now how do you do this?
(Tip: Reward the player in games! Give them a reason to progress and keep progressing. If you don't the player might feel lost because of the lack of (positive) feedback.
Examples of rewarding: +5XP's all over the screen, unlocks, achievements, progression bars, etc.)
SCRUM
This technique is used to show what to do, what's in progress, what needs to be tested and what's already done. We use this technique during the development of our explosion game (in GameLab). SCRUM allows yourself to show a lot of progress and displays what others are doing as well.
We use Trello for our SCRUM. As you can see on the screenshot everything is clear, organized and displays progress at any time:
There are other ways to display progress, like a Google Docs document where you mark everything green of what's done - that works as well. As long as you can display progress to yourself (and your team).
Finishing a game
This is the hardest part. Finishing a game takes so much time because you have to do all kinds of stuff like polishing, reviewing and bug fixing. The only way to prevent a lot of polishing and reviewing, I'd suggest to playtest your game as soon and as many times as possible. This shows your game's strengths, weaknesses and bugs you wouldn't find out on your own.
Don't be afraid to show it to your friends! They might be harsh on some parts, but if you take the most important feedback out of it you'll improve your game's experience by at least 50%.
Polishing also takes a LOT of time, this might eventually take about 15% of the actual development time. You want to deliver an enjoyable experience towards the player, not a buggy one where it can break once every 3 times. This can make the player frustrated and put down the game. Polishing is really important and do take your time for it.
At last, I'd recommend working on the game at least once every week. This prevents confusion of what you've written before and how your game's pipeline works.
Example: "How do I modify the AI's thinking again?"
------------------------
Recap:
Keep your scope small.
Define a finish line.
Display progression (like using SCRUM) and motivate yourself with it.
Playtest as much and many times as possible.
..And finish your game!
Thanks for reading!
-
6
3 Comments
Recommended Comments