LD34

Didn't join LD33. Couldn't come up with any ideas. LD34 has two themes because they tied. "Two button control" and "Grow". You can use one or the other, or both.

I went with grow, since I kinda had an idea already. My first idea was a top down puzzle game where you had to try to exit this maze thing and there was this machine placed in some areas that would make you large and small. But then that would only work if the theme was "Shrink".

Their twitter page showed some plants growing, so I'll just do something with farming, Harvest Moon style.

LD #32 - Super Worm Fanning

Well it's been 24 hours. It seems done. I don't feel like working on it anymore.

http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=37077

LD #32 - Unconventional Weapon

I didn't want to make another platformer, but it looks like I don't have too much of a choice. So. Weapon of choice: a frikin fan. I'm gonna kill some bugs with wind by blowing them off the center platform a la Super Smash Bros. Not the greatest idea, but whatevs g.

It's about 2 hours in now, and I'm gonna get some nap time.

This game is looking so aestheitcally pleasing.
But no seriously, I want to finish all of the core mechanics by tomorrow noon at most, and I'll spend the rest of the time on the art side.

UPDATE:
It's about 19 hours in now. I got bored working on the mechanics, so I did those and the art together.

And an upgrade system.
The point of the game is to last as long as possible. Timer is constantly ticking down and knocking worms off gives you a bit of extra time, depending on how fast you take them out.

I just got an awesome idea. I could have the background cloud things rotating, each one in alternating directions. That would look trippy son.

The supernado destroys everything in its path. Kinda makes that one upgrade useless though.

Should probably turn down the combo leniency. I'm getting combos too easily.

AR Suit - LD #30 game

Well that turned out better than expected. I had a lot more time to work with on this one.

You can try the game here.
http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=37077

Oh snap.

	Coolness	100%
#6	Fun	4.19
#9	Overall	4.23
#43	Theme	4.06
#60	Audio	3.74
#92	Mood	3.68
#96	Graphics	4.02
#153	Innovation	3.75
#337	Humor	2.71

LD #30 Half way point

24 hours left. Theme is Connecting Worlds. I couldn't come up with any interesting ideas. The only thing that struck me was something similar to the one I made for the 29th LD.

Yep, another puzzle/skill platformer. This time, you're a dude who tests out new technology. You've been commissioned to do a field test on the new AR (Alternate Reality) Suit. Time to sharpen your reflexes.

Awesome video

I guess the second half should be spent on moar levels and audio. I don't plan on making a menu, or level select, or whatever.

UPDATE:

3 hours left. Hauling ass trying to finish the last couple of levels and get some musica going. I got my trusty custom tilemap editor (not that crappy one from the Dragon Tale tutorial). I'm going to try for a menu seeing as how I'll be finishing a little bit early and I can afford the time. And maybe a score screen, based on how many deaths you've acquired.

Google Play Developer Console

There were some things regarding how exactly the Developer Console submitting process that confused me. I'll try to describe my experiences here. Hopefully people can see this and not have to wonder what some stuff does, or how to do some things, like I did.

--------------------------------
- Google Play Game Services -
--------------------------------
GPGS is treated like an actual game. They really call it a game which I find confusing because to me it's, well, a service. So when they ask stuff like "Publish the Game?" when I save some stuff in GPGS, I get nervous that I'm publishing the same game twice or something.

Once you create your GPGS "game" you have to link it up to one or more actual games that you've made, including cross-platform which is pretty cool.

One of the slightly annoying things about making a GPGS for your game is that you need to create 5 achievements and a leaderboard, or else you can't publish it. Even if you aren't going to use those two, you still need them. Fine, whatever bro.

-----------------
- Alpha Testing -
-----------------
You upload your APK to either Alpha, Beta, or Production. If you upload to Alpha, you still have to publish a store listing, but it's not publicly viewable. You can't even search for it. Only people in your alpha testers group who have opted in for testing can visit the store listing and download the game.

