Tutorial 1.2: Game Concept + Planning

Yet another "how to waste your time on a game" tutorial, but what makes me think you should spend your precious time here? Well for one thing, probably because you have plenty of time now. But yeah you're right. It's about time we reveal our plans.

It would be a bit ironic if, 2 years later, somebody has become ridiculous rich with this "JunkThrower" game idea, while I'm still working as a bat-catcher on a Chinese wet market. But for the sake of humanity not getting deadly bored, let's risk it and reveal the ideas.

Did I just say "JunkThrower"? Making names has never been my best treat. My kids are named "boy" and "other kid". Guess how our next dog will be called? Stalin. I found that an appropriate dog-name. But yes, that's how the game is called officially / unofficially. Now guess that the game is about?

It's about throwing junk. Boulders. Crates. People. Especially the latter. As a bunch of people (or maybe monsters, mummies, panda bears, robots, whatever) are trying to reach your magic “Orb”. Don’t ask why, they just do. Like Bowser has kidnapped Peach for at least 450 times in the past few decades.

In a maze-like (top-view) map, foes will try to reach your Orb, making it grow. Like a balloon. If the orb gets stuck between the walls, it will explode, a black hole will appear, you get sucked into your phone, and game-over.

There isn’t much you can do about it, other than throwing those assholes away. Preferably against a wall, or against each other. Vice-versa, you may want to throw in health-crates and other good stuff back into your orb to…. Calm down a black hole? Whatever. You get the idea.

To make it more tactical, of course we can implement all kinds of traps. Acid pits, explosive barrels, building obstacles. That’s up to your creativity.

 

The game will be 2D, topdown, and as flat as Paper Mario. No complex story, photo-realistic graphics, or high-end 3D engines for a chance. For that, I can already torture myself with Tower22. Besides, I’m hoping a little bit that I can involve the kids at some point with drawing some sprites or recording sounds. But as you know, that only works if the graphics are simplistic and if concrete results can be shown within the next few minutes.

Tactics / Planning

Simplistic or not, you will learn, the hard way, that even seemingly simple games may still require a ton of work. And not just the programming work. Every stinky little effect has to come from somewhere. Drawings, sound effects, text-fonts, particle-effects, sprite images, music, level design, additional editors/tools to make those levels, and so on.

When starting from scratch, you will quickly ride your bike onto a steep slope. Which often is the point where quitters quit. Dreaming about games is fun, but actually making them requires discipline and iron will. I won't lie, it takes a lot of energy even to create stupid little things. Discouraging, really.

The trick is to satisfy yourself with small results. If you tell me now to lose 30 kg, I probably won't even start. If you reward me for every 1 kg I lose, I may give it a shot. Once the train is rolling, you will find it easier to keep on going, though at the same time it takes more and more progress to

satisfy. In any case, it is very helpful to make a solid plan. Then break down the plan into milestones, objectives, and small tasks. With "small tasks", preferably something that can be done in a day or two. So you can make a promise to yourself: try to finish at least 4 tasks every week. As long as you can put a fat "DONE!" mark on tasks, you'll be doing fine.

As for the steep incline in the early stage, make sure your first objectives aren't too far away. This may mean you first start with ugly dummy images, without sound, or just focus on rendering a nice background. As a visual oriented guy, I personally need to SEE things. So, with the game described above in mind, I'll first try to render some sprites. Just to see how that mechanic works in LibGDX. Keep in mind, as I'm writing this, my knowledge about LibGDX is as good as yours: pretty much none!

Next big thing will probably be rendering the level itself, which is basically just a large background image. Or, a lot of small tiled images placed in a cell-grid. There are multiple ways to go there. Well, as far as I can see now, this will be our planning. The chapters I'll write, shall follow this picture. Keep in mind I'm not a fortuneteller, so in reality we may go off-road or add things a little bit.

At the same time, I would advise not to dive too deep into a very specific aspect right away. Besides the LibGDX framework, you will also need your own mini "framework", "engine", or classes that properly describe your game in terms of levels, rules, players, enemies, objects, and so on. We won't be making a super versatile engine that can be used for the next Red Dead Redemption, but I will show you some ways to structure your game into logical parts, classes, ultimately reading to cleaner and better manageable code.