I'm ditching the dark-art idea. The game should be fun and bright. I wanted to draw a game with pixel art for some time, and I guess the time is now. Here's my idea for the lead protagonist:
His passions are driving a spaceship and listening to heavy metal music. I need to work on his legs and...
...well, everything below the head. :)
If you got some suggestions, let me know.
Feedback & Share Bigosaur, 2014-11-20I'm experimenting with different art for the game. Here's the dark version.
The light version does not look that good, but plays much better because brick types are distinct enough and it's clear what you can do. Maybe I should look for a third art style, something like Braid?
I'm not sure what to do next. I got a lot of puzzles prepared but don't want to waste time making the, just to have to redo everything if I decide to change the art style.
Feedback & Share Bigosaur, 2014-11-19Starting this year I wanted to develop some applications for iPhone and iPad, so I got a Mac Mini. My other computers are 7+ years old, so I couldn't run any recent games. Over the years I accumulated games via Humble Indie Bundles and I finally got to play them. I'm very impressed with Braid, VVVVVV and Limbo.
A few days ago I realized that I wanted to play more puzzle platformers like those, but there aren't many around. So I decided to build one. The idea is to take from each game the element I like:
The main gripe I have with all of those games is that they were too short (ok, Braid maybe not so, because puzzles were hard). I plan to make A LOT of levels in my game AND I will make a level editor with “cloud save”, so you'll be able to upload and share levels on game's website. Other players will be able download and rate the levels. If players really start contributing a lot of levels, I'll pick the best ones, pack them together to continue the main games story in a nice way and release as DLC package.
Because of this, editing levels should be fun. My plan is to mix editing and play mode, so you can play the level as you edit it. Just drag the player, walls, boxes around. You will be able to freeze the enemies and such, but editing should be as fun as playing.
Also, my kids are begging me for multiplayer mode, so it might have separate local co-op puzzles for 2-3 players. Joystick/Controller support is also a must as I plan this to run on desktop computers (Windows, Linux, Mac).
Feedback & Share Bigosaur, 2014-11-05It's all done. Here's a video showing gameplay. It has a mouse pointer because I recorded it on a desktop computer, but it looks exactly the same on Android tablets:
Grab it in Google Play Store:
https://play.google.com/store/apps/details?id=com.bigosaur.gos.android
Feedback & Share Bigosaur, 2014-10-28
The second beta version is ready for testing. Everything should work, except that it lacks music in the main menu screen (should be coming soon). Please test and tell me how you like it and if you think something needs to be improved.
If you installed the first beta, please remove it from your Android. The application package name has changed, so Google is treating this new one as a separate application and won't update the game. You have to install this one as if it was a completely different game. Sorry for the inconvenience.
Feedback & Share Bigosaur, 2014-10-23Well, it turns out creating AI wasn't simple at all, but I finally finished it. In the meantime, Voyna created a great music piece to play in the background during the battle. I also had to switch to latest libGDX because I couldn't get the AdMob to work on the old one. Of course, that would be too simple. The new libGDX wouldn't work on my old Slackware, so I installed Ubuntu 14.04 and set up everything there. There was a problem with my old Intel i915 graphic card which supports OpenGL 2.0, but Eclipse/libGDX failed to recognize that. I fixed that with by setting env. variable:
MESA_GL_VERSION_OVERRIDE=2.0 ./eclipse
I also got some weird problems like Eclipse crashing whenever I used autocomplete. I fixed that by adding this to eclipse.ini:
-Dorg.eclipse.swt.browser.DefaultType=mozilla
The tooltips were also completely invisible (black text on black background). Apparently Eclipse only honors the system background color. I fixed that with gnome-color-chooser. At first I changed the color to a bright one, but then tooltips became unreadable in Firefox (while text on white background). Go figure. One would expect that there are some Ubuntu developers who use both Eclipse and Firefox. In the end I used a shade of gray to get some contrast against both white and black text.
I need to do a lot of testing now. First beta should be out tomorrow.
Feedback & Share Bigosaur, 2014-10-22I finished conversion to landscape mode and implemented the attack icons and animations. For most attacks the cards just move and shake a little bit. Ranged units have special animations, Zeus fires thunderbolts and Catapult throws rocks at enemies. I added the damage numbers to attack icons and it's now visible which type of attack deals the most damage.
I also created some nice icons for unit Energy (heart) and also Attack (sword) and Defense (shield). Those show up when the default unit values are modified (by artifact or an ally that stands next to them). This makes the game fluid to play, as you don't have to keep do the calculations manually all the time.
What's left to do: Turn indicator graphics, Sound effects, Music (I'm going to get help from a musician), AdMob integration. Initially the game was supposed to be only a two-player game, but now I'm thinking about single player mode as well. Writing good AI for this strategy might get complicated, but it's worth a shot. There's still enough time before the end of October.
Feedback & Share Bigosaur, 2014-10-16As I switched to landscape mode, I started to create mirror-flipped images of unit cards using the -flop option in ImageMagic in one of the card-generating steps. As the script rolled on for some time, it hit me that this would increase the amount of graphics a lot. I got worried about the size of the final .apk file. First time since I started the project I decided to check.
I created a package containing only the lowest (800x480) and highest (2560x1600) resolution images. It's 106MB!
I need to add 4 intermediate resolutions, so I'm looking at 300+ MB for the final .apk. I searched the docs and found that the limit is 50MB and rest has to be provided as a separate package. Or, you can distribute two different .apk files. I didn't like any of those. I hate when you download an Android game, and then you have to wait for it to download hundreds of megabytes more. I needed a new approach.
I searched the Internet. Most advices are about packing your code using compressor/obfuscator programs. But the gains are really negligible. Then one thing caught my eye: using JPEG for textures. I'm using TextureAtlas to pack everything automatically, but I could separate the images with and those without transparent areas and pack them separately as PNG or JPG.
The problem is that 90% or the graphics need transparency. In this particular case the main problem are the card images, which have rounded corners. And then I got this great idea: separate the card image into frame and contents. There are only four card types in the game (one for each faction and gold one for the items), and all cards of the same type share the same frame. The inside of the card is different for each one, but it does not require transparency. Instead of packing 126 cards into PNG texture, I would pack 126 cards into JPG texture plus 4 frames into PNG.
As I tried this, I got some weird clipping artifacts in the JPG texture, probably because I turned off the 2-pixel padding. So, instead of pixel precise cropping, I increased part of the graphics that gets copied to JPG so that there is some overlap. When staging the images, make sure the jpg one is drawn first and PNG frame over it. The part that overlays will covers the bad edge pixels.
BTW, by “staging” I mean placing the Images into libGDX Stage. To make the code simpler, I created a nice CardImage class (descended from Group) to handle drawing transparently. This Group contains the center of the card from JPG texture and then positions the frame from PNG texture over that.
This saved A LOT, but I got so concerned about the size that I wanted to do something about flipping as well. I researched if I could only flip a part of the image. It's possible using AtlasRegion.flip() function. But I also had the problem that I didn't want to flip the whole image. The textual part should remain the same and only the unit graphics should be mirrored. To do this, after calling flip(true,false) I used setRegionY and setRegionHeight to reduce the flipped region size. Using the flipped region I created another Image and added it to the CardImage group. At runtime, I simply show or hide this image when I need to unit to face left or right.
New .apk file with the same content is now only 12MB. A 88% save. Once I add all the other resolutions, I estimate the final .apk to be about 40MB if all goes as planned. Compare this with 300MB+ I expected at the beginning.
Beside all the other advice you might find on the web (compressing the code, etc.), add these three:
UPDATE Oct 28: The final .apk with all the graphics, music and sound effects is 42MB:
https://play.google.com/store/apps/details?id=com.bigosaur.gos.android
Mission accomplished :)
Feedback & Share Bigosaur, 2014-10-14Just like the last time, I decided that I have to change the screen orientation mid-project. This time from portrait into landscape. Here are the reasons:
Cons:
To conclude: unless the game is meant to be played like Flappy Bird (using the same hand that holds the phone and having only one command: “tap anywhere”) use the LANDSCAPE orientation.
Feedback & Share Bigosaur, 2014-10-12