Another thing I've never found out is when I'm uploading to Alpha, I have to keep incrementing the version number. What if I uploaded an APK to Production with the same version number as the Alpha APK? (This is automatic if you move your Alpha APK to Production) What if I uploaded an APK to Production with version 1 even though the Alpha APK is like version 100?

EDIT:
When you move an Alpha APK to Production, the store listing becomes public immediately, even though the Production APK isn't ready. Just watch out. For the first few hours, clicking on the install button will cause a "can't find item" error.
I have no idea what's the problem.

EDIT2:
I just uploaded a new APK straight to Production and it worked. If you know what's good for you, never move Alpha APKs to Production. Just upload a fresh copy to Production.

------------------------
- GPGS Development -
------------------------
You're going to need to download the GPGS libraries in the Android SDK Manager. Then you have to go to the Google sample apps and grab BaseGameUtils. Link up both of those to your Android project and you're set.

If you're getting tons of errors, in BaseGameUtils, it's probably outdated. I had a whole issue with this where I had the latest GPGS but the BaseGameUtils samples weren't updated yet, and I'd get hundreds of errors everywhere.

As for using the GPGS API in LibGDX, the most common method seems to be to have your LibGDX game in your core project communicate with the Android launcher in the Android project via some interface. Very awesome tutorial on how to do that here. Warning though, it's a little bit outdated. GPGS has changed their API quite a bit, but it shouldn't be too hard to figure out.

When in doubt, press Ctrl + Space. Yeah that just brings up the little Eclipse helper box thingy.

~*~*~*~*~*~*~*~*~*~*~*~

Anyway, those were just some of the few things I was unsure about. Hopefully other Android developers using the Google Play Store find this helpful.

Leaderboards and Achievements

Looky looky at what I have here.

Video

That's right. Leaderboards and Achievements. Also, I found out you can actually record your Android 4.4 (KitKat) screen using ADB. No root required. Kind of a bummer to people not using 4.4.

Anyway, I had to jump through a bunch of hoops just to get these working. Linking libraries, getting OAuth2 or something, achievement IDs, leaderboard IDs, Google Play Game Services API, alpha testing.

So far, the achievements aren't being unlocked. I wonder if it's because I didn't download the Plop apk from the Play Store, or if the leaderboards and stuff don't work on alpha release? I don't know. But I just submitted the (hopefully finished) game to alpha production. I really wish there won't be any more problems.

EDIT:
Ohhhh myyyy goooooooooooooooood. The achievements aren't being unlocked because I don't have the code for it! For some reason, my brain decided to blank out when writing the method for achievement unlocks. Here it is:

public void unlockAchievement(String achievementId) {
       
}

Yeah it's empty. I need to take a break. It's a good time to take a break anyway. It takes like 5 hours for Google Play store listing to update every time you upload a new apk.

Totally super amazing video of me getting the Lightning Reflex achievement

Plop

It's finished. Get it here:
Plop on Google Play

Working on my second Android game, Plop. I can't seem to stay away from puzzle games so I had to make one myself.

It's pretty much a 2D version of the Rubik's Cube, except with porings.
Shoutout to Ragnarok Online yo. Snipers4lyf.

The gameplay is simple. You can pick regular mode, which is timed, or casual mode. Then you pick a difficulty. Higher difficulty includes more colors and a more random solution.
You are to try to match the plop grid with the solution grid by:
1) moving rows left and right
2) moving columns up and down
The game has 4 levels, with increasing grid size from 3x3 to 6x6. The point of the game is to try to finish all 4 levels in the smallest amount of moves you can.

I did take some screenshots of the progress, so you can kind of see the steps I took to make the game look nice.

I've posted before that you shouldn't really worry about graphics until you have a solid foundation for your gameplay and you're happy with it. So I suggested using placeholder graphics.

Once you have something to work with, you can try making more detailed graphics for your game, as well as a basic layout for how you want your HUD to look.

Then just keep tweaking until you get something you're satisfied with.

I'm not gonna lie. This game is pretty hard, especially for people not inclined to puzzle games. Here's a small video of me playing on hard difficulty.

