Thursday, April 28, 2016

Drake - 10 Bands - Design Decisions: Code

*DISCLAIMER*


This information regarding code is not meant to:
  • Show you how to get your IDE setup
  • Show you how to import LibGDX into a project
This information regarding code is meant to:
  • Go over some design choices I made considering the framework at hand
  • Explain how you can modify the code to create your own levels/obstacles.
  • Cover some OOP concepts regarding game architecture.

This is not basic game design instructions. If you are looking for that, please go follow LibGDX's guide to making a simple game first and build off of it with the simple game extension like I did. Most of the information on their wiki page explains different things that I utilized such as animation, stages, using the accelerometer, etc. etc. I will cover some of those topics lightly.

*END OF DISCLAIMER*

Copied Code:

Classes include:
  • GenericActor
  • HorizontalMovingActor
  • VerticalMovingActor
Some code I utilized from a completely different game I had been working on three months prior to starting 10 Bands. During that game's development process I had to make use of stages and actors extensively because it has many layers to it. The Drake game didn't have many layers, but it was much easier to create one stage to have moving actors (phones) on instead of trying to keep all of their positions updated via their particular level class. It keeps code use to a minimum and already came with some animation looping settings that I was able to apply to the sleepers.

Horizontal and Vertical actor classes extends Generic Actor and Generic Actor extends the base Actor class that LibGDX supplies. Mine are built to take in parameters such as single/multiple texture regions to use, positions to be drawn at (starting and ending for moving sprites), floating value for speed in which the objects move, and booleans to state whether the animation should stop when it reaches its destination or continue going and whether or not to flip the textures when they return (such as a sprite that needs to face a certain way when heading in that direction). My HorizontalPhoneActor class extends HorizontalMovingActor and only has code telling it what to initialize regarding how it works as a horizontal actor. The same goes for my VerticalPhoneActor class.

Other Extensions:

After finally mocking up the screens and determining how I want my menus to look, I noticed that some things didn't change much between said screens:
  • All of them had a button in the top right that either said "Back" or "Quit."
  • They all had a title.
This was a perfect opportunity to create one screen with these options setup and to have my other screens extend them. My particular screen class included:
  • A string parameter that could be defined upon calling it where it would be printed to the same spot always in the center of the screen horizontally. If you go through all the menus you can see what I'm talking about.
  • A button already created which only needed to be defined for its action in the class extending this one.
The main screen class that the rest of the screens extend is GenericMenuScreen.

Best OOP Practice:

More extending! No seriously, in every level you have to:
  • Draw Drake
  • Check the collisions of Drakes various rectangles against the rectangles of the bands, phones, and sleepers
  • Play music and sound bytes
  • Draw floor tiles
  • Save record breaking scores/times
Why would you not put all of that into one class and have your levels extend it? There is so much code there I would hate to see it copied for each class. The main class is Level in which all of the level classes extends.

Tidbits:

  • The game is in landscape mode so I move Drake on the X axis based on the phone's accelerometer Y values and vice versa. If the game was in portrait mode then I would've used the X and Y values naturally to move him along those respective axisissys

No comments: