Saturday, February 13, 2016

Bob's Race through Space: Development progress 1/18/16-1/29/16

I have finished many of the core mechanics of my Android side-scroller which I have decided to call Bob’s Race through Space. In the two weeks since the beginning of class I have built the physics system for in-game objects, programmed both on-screen controls and physical gamepad input, made one simple enemy which can hurt the player or be squished by the player jumping on it, and started working on stats like health, coins collected, etc.

Physics System

Bob’s Race through Space is an idea that I’ve had for a while now but never finished. I actually did start it at one point and got some of physics and controls finished. After looking through the code, I decided it was messy and not very well organized. Using my original code as reference, I started a whole new Android Studio project and started rewriting the game.

When I talk about the physics system, I’m referring to gravity, ground detection, wall detection, and detection of other solid objects. In the game, there are objects (the player, crates, etc.) that must fall due to gravity and stop when they hit the ground. If they are moving horizontally, they must also stop when they hit a wall or another solid object. Objects may even be able to push each other (the player can push stacks of crates).

For detection of the ground and walls, I decided to use what I usually call a “collision map” but is sometimes referred to as a “bitmask”. This method uses two images to create the layout of the level. One image is what the player actually sees. It is decorated, detailed, and you can see all the platforms on it. However, detection of the platforms from this image would be difficult because they are too complicated! There many different colors, decorations, how would we know what part is solid, what isn’t? The image below is the test level that I created. You’ll be able to compare the complexity of this image to the collision map soon.

The second image as you may have guessed is what I call the collision map. It is the same dimensions of the previous image, but looks much different. In the collision map, the sky is black, solid platforms and walls are white, and “semi-solid” platforms are cyan.

The position of a physics compliant object can be compared to this image to determine if it should be falling (in the black) or stopping (in the white or cyan). Objects cannot jump through the white portions of the map. If an object is moving upwards (like if the player jumps) and the top of the object hits a white portion, it will stop moving upwards and begin falling down. The cyan portions however can be jumped through and landed on top of. The player can also press the down button to fall through these portions of the map.

Physics compliant objects can also stack on top of each other and push each other around. In the image below, you can see the player standing on top of some crates that are stacked on each other. I’ll use this in the game for puzzles that require the player to push crates and stand on top of them to get to places.

The physics system is the most complex part of this project so far. Luckily I had some previous work of mine to work off of but it was still difficult and time consuming. I spent a lot of time fixing glitches and it seemed that every time I fixed one it created another. Collision detection with the map wasn’t too bad, but collision detection between objects was difficult. I ended up with a pretty good physics system that will do everything I need it to, but I think if I were to do it again I would implement a more accurate third party solution like Box2D instead of trying to make my own.

Controls

Bob’s Race through Space includes four basic controls: left, right, down, and up. In the previous image, you can see the on-screen buttons for these controls labeled with arrows. A Bluetooth controller can also be used to play the game. Using a Bluetooth gamepad will even hide the on-screen buttons. I used an InputListener class to handle input from both the on-screen controls and the physical controller. Both types of controls fire the same events in the InputListener class so that both types of controls have the exact same effect in the game.

The controls fire methods in the player class that cause the player to do the corresponding action. For example, there is walkLeft() and walkRight(). All of these methods modify variables in the player’s physics data component. For walking left and right there is a target X velocity variable. The physics system will accelerate the player until it is moving at the target X velocity. This way, there is a small amount of friction. The amount of friction could be adjusted for things like ice platforms.

Pressing up (or A or B on a Bluetooth gamepad) will change the player’s Y velocity so that it will jump up into the air. The amount of time the button is held will affect how high the player jumps. Pressing down while on a semi-solid platform will cause the player to fall through the platform. This is done by telling the physics system to temporarily ignore cyan colored platforms.

Enemies and Level State

Each level in the game will have a certain number of enemies remaining, a certain number of collectible tokens (stars, coins… I haven’t decided what yet), a timer, and of course the player’s health. I have a “Level State” class that will track all of these things. The health portion has been implemented and is used to display the correct number of hearts as you can see in the last image.

In the next image you can see a basic enemy. This enemy bounces back and forth between the walls in the map. If it touches the player, the screen will flash red, a heart will be lost, and the player will blink for 3 seconds indicating that it cannot be hurt again until the blinking stops. If the player jumps on the enemy, the player will bounce off and the enemy will be destroyed, falling through the map and off the screen.

Next Steps

I have finished most of the core mechanics for the game and so I am on schedule. Over the next week I will work on programming UI related things like the start menu and level selection menu. If I have time, I may work on a Game Over screen as well. The start screen needs include the title, a “play” button that brings the user to the level selection screen, an “options” that will be used later for volume controls and on-screen control adjustment, and possibly some other buttons for future purposes.

Saturday, January 16, 2016

BobEngine has been Updated to an Entity-Component System

Enhanced Logo

It may have seemed like I just dropped off the face of the Earth for the past month or more but there are a few reasons for that. First, it was the end of the semester so I was very busy studying for final exams! Then it was Christmas break and I had just bought GTA V and gotten A Link Between Worlds as gift so I put some hours into those... :) But I wasn't totally slacking on my Android work! In the time since the last tutorial video I made I've been working on a massive over-haul of BobEngine.

Updates can always be found at https://github.com/Bobbyloujo/BobEngine

The update, which I just pushed to GitHub before writing this, introduces a new Entity-Component design system to BobEngine that is still mostly compatible with all the old features and uses of BobEngine. I should note: some things from the old version have been removed and package names and hierarchy has changed. Most of the things that were removed were poorly implemented features that I think most people did not use anyway. Among the features removed was the collision system, however it was replaced with a better system which I will go into later in this post. Many projects will be able to move over to the new version will little trouble, however imports will need to be fixed.

Let me talk about what an Entity-Component design system is and how I decided to implement it into BobEngine. The simplest definition I give is this: in an Entity-Component system every object in the game is defined as entity (player, enemies, coins, etc) which are composed of components which can hold data or add functionality to the entity (health variables, movement logic, input handling, etc).

BobEngine has been revamped to be centered around an Entity class and Component interface. The Component interface is empty and used as a marker interface. You can create any component you want just by implementing (or extending!) the Component interface. It can then be added to entities and has the benefit of being retrievable from the entity by component type.

Why did I choose to make Component an interface? I wanted to be able to make components that are a combination of different functionality. Let me explain:

There are some special component types in BobEngine that extend the Component interface. These include Updatable, TouchInputHandler, and others that help add functionality to components. For example, Updatable adds the method update(double deltaTime). ANY component that implements the Updatable interface and belongs to an entity in the current room will be updated via its update(double deltaTime) event each frame. TouchInputHandler works similarly but includes events for handling input from the touch screen. So, you want to make a component that updates every frame AND can handle touch input? Simple. This way you can just implement both interfaces!

An Entity in BobEngine is also a component. One effect that this has is that an entity can be a collection of other entities. This could be helpful for something like a large boss that consists of multiple parts.

Also, because of the way I implemented components it is possible to give entities functionality like updating and input handling. This allowed me to convert GameObject to an entity while keeping the usage of GameObject almost the same. The only major difference to the use of GameObject is the removal of the Quad inner class, but good riddance to that. The same functionality that Quad provided can be obtained more simply with the Entity-Component system.

Also worth mentioning: Rooms are also now entities and can be given components.

For those of you who have invested time in working through the video tutorial series, you'll be happy to know that everything learned in that series is still usable. More tutorials will be made to teach you how to use the new functionality.

So, other than the switch to an Entity-Component system, what else is new?

The New Collision System

I mentioned earlier that the old collision system had been entirely removed and replaced with a new one. So what is the new system like? You'll find that there is a new class called CollisionSystem accompanied by CollisionBox and CollisionHandler. A CollisionBox is a component that can be added to an entity and as you might have guessed it defines the bounds of a box used for the detection of collisions. A CollisionHandler can be assigned to a CollisionBox so that when that box collides with another the collision event can be handled. Entities with CollisionBox components can be added to a CollisionSystem which will check for collisions between the boxes and dispatch collision events to the CollisionHandlers! A new example is included in the Android Studio project which demonstrates a few different uses of the collision system.

