Book Image

Learning Java by Building Android Games - Third Edition

By : John Horton
5 (1)
Book Image

Learning Java by Building Android Games - Third Edition

5 (1)
By: John Horton

Overview of this book

Android is one of the most popular mobile operating systems today. It uses the most popular programming language, Java, as one of the primary languages for building apps of all types. Unlike most other Android books, this book doesn’t assume that you have any prior knowledge of Java programming, instead helps you get started with building Android games as a beginner. This new, improved, and updated third edition of Learning Java by Building Android Games helps you to build Android games from scratch. Once you've got to grips with the fundamentals, the difficulty level increases steadily as you explore key Java topics, such as variables, loops, methods, object-oriented programming (OOP), and design patterns while working with up-to-date code and supporting examples. At each stage, you'll be able to test your understanding by implementing the concepts that you’ve learned to develop a game. Toward the end, you’ll build games such as Sub Hunter, Retro Pong, Bullet Hell, Classic Snake, and Scrolling Shooter. By the end of this Java book, you'll not only have a solid understanding of Java and Android basics but will also have developed five cool games for the Android platform.
Table of Contents (24 chapters)

The Simple Factory pattern

The Entity-Component pattern, along with using composition in preference to inheritance, sounds great at first but brings with it some problems of its own, not least of which that it exacerbates all the problems we've discussed. This means that our new GameObject class would need to "know" about all the differentcomponents and every single type of object in the game. How would it add all the correct components to itself?

It is true that if we are to have this universal GameObject class that can be anything we want it to be, whether it's a Diver, Patroller, PlayerShip, PinkElephant, or something else, then we are going to have to code some logic that "knows" about constructing these super flexible GameObject instances and composes them with the correct components. But adding all this code to the class itself would make it exceptionally unwieldy and defeat the entire reason for using the Entity-Component pattern in the first...