Let's explain this picture. I guess most folders are self-explanatory, but just in case. Plus it may be useful to draw the line between "Engine" and "Game". What type of tasks do we consider generic, thus engine stuff?
The answer on that is: there is no answer on that. It's a trade-off. Very generic engines do very little. You’ll have to write a lot of (game) extension code. Flexible, but not very helpful. The opposite is an engine that goes deep in detail, almost interfering with your game. If you make a football game-engine, then it makes sense to reserve space for 22 actors on the field. And you don’t have to care about multi-platform levels with elevators and stairs. The engine will get a very narrow scope, but has been highly optimized on this type of game.
You need to control your hero, team or at least the camera right? Using a mouse, gamepad, keyboard. Or in this case, your swiping finger and the telephone accelerometer. Maybe we need to detect some multi-finger gestures. Feedback like vibrating the phone or giving electric shocks if the player messes up, should also belong here.
Loading & Saving keybinding files ("W=forward") is yet another typical controls task. But what does NOT belong in an engine, is determining the available controls. W could be forward in Doom, and throwing a fishing rod in a very different game. The available inputs and their meanings, that is something that belongs in the game. In our game however, we won't be dealing keybinding. Not much to press on a phone...
Entities
This is a somewhat abstract, yet very important one. Games and their worlds are filled with "things". Trees, monsters, trashcans, power-ups, shotguns, soccer balls, billiard balls, monkey balls. You name it. Some are just static decoration, others can be destroyed or used. Some others can even bite or kill you. Entities typically come with a visual appearance (a sprite or 3D model, maybe animations), and also often have a physical shape. So can collide with it, push it away, or at least not walk right through it.
Entities that are more than just static "statues", also have some type of behaviour. That means they need to be updated regularly, to evaluate their status, make decisions and throw their next move - which could be as simple as making a fart sound every 5 seconds. The difficulty here is that the engine doesn't know what kind of entities your game will have. It could provide "Actors", A.I. driven things. But you still have to decide whether that thing is a robot, soldier, zombie or monster. And probably extend its functionality.
The more generic part of these entities is mainly about drawing, doing physics, and managing / updating them. Entities typically use a lot of the other engine sub-systems.
Graphics
Where to start. Well I think you already know what to expect here. It's about getting that game on your screen. Again, the engine won't dictate you how things should look. You will make the images, the models, the shaders, the animations. The graphics part makes sure you can see them.
Unlike Tower22 / Engine22, the graphics part is pretty simple here, as we are making a straight forward 2D game (and sine LibGDX is helping a huge deal here as well). Note how this a restriction of this engine: it's a 2D engine, making it pretty useless for any other 3D ambitions. Sure we can throw a lot more code against it, making it more versatile. But that would over-complicate things. Keep our end-goal, a 2D game, in mind at all times.
We already created a Gx (that's ganster slang for Graphics) Camera here in the first chapters. Obviously, the camera decides what you can see, but also what cannot be seen. So we don't have to put energy in drawing things that are off screen.
Since we will be throwing with things, I expect a function or two here. Physics is about collision detection and response. If I kick your ass, then what will happen? For a platformer, think about Mario landing or slipping of those blocks. Which sounds easy enough, but is actually pretty hard. Those who have seen episodes of the Angry Video Game Nerd, or just owned a (S)NES themselves, will know the difference between the good, the bad and the ugly titles in the early platformer era. Because my god, a lot of programmers clearly didn't get it. And you know what? Can't even blame them that much, because you will find out this becomes the trickiest part of this entire tutorial.
Sound
Beep. Boink. Zoop. Zip. What else do I need to say? Not to underrate sound as it can make or break a game in my opinion. But that is mainly in the hands of the composers and audio artists, not so much in the engine that just takes care of loading (and releasing) resources, and playing them -in stereo eventually- when somebody asks for it. At least, that is as far as our simple game here goes.
World
This is always a tricky one. The world / level / map / environment, or whatever you want to call it, is where the game takes place. And boy, there are a lot of different (game) worlds out there! Corridor shooter or soccer field? Asteroids in space, or a dense forest? 2D side viewed platformer, or a top-down RTS game? Static world, a highly adjustable / destructible world? All these examples use very different techniques to load, stream, render and manage their worlds.
Engine main file
Lastly, we created an "Engine.java" file, which more or less is your main entry point for the Game code. It creates, updates and destroyes all subsystems (ie, entitySystem, soundSystem, graphicsSystem, ...). We'll get into that next chapter.
No comments:
Post a Comment