Patch notes

Hello!

Are you enjoying / have you enjoyed Apple Jack 2? It seems to have gone down well, all in all, but one or two issues have cropped up for people playing the game. To that end I've released a patch which makes it more stable and fair to play:

- Fixed crash bug that sometimes occurred when sliding down a hole.
- Adjusted level 2 to work better for people with manky controllers.
- Also adjusted levels 8, 24, 50 & 51 for various reasons..
- Made the saw blade hit-circle more forgiving.
- Stopped the slight stuttering just before a new song plays.
- Added coin, combo and death stats to the pause menu.
- Made spikes speed up during rewind (purely cosmetic).
- Fixed bug that zoomed in to intro art on second viewing.

Nothing earth shattering, but the crash bug especially was annoying. You'll be prompted to download the patch when you next play the game and all your old save data will still work fine. Enjoy!

Apple Jack 2 soundtrack available now!

As excellent and life-affirming as Apple Jack 2 is, you can't play it all the time.

Sometimes you need to go to the toilet.

Sometimes you need to go to work.

Sometimes you have to heave your body upstairs to have laboured, joyless sex with your boyfriend / girlfriend / wife / husband.

None of these things will ever be as good as playing Apple Jack 2, clearly. But with the new Apple Jack 2 soundtrack album, courtesy of This Eden, you can enjoy the acclaimed music of the game at any time, day or night!

What's more, you only have to pay what you think it's worth! Get it here:


http://thiseden.bandcamp.com/album/apple-jack-2-ost


They also have a self-titled proper album available, so buy that too while you're at it.

Apple Jack 2 responses

Hello!

I've had lots of positive (and one negative) reaction to the game so far, so I thought I'd use this post drop a few links on yo' asses.

First, Indiegames.com found the intro very funny and used words such as 'interesting' and 'creative' to describe the game itself. It should probably be pointed out that they only played the demo though, the cheap sods. Read it here

Adam Pettifer writes for a group of websites under the Your Local Guardian banner, and liked it a great deal, saying "I don’t remember enjoying any 2D platformer quite this much, not Sonic 1 or 2, not Super Mario World on the SNES, nothing.". Slightly over the top possibly, but it's great to read something like that! Read it here

Indie Gamer Chick wasn't a fan of Apple Jack 1, so I wasn't expecting a great deal of gushing praise from her this time around. And so it proved to be. She preferred it to the first game, but ultimately she doesn't much like difficult platform games, and didn't think the adddition of a rewind mechanic helped enough to ease the pain. Read it here

Critical Hit start their review with a disclaimer stating that one of their staff, Kate Willaert, did the cover art for the game (which is true - see a few posts back). This doesn't take the gloss off of a very positive review though, which praises the graphics, the music and the level design, and awards a score of 20/20 Read it here

Will Porter at Hookshotinc said that the game 'stapled a smile onto the front-side of my fizzog', which is as good a place as any for it, I suppose. 'Highly, highly recommended', he goes on to say, and uses the term 'pluck-n-chuck' to describe the gameplay, which is too good not to steal and claim as my own. Read it here

I think there was another one but I can't find it at the moment.

There should be some more reviews coming soon if my inbox is to be believed, but in the meantime you could always take a look at the official Apple Jack 2 threads at Neogaf and Rllmuk. They were both started by the excellent Matt, who goes by the name of toythatkills.

I'll be getting a patch ready for the game soon, and many of the bugs and issues mentioned in the above threads will be addressed. A couple of crash bugs in particular are high on my list.


Finally, Gamers Dissent did this playthrough of the first few levels, complete with commentary, which I enjoyed greatly:

Apple Jack 2 is out!

Get it here: http://marketplace.xbox.com/en-GB/Product/Apple-Jack-2/66acd000-77fe-1000-9115-d80258550b4d

..And once you've given it a go, don't forget to give it an honest rating on the dashboard!

Test-driving Builders with Mockito and Hamcrest

A lot of people asked me in the past if I test getters and setters (properties, attributes, etc). They also asked me if I test my builders. The answer, in my case is it depends.