Parent Transformations and other fun tricks

In the new BobEngine transformations (position, rotation, dimensions) are handled with Transformation components. This allowed me to implement a new feature: parent transformations! Have a player entity and you need to his cape to stay on his back as he moves around? No problem! Just set the cape's tranformation's parent to the player's transformation! The cape's new "origin" will be the position of the player, so the cape can now be easily positioned relative to the player! This also effects scale (which is also a new feature!) and rotation! You can see how I played around with this in the example bobEngineTest with the entity BobEngineMothership.

This is also fantastic for large, multi-part entities.

The "BobEngine mother ship" composed of 7 separate entities

Room Grid

Rooms now use a grid to place objects on the screen. By default, the size of one grid unit is one pixel so it will behave just like before. However, you can now set the size of the grid units manually and independently for the X and Y axes. The size of a grid unit can be set as a number of pixels or such that a specific number of units will fit in width or height of the screen. I recommend the latter and here's why: the getRatioX() and getRatioY() methods have been deprecated. Any sizing or positioning of objects on the screen will use grid unit rather than pixels. So if you set your grid to be 20 units wide, an object with a width of 10 will always be half the width of the screen no matter the actual size of the screen. Also, if the object starts at an X position of 0 and moves 1 unit per frame, it will always take 20 frames for the object to move across the whole screen regardless of actual screen dimensions.

Jumpy Bug has been updated in many ways to demonstrate usage of all the new features including the new grid feature.

Closing Thoughts

There are some other fun things in store for you when you check out the new version of BobEngine. The numbers and characters graphics have been updated, the out-of-place utility functions in Room (getAngleBetween(), etc) have been moved to a Util class, and some other things have just been reorganized in ways that make more sense then before.

I really feel like this update opens the door for many new use cases for BobEngine and will help make BobEngine one of the best open-source engines for Android. This update also creates a lot of room for expansion, such as the possibility of OpenGL ES 2.0 support and other great features. I will be changing up my workflow a little bit after this update. You may start to see more frequent but smaller updates from here on out. This new version will not be given a new version name and will just be referred to as BobEngine.

If you find any bugs or have some suggestions or insights, please do let me know. The decision to make this change was made after some discussion on Reddit and it really helped me improve my engine. I'm all ears!

As always, if you have any questions feel free to ask. You can contact me on social media or via email:


Email: bobbyloujo@gmail.com

Happy developing,
Benjamin Blaszczak

Tuesday, September 22, 2015

BobEngine Tutorials are Here!



On Saturday I released the first two video tutorials for my 2D Android game engine called BobEngine! The tutorials can be found on my YouTube channel. BobEngine aims for simplicity, so if you're looking into Android game development and want an easy starting place, this might be for you!

The first tutorial starts with the very basics. Since BobEngine is made for use with Android Studio, you'll learn where to get Android Studio in the first tutorial. You will also learn where BobEngine can be found and how to download it and view the examples. There's a brief explanation of the examples, and then I show you how to start your own project and import BobEngine.

The second video picks up where the first left off. First, I explain the structure of a BobEngine game with a some visual aids. Then, using the project I started in the first tutorial, I show you how to implement the structure I talked about in code which leads to being able to output images to the screen. I talk about loading graphics, displaying them, and moving them around.

The next tutorial will focus on getting input from the touch screen. BobEngine has a lot of useful features for using touch screen input so I'm sure that tutorial will be very informative. Hopefully I can get it finished either this week or next week. My school work and part-time job keep me pretty busy, but I would like to release new tutorials at least every two weeks. I can't make any promises, but I'll try my best!

Future topics could include:
  • Sound effects and music
  • Gamepad input
  • Advanced graphics options
  • Advanced Room and BobView uses
  • Specific examples and use cases
  • Coverage of any features that I add in the future - BobEngine is an ongoing project!

To watch the tutorials, follow these links:
Tutorial 1: Introduction and Importing BobEngine
Tutorial 2: Outputting graphics

Don't forget to subscribe to my channel on YouTube if you want see the next tutorials as soon as they come out!

If you want to see a specific topic covered in any of my tutorials go ahead leave a YouTube comment describing what you would like to see. If you have any other general suggestions for me, go ahead and leave those in the comments as well. I'll take every piece of advice into consideration! Lastly, if you like these tutorials don't forget to hit that like button under the video!

Until next time,
Ben Blaszczak
a.k.a. Bobby Lou Jo

Wednesday, July 15, 2015

BobEngine v3.0 Bobsled

It's been a while, but in the time since my last update I've added a lot of new things to BobEngine. Since it's such a big update, I'm giving it a new version name: v3.0 Bobsled. Here goes:

  • RoomCache - In BobView.java you will find a new static class called RoomCache. As the name implies, RoomCache is used for storing and retrieving instances of Rooms. The nice thing about RoomCache is that you can call getRoom(Class roomType) with any class type that inherits Room and the function will return an instance of that room type, even if you haven't manually added a Room of that type to the cache. The function getRoom(...) will search the cache for an instance of roomType and return it if one is found OR it will create a new instance of roomType using reflection and return that. You'll also notice that there is a getRoom(Class roomType, Object... args) function. If you have created a room type that takes parameters other than (BobView view) like a default Room does, you can use this method to pass the required arguments to initialize a new instance of that room type if need be. The cache holds a specified max number of Rooms. When the cache is full and a new Room is added, the oldest Room is removed. You can make your own RoomCaches, but each BobView has it's own cache with an initial size of 3. To access it from your BobView, just call getRoomCache().
  • Along with RoomCache, BobView has received two new goToRoom overrides: goToRoom(Class roomType) and goToRoom(Class roomType, Object... args) for switching to rooms retrieved from the RoomCache.
  • Input events (newpress, released) are now handled on the main thread (same thread as step event). Handling game logic on the separate input thread was causing a lot strange glitches in my games when values were being changed when I was not expecting them to be changed. Now, input will be handled on the same thread just before the step event.
  • For even more convenience and even quicker game development, a new constructor has been added to GameObject: GameObject(Room room). This will automatically assign an instance ID number AND add the object to the room. What typically looked like this before:
    Code:
    GameObject object = new GameObject(room.nextInstance(), room);
    room.addObject(object);
    Now looks like this:
    Code:
    GameObject object = new GameObject(room);
    So simple! The old constructor is still there and behaves the same way for those who want it and for backwards compatibility.
  • Setting GameObject.visible to false will now hide all Quads belonging to that GameObject. This will not change the Quad.visible field for any Quad. Also, similarly to GameObject, Quads are now added to the GameObject when initialized.
  • Animations can now be played once and looped for a limited number of times. animationFinished() will return true when an animation has finished playing.
  • Animation class - a new class has been added to GameObject.java. This class can be used to predefine animations with a start frame, end frame, fps, and loop times.
  • Previously, I was using 3 coordinates for each vertex. I learned it's possible to use only 2 in OpenGL. Since the 3rd vertex is not needed, I changed the code to use only 2 vertices. I'm not sure if this actually caused any performance improvement.
  • Graphic.Parameters class - A new class in Graphic.java allows you to predefine Graphic parameters to use with GameObject.setGraphic(Graphic.Parameters params). Useful for when you want to switch between graphics on a GameObject often.
  • A new method in the Graphic class called setDimensions(int width, int height) allows you to set the height and width of the DPI level image you want to use for setGraphic(Graphic g, int x, int y...). Previously, you would have to use setPreciseGraphic(...) if you had different sized images for different DPI levels that have multiple graphics on them.
  • Set the color intensity of all GameObjects on a specific layer using Room.setLayerColor(int layer, float r, float g, float b, float a).
  • Graphics management (this is a big one):
    The Room, Graphic, and GraphicsHelper classes have been updated to improve and simplify management of graphics for large games. A new GraphicsHelper.cleanUp() method makes it easy to manage graphics. You can choose points in your game to call cleanUp(). When called, Graphics that have not been used recently will be unloaded and removed from the GraphicsHelper. Graphics have a new public field called 'persistent' which when set to true will cause the graphic to remain loaded when cleanUp() is called. All non-persistent Graphics will survive through a set number of cleanUp() calls before they are removed. If a Graphic is removed but then a GameObject tries to use it again, it will automatically be re-added to the GraphicsHelper and reloaded.

    You can also manually call:
    Graphic.load() to load a graphic after is has been added to the GraphicsHelper.
    Graphic.unload() to unload a graphic
    Graphic.remove() OR GraphicsHelper.removeGraphic(Graphic g) to unload and remove a Graphic from the GraphicsHelper.

OKAY, I think that's just about everything. I actually had to look through the changes in the GitHub commit to remember all the things I've changed xD There are a few other small changes but I didn't think they were important enough to list.

I'm tossing around the idea of doing a tutorial series for BobEngine. It would be a video series on my YouTube channel. I would start with the basics, then explain more advanced features like graphics management. I could also take requests for certain tutorials. I could even cover general game development topics and how to implement them with BobEngine. Doing this would be a lot of work so before I dive in I really want to gauge the level of interest in BobEngine. So far, it's been difficult to tell how many people are interested because I haven't gotten an overwhelming amount of replies here but every once in a while I get a PM or email asking for help. So if you're using BobEngine raise your hand! :P

And of course: if you've made anything with BobEngine I would love to see it! I've seen a few things and it makes me happy to see you guys using getting some use out of my engine.

Thanks for your time! If you have any questions, just ask. If you find any issues with BobEngine, go ahead and open an issue on GitHub and I will fix them. Also don't forget to let me know if you're using BobEngine!

Once again, the repo can be found here: https://github.com/Bobbyloujo/BobEngine


Ben Blaszczak
a.k.a. Bobby Lou Jo 

Friday, January 2, 2015

BobEngine 2.0 Shishka update

A little while ago I released the first public version of my 2D game engine for Android called BobEngine 1.0 Thingama. I've been working on adding some new features that I felt were crucial to a simple but powerful engine. Following the theme of things that end in "bob" I have denoted this second version of BobEngine "Shishka".

This new version includes the following new features:

Camera methods

setCameraX/setCameraY - For changing the position of the camera.
setCameraZoom - For zooming the camera in and out.

Other camera methods and functions are also available for use with the ones above such as getters for the camera coordinates and zoom level as well as a method for changing the anchor point which will be the point that stays in place when changing the zoom level of the camera.

Unload and reload graphics whenever you need

BobEngine 2.0 Shishka provides load and unload methods for releasing graphics when they are not currently in use. This can be useful for applications such as displaying large maps one piece at a time.

New examples!

Along with the two from before, we now have:

bobEngineTest - Allows you to test the performance and features of BobEngine
cameraexample - Shows how to use the new camera functions!

More examples to come!

Android Studio

Since Eclipse is no longer the official IDE for developing Android applications, BobEngine has been migrated to Android Studio! The included Android Studio project contains the bobEngine library module that you will need to use BobEngine with your own projects as well as modules for each of the examples.


This update also includes some under-the-hood changes that improve performance and usability. For example, BobEngine will automatically down sample graphics when too many graphics have been loaded to fit in the memory. When this happens, you will receive a message in logcat. You should try to avoid this by optimizing your graphics, but it's better to down sample than to crash!

Where to get it?

BobEngine is free and open-source and can be found on GitHub at this URL:
https://github.com/Bobbyloujo/BobEngine

BobEngine is licensed under the GNU Lesser General Public License v2.1 (LGPL-2.1) which means you can use it for free both non-commercially and commercially.



Thanks for having a look at BobEngine! If you find it useful, be sure to tell your fellow programmers about it and follow me on Twitter so you don't miss any updates from me!

Benjamin Blaszczak
a.k.a. Bobby Lou Jo
@Bobbyloujo

Monday, October 6, 2014

How Android TV could Change the Game for Microconsoles

The topic of microconsoles has sort of become a joke in the gaming community after the rise and then quick, dramatic death of Ouya. Intended to be a haven for indie developers, the Ouya game console was a huge success on Kickstarter raising nearly $8.6 million making it the 2nd most funded campaign on the website at the time. With all that money raised by over 63,000 backers it's obvious that this is a product that people wanted. It's hard to believe that after all that hype the Ouya could've failed as badly as it did. So, what happened?



Despite being a good idea, Ouya's implementation of an open, easy-to-developer-for indie console just didn't do the idea any justice. First off, the Ouya's hardware was very disappointing. Although the slightly outdated Tegra 3 could've been overlook as graphics aren't everything, the terrible controller and other miscellaneous annoyances such as bad wifi reception really gave the impression of the Ouya being a poor quality device. A strange feel in the hand and bad input lag from the controller made gaming difficult and uncomfortable. Sure, you could use a third party controller or a PS3 controller, but those can run around $40 which is a bit of an issue considering the Ouya was meant to be an inexpensive gaming experience.

Aside from having bad hardware, the Ouya also had more than it's fair share of software issues. The interface is a bit clunky and hard to navigate quickly. However, that may have been excused if the console had any good games. Or maybe I should say: if you could find the good games. The Ouya "Discover" store is jammed full of small, low quality games and direct Android ports. Some of the ports benefit from being played on a TV, but one would expect more than just mobile ports from a game console. With the Discover store being saturated with low quality content paired with the console's less than perfect sorting and organization, it's very difficult to separate the good from the bad on the Ouya and so you might understand why it didn't succeed.

If you keep up with gaming news at all you probably already knew everything that I've discussed in this article. So why does it matter that we talk about this now?

Well, at Google IO we caught a glimpse of a new Android based operating system called Android TV. You guessed it, it's an OS for little boxes that you plug into your TV. Basically, it's meant for devices like Roku streaming boxes and Apple TV. The twist that Android TV brings to the table that it also plays games. That means that we'll start seeing many new devices just like the Ouya that run Android TV.
www.android.com/tv

So, what's different this time around? Why do these new Android TV devices have potential to succeed? First, don't forget the tremendous amount of potential the Ouya had. The success of it's Kickstarter campaign shows it was something that people wanted. These new devices will have all that potential and more. Why? There are a few reasons.

On top of the list of reasons is the developer of the OS. It will be a Google product and it will be based on Android. Granted, not every Google products succeeds but many of them do and at least they aren't some unknown start up. Google has the resources to make this succeed. Also, Android TV is of course based on Android which is a tremendously successful OS. Google's job as a part of making microconsoles successful will be to create good software to run on them that is easy to develop for and provides a good UI and a good discovery platform for developers to help their apps get noticed. They've done a pretty good job with all three of these things on Android and I think they could do it with Android TV as well.

The success of microconsole gaming isn't solely in Google's hands, though. Android TV will be available to many device manufacturers. These companies will be in charge of avoiding the mistakes that Ouya made and creating high quality and high performing consoles. The introduction of competition between Android TV devices should bring some new and exciting ideas to the world of microconsole gaming. Just like with Android devices in general, we'll see high end and low end Android TV devices. Although this may be confusing to some, to others it will open a world of choices from low spec, low cost to higher specs at less competitive prices and possibly a range of extra features between different devices.

Speaking of high specs, the timing of Android TV's announcement couldn't have been better. With the Tegra K1 chip promising more performance from mobile devices than you may have ever thought possible, it seems that future microconsoles won't be held down by the lackluster graphics capabilities that we've seen in mobile devices and other microconsoles compared to the current kings of the console industry and PCs. With the Tegra K1 and Unreal Engine 4 on Android already game devs might just decide that porting their games to Android TV may be simple enough to benefit them meaning that we could see console level games coming to Android TV.

So the question still remains: will Android TV devices revive microconsole gaming? And will these new devices dare to compete with current kings of the console industry? Only time will tell, but I certainly think that the foundation is there and the possibility is real.

Bobby Lou Jo

Wednesday, July 9, 2014

BobEngine: the Power behind Plane Popper

I have finally finished and released my first Android game: Plane Popper. If you haven't already, you can get from the Play Store. It is free, of course :)