Video

EDIT:
Complete fail in the video. In the 3x3, I could have just moved the bottom row to the right to solve it and save me two moves. I have no idea what I was doing there with that fancy swivel.
Every move counts. One of the achievements I'm planning on adding is to finish hard mode in under 180 moves. Also global leaderboards. Hopefully I can get that to work.

Polymatch

This is my first Android game submitted to the Google Play Store. Here's a link to the app page:
https://play.google.com/store/apps/details?id=com.neet.polymatch
Or just search it up.

It's a simple reflex game with two modes.
Classic mode is where you drag the filled polygons into the empty polygons to score points. You need 15 points to finish.
Tap mode is where you tap matching polygons to get points. You need 20 for this one.
Both modes are a race against the clock. The objective is to beat it as quickly as possible.

If you do install this, I'm looking for any technical feedback. Mostly I'm looking for any problems regarding screen resolution and aspect ratio. So if it looks any different from:
https://www.youtube.com/watch?v=5VO81K8mduo
just post your phone resolution.

LD29

I originally wasn't intending on joining and Ludum Dare competitions since I've lost interest in them, but for some reason, I really want to join this one. Unfortunately, I'm just starting right now, and there's only 9 hours left. Oh well, if I make it, I make it.

I've thought up an idea very quickly, and started scratching down code structuring on paper. I'll update this post as I get more finished.

Technical stuff:
Language - Java
Framework - LibGDX

Theme is Beneath the Surface.

UPDATE:
Oh noes 6 hours left. Why am I wasting time posting blogs though? Anyway, I actually got some amount of work done. All the game mechanics seem to be in order. Time to make some damn levels.

UPDATE2:
2.5 hours left. I made a few levels. I guess the only thing left is to see how many more levels I can make before time up. Also I forgot music and sfx.

UPDATE3:
Meh, I really needed more time, but I'm happy with what got done.
Links here:
http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=37077

2048

Ever since I got my Android, I haven't really looked at the play store. I figure I might as well see games other people made. The top one on the list is a game called 2048. I downloaded it yesterday, and I couldn't stop playing it. I just had to beat this thing. I can see it's smug face laughing at me. Hell no. Anyway, I did finally beat it after a couple hours. For good measure, I beat it a couple more times.

Then I started thinking about writing a bot that will solve it for me. Apparently, 2048 AI is pretty popular. I decided to try creating a 2048 bot. Problem is, I have no idea if I can make a Java desktop app that can load http://gabrielecirulli.github.io/2048/ and pass keyboard input to it. (anyone?)

So I'm forced to create my own 2048 for the desktop. Oh well. It's a good learning experience for me since this will be my first puzzle game that relies on a 2d array.

I usually split these puzzle game solver bots into two categories: brute force and human strategy. I've made a Sudoku solver before using the strategy method. Unfortunately, I suck at Sudoku, therefore my bot sucks, since it's only as good as I am. Obviously, writing a brute force solver would finish the Sudoku puzzle easily, but where's the fun in that?

Most of what I've seen on 2048 AI uses the brute force method. Minimax, expectimax, etc. Basically, searching through possible scenarios for the best evaluation. I'm going to go the other method. I will impart my limited knowledge to my bot, and hopefully this thing will be able to solve it like I would.

UPDATE:
Ahhhahahaha . I can't stop working on my damn bot. Again, it doesn't use any brute force recursive searching. It's a decision bot, and it makes decisions that I would make. I've managed to get my bot to create the damn 2048 tile. Average score is ~6000. Highest score is ~28000. Wins 5% of the time.

My Bot Doing Work

 It still doesn't make the exact same choices I would make, since I haven't put all of my thought process into it yet, but it's enough to actually beat the game. My personal best is ~58000, close enough. Hell yeah

Tips: Placeholder Graphics

If you want to speed up development, ignore graphics. In the early stages, you can draw boxes instead to get the idea of relative sprite sizes. Once you develop more of the mechanics, you can start using low quality images. Only after the game is good to go should you start working on that sweet game art.

