Whisky Neat Games DevBlog Number 1
In which I compile a mass of tweets about the development process over the past 8 months:

5 Oct
I have decided that 'Whisky Neat Games' will be the name of my games studio. If anybody steals this I will cut them.

12 Oct
Real progress made in figuring out how to organize the data and populate it for beginner android game.

Which is to say that I created a custom object class, initialized it properly, and populated the data with a random number generator.

Things still to figure out: preventing a variable amount of duplicate numbers based on the number generated. The actual gameplay.

And eventually netcode. But initially I think it will be a local multiplayer tablet game only.

13 Oct
Figured out how to do the deck tracking, hooray! Other gamey things need to be figured out, but actual progress being made is good.

14 Oct
Made a change to the data structure that I /think/ should let me have the cards various effects work. #stilltryingtomakeagame

14 Oct
Can successfully launch new activity and assign card names to buttons! Need to figure out card effects and linking the button actions.

15 Oct
Found a way to iterate through the players that should've been perfectly fucking obvious. Didn't realize you could array a custom class.

16 Oct
Almost have the primary game loop all set up for two players. Once that's done it should only require minor tweaks for 3-6 players.

Of course my code is fairly Rube Goldberg-ian.

18 Oct
Today's progress on #myfirstAndroidgame: basic UI for the War cards is able to spawn and populate itself. Actual war still to come.

19 Oct
The weird thing about coding a game is that what makes me happy is not when the game works, but rather watching all the variables tick over the way they're supposed to when running debug.

Also coming up with clever names for the variables. Like declarewar is a function that launches the war activity, and WarWereDeclared is the container for the data that the war activity needs from the activity that launched it.

19 Oct
Today's #myfirstAndroidgame update: War activity end-to-end works.

Need to code in the counter cards and then two player mode will be pretty much done.

3-6 player mode should only require minor tweaking of the two player code to make work. After that I just have to make it pretty. (Note: This was an INCREDIBLY naive thought)

20 Oct
#myfirstAndroidgame update: All basic gameplay elements of War work. Handful of additional cards to code, then pretty-making.

21 Oct
Today's #myfirstAndroidgame update: all the cards are coded. Reworked a bit of code so it'll work for 3+ players.

Had a thought for checking end-game condition for 3+ players, but since Java doesn't allow dynamic arrays it won't work.

I'll figure out the two player end-game code tomorrow and then extrapolate 3+ players from there.

22 Oct
#myfirstAndroidgame update: Two player game end-to-end is go. Some interface tweaks went in, and I need to make additional ones.

Tomorrow or later this week, I will finally start drawing the cards and background images.

Then I need to figure out animation.

23 Oct
Some animations are in for #myfirstAndroidgame. If you long press on the cards, they will scale up and then scale back down on release.

The process of learning how to do this has given me a pretty good idea for how to handle target selection in 3+ player games.

That idea being: the main background image will be a map, and you tap on the location of who you want to play a card on to target them.

When tapped, their village icon will scale up slightly.

potential problems: changing your mind about your target. Scaling the icon back down at end of turn.

Also: image layers getting screwy, since I'm planning on additional icons appearing for the improvements.

I also feel like the onStart is getting out of hand, but I don't know where else to put some of this code.

25 Oct
Finally broke down and flashed CyanogenMod 9 on my Nook Color.

#myfirstAndroidgame uses an API that only works with Android 3.0 and up, and as it's meant for tablet devices and the only tablet I have is the Nook, I need it to be able to run the game so I can test it.

The emulator built into the SDK only goes so far.

25 Oct
Drawing tunnels is hard

Seriously, look at this non-Euclidean nightmare #Iamnotgoodatdrawing http://pic.twitter.com/ePb1WMdS

30 Oct
#myfirstAndroidgame update: having grown bored with drawing the cards (because I'm not very good at drawing), I have begun coding the 3-6 player game.

Also upgraded my Nook Color and my phone to Jelly Bean 4.1

I'm so bad at drawing that I'm tempted to fire up Blender and just make models and do renders for the cards and tweak the renders in post.

5 Nov
#myfirstAndroidgame update: place holder art for all the cards is in, animation for the targeting map is in for 2 player game.