When working with legacy code, I wouldn’t bother to test data structures, that means, objects with just getters and setters, maps, lists, etc. One of the reasons is that I never mock them. I use them as they are when testing the classes that uses them.

For builders, when they are used just by test classes, I also don’t unit test them since they are used as “helpers” in many other tests. If they have a bug, the tests will fail.

In summary, if these data structures and builders already exist, I wouldn’t bother retrofitting test for them.

But now let’s talk about doing TDD and assume you need a new object with getters and setters. In this case, yes, I would write tests for the getters and setters since I need to justify their existence writing my tests first.

In order to have a rich domain model, I normally tend to have business logic associated with the data and have a richer domain model. Let’s see the following example.

In the real life, I would be writing on test at a time, making them pass and refactor. For this post, I’ll just give you the full classes for clarity’s sake. First let’s write the tests:

Now the implementation:


This case is interesting since the Trade object has one property called inboundMessage with respective getters and setters and also uses a collaborator (reportabilityDecision, injected via setter) in its isReportable business method.

A common approach that I’ve seen many times to “test” the setReportabilityDecision method is to introduce a getReportabilityDecision method returning the reportabilityDecision (collaborator) object.

This is definitely the wrong approach. Our objective should be to test how the collaborator is used, that means, if it is invoked with the right parameters and if whatever it returns (if it returns anything) is used. Introducing a getter in this case does not make sense since it does not guarantee that the object, after had the collaborator injected via setter, is interacting with the collaborator as we intended.

As an aside, when we write tests that are about how collaborators are going to be used, defining their interface, is when we are using TDD as a design tool and not just simply as a testing tool. I’ll cover that in a future blog post.

OK, now imagine that this trade object can be created in different ways, that means, with different reportability decisions. We also would like to make our code more readable and we decide to write a builder for the Trade object. Let’s also assume, in this case, that we want the builder to be used in the production and test code as well. 

In this case, we want to test drive our builder. 

Here is an example that I normally find when developers are test-driving a builder implementation.

Now let’s have a look at these tests.  

The good news is, the tests were written in the way developers want to read them. That also means that they were “designing” the TradeBuilder public interface (public methods). 

The bad news is how they are testing it.

If you look closer, the tests for the builder are almost identical to the tests in the TradeTest class. 

You may say that it is OK since the builder is creating the object and the tests should be similar. The only different is that in the TradeTest we instantiate the object by hand and in the TradeBuilderTest we use the builder to instantiate it, but the assertions should be the same, right? 

For me, firstly we have duplication. Secondly, the TradeBuilderTest doesn’t show it’s real intent. 

After many refactorings and exploring different ideas, while pair-programming with one of the guys in my team we came up with this approach:

So now, the TradeBuilderTest express what is expected from the TradeBuilder, that means, the side effect when the build method is called. We want it to create a Trade and set its attributes. There are no duplications with the TradeTest. It is left to the TradeTest to guarantee the correct behavior of the Trade object.

For completion’s sake, here is the final TradeBuider class:



The combination of Mockito and Hamcrest is extremely powerful, allowing us to write better and more readable tests.

Apple Jack 2 released June 14th!

Nine months late but entirely on budget (£0.00), Apple Jack 2 will be released next thursday, the 14th of June...



...For a paltry 80 MICROSOFT POINTS!



That's cheaper than a big bag of crisps, even before you factor in the expense of driving to the shop to pick them up. My Owl Software's commitment to the environment means that Apple Jack 2 will be delivered digitally, direct to your Xbox, absolutely free of charge!

Anyway, does this bag of crisps contain OVER 60 LEVELS of deep-fried platform-puzzle mayhem, with a seasoning of giant monsters, huge fruit-multiplying combos and head scrambling puzzles?

No. It just contains some crisps.

To conclude: you'd have to be an idiot NOT to buy Apple Jack 2 next thursday, from the Xbox Indie games channel!


Thankyou.



PS. If I promised you a download code for the game, I'll email them off once I get them, probably on thursday.