The purpose of this is so that if you happen to hit a road block, whether some game mechanic isn't good, or you want to change the dimensions of some stuff, you don't have to redo any art, because hopefully, you haven't created any of that yet. It's a lot easier to replace a box than it is to replace a drawing.

It will look bland, but just use your imagination. You gotta visualize the final product.

5-Star Rush

I'm putting Psytech on the back burner for now because I'm looking to make my first Android game.

Being a pixel art game, it truly is a pain in the ass trying to make images for multiple resolutions. Since Android has no set standard, I'm out of luck there (I really love pixel art). I've decided to stick to a small virtual width and height (240x400) and just scale up to fit higher resolutions. This is so it hopefully doesn't look too bad using nearest mag filter to keep that pixel art feel.

EDIT:
The real problem is the different aspect ratios. It looks like the most common ones are 1.6, 1.666 (the one this game is currently fit for), 1.777, and 1.78 (lol?). Okay so if I fix the 400px height, then the widths are 250px for 1.6, 240px for 1.666, and 225px for 1.777 and 1.78. If I don't want to have any black bars, I should go with the max size of 250x400 for the background image, and cut down the actual game "play area" to the smallest 225x400. Then I make sure to keep the camera centered so higher ratios crop out the extra background space. That would probably work since it's only a few extra background pixels. (sorry tablets, you're going to have to go with an aspect ratio altering stretch). I'm getting the Galaxy S4, which is 1920x1080 (1.777), so it'll be that perfect fit for 225x400 with no extra background space.

Oh, and I just tried LibGDX's texture packer. This is probably the niftiest tool ever created. I don't know why I haven't tried using it before. One pack per screen would be excellent. Mr. Aurelien Ribon has created a very handy GUI for the texture packer. You can find it here:
http://www.aurelienribon.com/blog/2012/06/texturepacker-gui-support-for-multiple-packs/

I've been thinking about this game for a long time, so I've already scribbled out all the game mechanics on paper. It's just a matter of translating it to code.

Psytech - dev 2

So a checklist of things I have finished since dev 1:
- player level, exp, skill points
- skill tree
- skill prerequisites
- using skills
- skill cooldown
- skill effects (buffs)
- skill HUD

I still need to finish up the HUD. The last things I need are a shield bar, current weapon, and some player stuff.

I decided to try LibGDX's particle editor for explosions. It is surprisingly difficult to get a good looking effect going, but once you tweak it just right, it can look pretty damn awesome.

The goal now is to finish the HUD, and make a skill tree menu where you can upgrade your skills via skill points.
Might as well make a title screen while I'm at it.

Also, wow I never posted what I was using. This is a LibGDX desktop game using Box2D, Box2DLights and Tiled maps.

Psytech - dev 1

I don't really have any more tutorial ideas, so for now, I'm just sticking to making games. My current project is a top-down shooter. It's in very early stages. I've already thought up most of the game mechanics, but have yet to implement them.

The game is called Psytech because apparently people in the future have some kind of psychic abilities, although weak. Psytechs are soldiers with strong psychic abilities amplified by technology.

This is a sort of single player horde mode, where you have to survive a certain number of waves to finish a match. You always start out at level 1, and gain exp by killing enemies. Every level up boosts your stats. You may also earn skill points.

The skills have a tree structure, so you need to plan out which path down the skill tree to take. You can focus on passive abilities to boost weapon damage, or spec for offensive Psykinetic abilities. Weapons and their attachments are also suited to different play styles.

Like I said, every match starts the player at level 1. However, there is also persistent rank. This is the exp you gain after a match. Higher rank means more weapons and attachments. I haven't fully thought this out yet so I'm not sure. This is kinda far into the future.

My next goal is to get the skill system working.

Block Bunny

This is a tutorial game for getting familiar with Box2D basics and LibGDX's Tiled API.

The point of the game is to get the bunny to the end by jumping and switching block colors. You can only run over blocks that are the same color you currently have selected in the top left.
Press Z to jump, and X to change color.
I only put 5 maps in there, but you can make your own. To make maps, you need three tile layers named "red", "green", and "blue" and two object layers named "crystals" and "spikes". Put all your red/green/blocks in the appropriate layer. You can simply place any object in the crystals and spikes layer to add them. The only thing I grab from these objects is their position.

You can watch the tutorial if you want:
https://www.youtube.com/watch?v=85A1w1iD2oA

Game:
https://dl.dropboxusercontent.com/u/59779278/libgdxtutorials/Block%20Bunny/Block%20Bunny%20Game.rar

Source code:
https://dl.dropboxusercontent.com/u/59779278/libgdxtutorials/Block%20Bunny/Block%20Bunny%20Full.rar

LibGDX + Box2D + Tiled

Well, it's been a while. I just finished the LibGDX Asteroids game.

I probably won't be going back to Java 2D. I said that I would try to get a LibGDX Box2D and Tiled tutorial up and running, but of course, before I start my tutorials, I need to actually have a game for it. I'm still in the process of figuring out the best way to integrate Box2D and Tiled maps.

The game I'm going to use for this future tutorial is this simple, get-to-the-end-of-the-level, platformer: GIF 1.6MB

Some of the things I want to cover in the tutorial are:
- how to use the Tiled software
- how to use the LibGDX Tiled API to read the Tiled maps
- how to use Box2D (this is the big one)
---- adding bodies to the world
---- creating and customizing fixtures
---- converting to Box2D units
---- filter collision
---- contact listeners

I got most of the main game mechanics already finished. I should have the game done soon, or at least enough of it done to start recording the tutorial.

Camera Scrolling

This is the second part of the TileMap in depth explanation.

A preface first: I want to say that in retrospect, I should have probably created a Camera class rather than rely on the TileMap to be the camera. The scrolling concept remains the same though.

I just remembered, I created an image explanation for scrolling.

The basic concept is that there are two different coordinates: the game coordinates, and the screen coordinates. Whenever I draw to the screen, I first have to translate everything over from game position to screen position.

So instead of drawing at say:

g.drawImage(image, x, y, null);

I draw at:

g.drawImage(image, x - cameraX, y - cameraY, null);  

If anyone's ever done OpenGL, it's similar to applying the (model)view matrix to transform game coordinates to camera space.

TileMap in depth

I didn't really explain how my TileMap class works, so I'll go into more detail here. If you want to follow along, I'm using the TileMap class from: https://dl.dropboxusercontent.com/u/59779278/Dragon%20Tale%20Tutorial%20P02.rar

First, I'll go over the fields.

// position
private double x;
private double y;

This is self-explanatory. These two variables indicate the top left corner of the TileMap. As the player moves to the right, the TileMap moves to the left, ie: x decreases.

// bounds
private int xmin;
private int ymin;
private int xmax;
private int ymax; 

These are the minimum and maximum bounds of the map. The position (x, y) cannot go further than these limits. This prevents the "camera" from scrolling past the edges of the TileMap.

private double tween;

This is a factor between 0 and 1 that indicates the speed in which the TileMap's position changes. A tween of 1 means that the TileMap will move to a given position instantly, where as a tween of 0.1 means that the TileMap will move 10% towards a given position. This gives a smoother scrolling effect.

// map
rivate int map[][];
private int tileSize;
private int numRows;
private int numCols;
private int width;
private int height;

The map is simply a 2d array of integers, where each integer represents a tile from the tileset. The tileSize is the size of a single tile in pixels. numRows and numCols are the number of rows and columns of the map. width and height are the dimensions of the map in pixels.

// tileset
private BufferedImage tileset;
private int numTilesAcross;
private Tile[][] tiles;

The tileset is the entire tileset image. From that, I read each individual tile subimage, and store it in the tiles array. The numTilesAcross is used to calculate the "id number" of the tiles.

// drawing
private int rowOffset;
private int colOffset;
private int numRowsToDraw;
private int numColsToDraw;

These are for drawing. They indicate the row and column that drawing should start, and how many rows and columns to draw. This is so that only part of the TileMap on the screen gets drawn, rather than the entire TileMap. (With respect to drawing, these variables aren't important because the Graphics object has a device clip, which prevents any drawing from happening outside of the Graphics' device's visible region. But from a complexity point of view, it does reduce the time from O(n^2).)

 The constructor is simple. It sets the tileSize, the tween, and the number of rows and columns to draw.

The loadTiles(String s) method reads in the tileset and cuts out each individual tile to put into the tiles array. My TileMap class isn't very scalar, in that it has a specific way of handling tilesets. The tileset image must always have 2 rows of tiles. The top row are all the non-blocked tiles, and the bottom row are all the blocked tiles.

 The loadMap(String s) methods fills in all the field variables under // map. The map file contains the number of rows and columns of the map, and the map itself, a 2d array of integers. I get the numRows, numCols, width, height, and bounds of the map.

Then there are a few getters and setters. Simple.

Next is the setPosition(double x, double y) method. This method tries to move the TileMap's (x, y) position to the given destination (x, y). This is where tween kicks in to smoothly move the TileMap to the destination. Then I make sure the position doesn't go past the bounds using fixBounds() and then calculate the row and column offsets to know where to start drawing.

The last thing is the draw(Graphics2D g) method. This is a straight forward 2d array loop. I loop through the map array starting with the rowOffset and colOffset, up to the specified numRowsToDraw and numColsToDraw. Now remember the map array contains integers of tileset "id numbers." I have to calculate, say, the id number 24 into row 2 column 4 (see tileset image above.) Since I know the numTilesAcross of the tileset, I can easily translate the id number using:

 int idNumber = map[row][col];
int translatedRow = idNumber / numTilesAcross;
int translatedCol = idNumber % numTilesAcross;

Then I just draw the given tile at the correct position and that's it. 

Hopefully, this answers some questions about the TileMap. I'll make a separate post about the "camera" scrolling.

State Based AI

I want to explain a little bit about FSM based AI. The concept is simple: an AI has a set of behaviors, and acts on a behavior depending on certain conditions. The enemies in Cranky Rampage all use this method.

The Sentry is your basic cannon fodder enemy. It can be in any of three states:

private int state;
private final int MOVING_TO_PLAYER = 0;
private final int SHOOTING = 1;
private final int COOLDOWN = 2;

When in the MOVING_TO_PLAYER state, the Sentry will simply try to get closer to the player. Once it reaches a certain proximity, it will move on to the SHOOTING state. Here, it will stop moving and fire a bullet. Then it will move into the COOLDOWN state where it will wait for some time. I have to find the edges in this FSM, meaning I have to find which states can transition to which other states.

MOVING_TO_PLAYER transitions to SHOOTING, SHOOTING transitions to COOLDOWN, and COOLDOWN can either go back to MOVING_TO_PLAYER or SHOOTING. So here's our list of edges for the graph:

MOVING_TO_PLAYER --> SHOOTING : if within range
SHOOTING --> COOLDOWN
COOLDOWN --> MOVING_TO_PLAYER : if out of range
COOLDOWN --> SHOOTING : if within range

Now coding the Sentry's AI is simple.

if(state == MOVING_TO_PLAYER) {
    if(player.getx() < x) {
        left = true;
        right = false;
    }
    else if(player.getx() > x) {
        left = false;
        right = true;
    }
    if(Math.abs(player.getx() - x) < range) {
        state == SHOOTING;
    }
}
else if(state == SHOOTING) {
    left = right = false;
    GameObjectFactory.createBullet(...);
    state = COOLDOWN;
}
else if(state == COOLDOWN) {
    timer++;
    if(timer > time) {
        timer = 0;
        if(Math.abs(player.getx() - x) < range) {
            state = SHOOTING;
        }
        else {
            state = MOVING_TO_PLAYER;
        }
    }
}

This is an easy way to give your NPCs some behavior. State based AI is simple to implement and can be effective.