Still need to draw the map, but it's pretty slick watching the thing rotate and zoom in when the game starts.

Also need to set the animation for 3-, 4-, and 5-player games.

And I'm still kind of blanking on the best way to remove players from 3-6 player games when they run out of population.

7 Nov
So far I am finding Android development shockingly easy. Hit a roadbump in the UI design due to different tablet screen sizes

And the fix was as simple as creating different layout folders named for the screen resolutions and putting the different xml files for the layouts in those folders. No fancy coding necessary.

Which means it'll be a lot easier to set up things if/when I get to the phone compatible version with local wifi multiplayer.

8 Nov
In #myfirstAndroidgame news: primary gameplay loop for 3-6 players is in. Still need to figure killing players and endgame out.

Also need to add some conditional stuff to keep a person from declaring war on themselves, and handling cards that don't need targets.

And I need to put in the map animations. Also tempted to just move the two player game into the 3+ player activity.

Then draw the rest of the cards, the map, the title screen, the two background images for the main game, the background for War, and the opening Whisky Neat Games animation.

THEN get an Android developer account (Note: Done!), an AdMob account, split the versions for a free version with ads and a paid no-ads version, and upload them to the Google Play market and watch as I don't actually make any money.

Once that's done I can try to do the phone compatible local wi-fi multiplayer version. Or break down and get an entry level QA job.

12 Nov
Ran into a display size disparity issue on #myfirstAndroidgame that required actual coding to fix, and of course, THAT code is causing some other weirdness.

15 Nov
Oof. Going through weird code contortions (code-tortions?) to avoid re-writing large chunks of code, even though I know just re-writing those chunks will make for cleaner, more efficient code.

Just trying not to fix things that are more or less un-broken as is.

16 Nov
3+ player game end to end works for realsies now. Some animations, some additional game logic and lots of artwork and I'm pretty much done. (Note: STILL NAIVE)

Oh, and credits. I should probably put in credits somewhere, if only to credit the open source font I'm using.

21 Nov
Nook HD+ bought. Between it and the Nook Color I should have the necessary screen sizes for testing #myfirstAndroidgame

After a couple of hours screwing about to get ADB working on the nook HD+ I am finally able to test #myfirstAndroidgame on it, and immediately discover that I am going to have to do a whole tonne of shit to make the animations work properly on that display because PropertyAnimate translates the ints as pixels instead of dps so nothing lines up any more.

I have to put in a conditional for the card scaling animation, another one for scaling the board at the beginning of the match, etc.

28 Nov
Realized I could make my code a bit more efficient by making one listener and assigning it to multiple objects instead of creating listeners for each object that all did exactly the same thing.

Brings an additional benefit of making the code easier to navigate since I don't have to scroll through a billion listeners any more.

4 Dec
Code for #myfirstAndroidgame is pretty much done! YAY! (Note: I was lying to myself) Now I just need to do the art. Boo!

6 Dec
That moment where you stay up later than intended because you suddenly realized a code change that would work to do a thing you wanted.

10 Dec
So annoyed with myself right now. Spent the past five hours doing RIDICULOUS shit to fix a bug that was being caused by one line of code.

I can't figure out WHY that one line of code was causing it, since it was in a different activity than the one that had the crash.

Oh, and that line of code? Setting the activity to full screen. Made it crash on the Nook HD+, but ran fine on the emulator.

Crash was because the system was killing Activity 2 when Activity 3 launched.

But Activity 3 ends and goes back to Activity 2, and does a bunch of stuff with Activity 2's data that no longer existed.

Why Activity 1 being full screen makes it kill Activity 2 when Activity 3 launches, I HAVE NO FUCKING IDEA.

It worked fine on the Android emulator and the CM10 Nook Color (until I set the 'kill activities as soon as they're gone option to on).

2 Jan
Have decided that I should be using vector graphics instead of bitmaps for the images in the game.

So now I have to learn to use Inkscape, convert the cards that I've already drawn, and figure out how to use the svg-android library.


Thankfully, since the cards that I'm keeping are all hard black and white line art, Inkscape's tracing tool works really well on them.

3 Jan
After several hours of messing around, I have decided that using vector graphics instead of bitmaps in the game is too fucking complicated

Drawables created using svg-android don't scale to the views (unless I draw them directly to canvas, which is WAY too complicated)

It also has all sorts of weird problems with SVG files made with Inkscape, and like hell I'm paying $600 for Illustrator.

In short: too much weird shit I have to do to make vectors work, not worth the effort. At least not with this version.

Extremely frustrated by this vector graphics thing. I really really want to make it work, but I feel like I'm banging my head against a wall

I think I could almost get it to work for one thing, but that method won't work for a bunch of other stuff.

Another six hours of trying to figure out how to use vector graphics for naught. #justgiveupalready

Why am I trying so hard to get this shit sorted out? Because certain cards are pretty much illegible regardless of screen size and vectors should be able to sort that out. And I can get vector graphics to display at their original sizes but I can't for the life of me figure out how to rescale the damn things, because for some reason that's not built into the API.

And poking through the library, I think it might be really easy to insert a 'replace width and height' function.

Why a 'replace color' function took priority over a 'resize' function, I have no idea. I would think a person would be more likely to want to resize their svgs dynamically than replace a color within them dynamically.

Several more hours wasted banging my head against vector graphics. Tweaked the library a bit ended up with a way to get shitty looking re-scaled bitmaps out of SVGs. Not what I want

I have resorted to asking for help at Stack Overflow and inviting abuse for my n00bness.

5 Jan
YEEEESSSSSS!!!!! Finally cracked the vector resizing! It's half past 4 in the morning but it finally fucking works!

Answer was staring me in the face, just had to change a couple of lines in the resize function that I didn't like.

The scaled vector drawings look SO MUCH BETTER than the down and up-sized PNGs I was using.

Just have to convert the rest of the images to SVGs and re-write some code so the SVGs will get assigned to the cards instead of the PNGs. But right now: something to drink and then bed.

5 Jan
The best thing about switching to SVGs instead of PNGs is that editing an SVG is much more akin to 3D modelling than drawing.

I'm shit at drawing, but not awful at 3D modelling, so the images look way better.

Observe: Before http://pic.twitter.com/767YKnN4

After http://pic.twitter.com/QGxqNuHU

7 Jan
Only took me three days, but I finally got the card with lots of intricate brickwork converted to an SVG that the Android SVG Parser doesn't convert into vomit.

9 Jan
Another card converted to SVG. I think I've got the process pretty much down. Annoyed at having to swap between Inkscape and GIMP because Inkscape frequently fucks up the formatting.

16 Jan
Really wishing I could afford to commission an artist to draw these cards for me.

17 Jan
You know what I hate drawing more than anything else in the world? Boats. All curvy lines and wonky perspective.

18 Jan
Have decided to attempt converting some of the Dance of Death woodcuts to vector files for the art for some cards, since they were the art style that the original game was cribbing from anyway. First one converted perfectly, but with WAY too many nodes. >14,000. Takes too long for a tablet to process that to resize them.

They're also super busy, which makes it harder to tell at a glance what card it is when it's small sized.

F'rinstance: http://pic.twitter.com/ihkI8WAf

Now imagine that at 60x84, and trying to figure out what the hell it is. Bad interface design, that.

So I'm back to trying to figure out the best way to do these things with my own meagre drawing skills.

I might be able to trace over some of them, but it'll be time consuming.

It's starting to feel like I'm not going to be able to get this thing done by the end of the month.

18 Jan
Threw together a bunch of placeholder vector cards just so I could re-work the code for dealing the cards and such.

The game is now slow as fuck when running on the Nook Color. The same Nook Color that runs GTAIII okay.

I think I need to learn multi-threading.

Of course I'm doing silly things like re-processing drawables that have already been processed, but the only way I can think of to get around that is to do all of the cards right at the beginning and throw them in an array, .but I'm pretty sure that would result in a load time in excess of a minute when starting the game. It's already >15 secs doing the background image and five cards at game start.

19 Jan
Attempts at multithreading have not brought an appreciable performance gain. Neither has the 'all the cards at once' method.

Vectors are apparently just way more CPU intensive than I was expecting.

I don't think I can hardware accelerate the parser. Only other way I could potentially speed it up would be to switch rendering to OpenGL.

Which I am not going to do because that will take way too damn long to learn.

