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.