Now that my game is finished, I wanted to take the time to tap out a little description of my custom game engine that I designed when writing Plane Popper. I will refer to my engine as "BobEngine". If I ever decide to release BobEngine (which I am really considering) look for it under this name. BobEngine is not currently a finished project and needs to be more generalized before it can be used for general game creation. My next project will be to work on generalizing BobEngine. Terminology within BobEngine may change between now and the time of its release. Be sure to check back here regularly for updated information.

The purpose of BobEngine is to create a very simple way to make 2D Android games. I aim to simplify and streamline the process as much as I can. To get an idea of what BobEngine will be able to do, download and play Plane Popper from the Play Store.


Features


Basic Organization of Objects on Screen


BobEngine aims to create a similar structure to that of the programs Game Maker, DS Game Maker, and many other game creation software products that use objects inside rooms or scenes. In BobEngine, there are GameObjects which preside inside Rooms. GameObjects are objects that appear on the screen. They can either be for decoration or they can allow the user to interact with them. Rooms are a collection of GameObjects that are meant to appear in the same space. BobEngine will allow the programmer to create any number of Rooms needed and any number of GameObjects. The programmer will be able to switch the current Room at any time as well as reset the current Room to its default state at any time. BobEngine can even handle updating and rendering several Rooms at once, one layered on top of the other.

Rendering, Textures, and Animations


Rendering is handled very efficiently in BobEngine using openGL ES 1.1. GameObject textures should be grouped together onto texture sheets to improve performance. The programmer will be able to specify the location, size, and number of frames for a specific texture on a sheet. BobEngine will provide simple methods to change animation frames and loop through a range of frames at a given rate. BobEngine is able to render thousands of small quads (such as the dots that make up the tails of the firework sparks in Plane Popper) before taking a performance hit. Small particle effects should be easily achievable in BobEngine.

Input


BobEngine will support multi-touch input from the touch screen. The programmer will be able to track three states of input for each touch (newpress, held, released) as well as the (x, y) positions of the touch inputs. There will also be simple methods such as isAreaTouched(x1, y1, x2, y2). Keypad and controller support may also be implemented somewhere down the line.

Sound


BobEngine implements Android's SoundPool for easy handling of sound effects and music. SoundPool operations are handled with simple play(sound), pause(sound), and stop(sound) methods as well as overloaded methods that give the programmer more options when handling sound.


Conclusion


I will continue to post information regarding BobEngine on my blog and on my Twitter feed during the coming months. Be sure to continue checking back here for more information. If the demand is strong enough, I may even open-source BobEngine but I will not make any promises in that regard. Upon release, I will provide proper documentation and sample projects for BobEngine.

Also, stayed tuned for more information about the success or lack-thereof of Plane Popper! I will be posting reports regarding revenue and userbase as well as commenting on the experience of releasing an Android game for the first time. My next post will likely be about what a new programmer should expect when he or she releases their first game on the Play Store. Stay tuned!


Benjamin Blaszczak
aka Bobby Lou Jo

Friday, May 2, 2014

Welcome to my DevBlog!

Hello everyone and welcome to my development blog! My name is Benjamin Blaszczak a.k.a. BobbyLouJo. I'm an independent video game developer and I'm currently studying Computer Science at Penn State University. This blog is dedicated to my games and other programming projects.

I started programming in 2009 when I was in ninth grade. My programming adventure began with creating simple homemade (or "homebrew") games for the Nintendo DS. I created several of these - some finished, some not - and learned a great deal about programming and game creation in the process. The first game that I ever finished was titled Plane Popper. It was a simple game in which the player flies an airplane up and down, popping balloons and dodging bricks. Over the next 5 years, I started many projects and finished a few that am quite proud of, most notably Christmas Jump and MOTH. I've always done all my own artwork for my games and by comparing Plane Popper with MOTH you can see that I came a long way.

Now, for the past year and 5 months I have been hard at work on something new. In November of 2011 I started to teach myself Java and learned how to use the Android SDK. I began work on a total overhaul of Plane Popper for Android devices. While keeping the main idea of the original game - a plane that pops balloons - this new version of the game includes reworked game mechanics and completely new upgraded graphics. The game is in it's final stages of development and I'm very excited to share it with everyone!

Stay tuned for development updates and release information for Plane Popper!

Ben
BobbyLouJo