Or I suppose I could convert the Drawables to Bitmaps, but then they'll scale for shit, which would defeat the whole purpose.

A bit of additional research and I think I really should learn OpenGL on Android.

Or maybe I don't. drawPicture() can't be hardware accelerated, so there's no way to speed up the vector processing, but I found a way to tweak the hardware acceleration on the views to make the animations not so herky-jerky, and have thought of a way I might be able to reduce the redundant vector processing.

21 Jan
Turns out processing all the cards at the top of the game instead of on a per-turn basis was the way to go. Takes about 11 secs on the NC.

Though that number will go up as I add final art for more cards.

Also managed to sort out the framerate issues on the card scaling animations. Doesn't work with the big map animation, alas.

Would really like that one not to be as herky jerky as it is, but short of turning that into an OpenGL window, it's not to be.

21 Jan
Bah! I've kind of figured out multi-threaded coding, but it causes more problems than solutions for me right now.

If I throw the vector processing onto a background thread, the dealcards function hits before there are drawables for the cards, so, if each player is lucky, they might get a card or two that they can play, but they'll never get the rest of their cards.

I might be able to tweak the card dealing function so it won't deal cards that haven't been drawn, but I suspect that will result in everybody's first hand always being the same.

21 Jan
Tried adding the logic that would prevent a card from dealing if the drawable wasn't present when building them on a background thread, and got exactly the result I was expecting: same cards on the first hand every time.

Tried adjusting it so that instead of 1 background thread iterating through the whole array a new thread would spawn for each item:

Made it vary slightly, but still 99% the same cards for the first hand every time.

So I'm stuck with the whole game basically freezing while the drawables are generated, which is disappointing.

What I COULD do (and this might not work) is put the drawable processing in the background, and then have some sort of spinny animation on a while loop in the foreground. Actually, that would probably work okay.

22 Jan
My loading animation idea isn't working, and I can't figure out why.

Figured it out! I ARE SMARTY CLEVER MAN. Now I have to copy/paste a shit tonne of code over to the twoplayergame activity.

And then I guess I have to work on the art again. Blergh.

23 Jan
Have decided that #myfirstAndroidgame is essentially at Beta, and am uploading a video of me mumbling through a walkthrough of the game.

And here is the video of me awkwardly mumbling through me demonstrating the sort of beta of my game: http://youtu.be/81UdSTtS68A

25 Jan
Just realized that now that I have a loading animation, I probably could just go ahead and use the Dance of Death engravings for the cards.

15th Century engravings are in the public domain, right?

Though I'd still be stuck with the 'too busy to be distinctive at the smaller size' problem for a lot of them.

29 Jan
As suspected, vectors made from the Hans Holbein Dance of Death engravings are too complicated to use in #myfirstAndroidgame

Tried converting a couple and dropping them in, and it took upwards of ten minutes to load on the Nook Color. Over a minute on the HD+

Back to trying to draw the cards my own damn self.

1 Feb
Hooked up some pictures for the dice, since dice are something I CAN draw.

7 Feb
Spot survey: Tentacle Monster or Tree? #fb http://pic.twitter.com/GLUFNiFs

And then I got a job that takes up most of my time...

15 May
Reading the documentation for Google Play Games makes me unreasonably excited about what it could mean for #myfirstAndroidgame.

18 May
Whelp, I am now an officially registered Google Play developer. Whisky Neat Games is a thing that is me.

27 May
Done some programming today, hooray! made some changes to #myfirstAndroidgame.

Made it so the longpress to zoom in on the cards thing works for cards that can't be played, so now the player will be able to know why.

Trying to figure out a way to do a swipe down to discard, but it's much more difficult than expected.

The first attempt at a motion listener for it ended up overriding the existing long press listener, so that won't work.

I'm thinking of doing some more looking in to OnDrag, which might let me create a discard pile.

As well as re-do the whole targetting system to make it more card-like by dragging the cards on to your target instead of clicking target and then clicking the card you want to play on them.

Also need to figure out Google Play Games for the online multiplayer.

1 Jun
In figuring out how to do a discarder function, I may have stumbled on a way that I can get rid of six functions and five listeners, and have one listener and one function for handling playing the individual cards, which should result in a lot less redundant code
Shared publiclyView activity