Android 2D RPG - Part 2: The Architecture

Hello dear readers! This is part 2 of the 2D RPG game for Android series. Make sure you checked out Part 1: An Idea, where we discussed the general aspects of the game we'll make, before reading ahead.

Let's get started. So far we got Android Studio up and running and we have the very basics of our game concept ready. It's time to talk about games, in general, and how they work.

Word of advice: DO NOT EVER start coding without a working understanding on what you want to do and how you will accomplish it, this will save you MANY a headache and a lot of time.

Now, every game out there has a basic loop which  repeats forever once the game starts, during the whole time it's running and up until the game ends, for whatever reason it does. This basic loop consists on taking user input, updating the game objects (think about the character position coordinates, for example) and rendering the game state (which is the collection of the game object's states that will be displayed).

The Input

The user input in our game in generated by touching the screen. I.e., if we touch a map square that is unoccupied and reachable (by pathfinding), our character should move there. For our character object, this means updating the position coordinates.

As we can see, input is used to alter the game objects, that's why the game should always be ready to handle user input, and even so, the updating and rendering processes need to continue even if there's no input from the user, that will allow NPCs or objects to continue their animations even if the player is not doing anything. In a way, the input is not really part of the loop, but it works hand-to-hand with it.

The Updating

The updating process consists on changing the state of the game objects. Which direction our character or a NPC is facing, if we're doing an action or just standing, whether a conversation is taking place, etc. This changes will affect what is being displayed. As we mentioned before, the updating part does not necessarily require user input to happen.

The Rendering

The rending consists on drawing our game state on the device, simply enough. This will lead to the infamous FPS but we'll leave that for later, when we get to that part in our game code. Alongside the graphic rendering, it's usual to output audio and or vibration. For the sake of simplicity, audio and graphics will go together in the rendering process.

In conclusion, a typical game architecture will look like this:
  1. User Input (if any)
  2. Update Game Objects
  3. Produce Sounds
  4. Render Game State on Display
  5. Repeat from 1 (if game not over)
With this information at hand, we can make a rudimentary game loop consisting of endless calling for updating and rendering processes, in that order, while listening for user input. It's time to start working on our app now.
So go get your Android Studio ready, we'll finally start using it in the next part of this series, Part 3: Creating our App! You can go ahead to it or check out the series' index at Android 2D RPG Series.

If you enjoyed this post, I'd be very grateful if you'd help it spread by sharing it on Twitter or Facebook. Thank you!

If you have any questions or ideas, let me know in the comments!

No comments:

Post a Comment

Got something to say? Speak your mind!