Deprecated…

I was feeling a little depressed last night, thought I’d wallow in the understanding that I was going to end up, moving on…

I’m working away, (again), at the moment. So I left my hotel and went for a walk, then into town to get something to eat. Found a nice homely Italian restaurant, and settled on some pasta, and beer, and wine, and desert, and Limoncello, and coffee…

I got back to the hotel and decided to Kickstart the ZX Spectrum Next. I figured that I might have a play around with it when it comes out. Started to think about finishing off the OpenSourceing of the codebase that I started previsouly. I then decided that I needed to give Timbles one last chance. I’d been unable to build LoM and DDR as 64 bit, but hadn’t tried Timbles. It failed! BUT, it failed differently. Hmmm… interesting.

Marmalade uses a project file called an MKB. The cross platform nature of it means that you create the actual project from the MKB file. So if I’m developing on Mac under XCode, I don’t hand the XCode project to someone developing on Windows, just the files and the MKB. From the MKB file they will be able to create a Visual Studio project.

This would be the only thing that would affect the build process of the different Apps. I took a look through the MKB file and found a couple of odd entries, entries that looked like they pertained to processor. These entries were in the iOS section. Now, I didn’t think there was anything in the project file for processor selection, that happens as part of the build process, AND I didn’t recognise the config options, I certainly hadn’t put them there. Now, I’ve had this before when an older version of Marmalade has added some options, or the options were necessary at some stage, but the system has evolved – yet the project has not been cleaned up.

I deleted the options and rebuilt… Success!

Quickly loaded the app onto my device… fail!

Not disheartended though, the failure was a memory issue. A quick check of my memory configs and I noticed that I don’t have enough memory allocated against the new devices ( as decided by screen resolution ). I’m testing on an iPhone7. Change, compile, deploy… fail!

It got further though… This time it is complaining that the TME databse is invalid. The MagicNo that I used to identify the database and to check endianness, is wrong. I figure that this is a 64 bit issue… I check my definitions of u32 ( being an unsigned 32 bit ) and the definition is unsigned long. Longs change to 64 bit, so I’m reading 8 bytes for the MagicNo and not 4 bytes, I should have used int. I check all the type definitions, check all the places that I’m using longs in the project. Change, compile, deploy… fail!

This time no error message, just crash straight out. So I add more logging and identify the image cache sorting routine. It’s using the c++ qsort function to sort a series of pointers to objects… in the code I noticed some funky casting going on, which happens to be using *(u32*) – that should be using longs. Change, compile, deploy… fail!

Hmmm… more tracing and I find another sort routine! So I change that and then search the code for any code that is doing a similar thing. Change, compile, deploy… success!

A quick play through and everything looks ok!

I upload to app store and the upload fails. It doesn’t like the binary. The reaon – it’s because the payload has the iTunesArtwork embedded in it, and Apple stopped doing that a while ago. Change, deploy, upload… success!

Download the app and everything is ok. So I push a version to external testing. This requires Apple to review and clear it. At 1:45 the app is cleared. I’m now ready to externally test. I really need to test against all the new devices that have been released by Apple over the last few years. Resolution will be the issue…

But… we’re on. This means that I can now push a new version of LoM and DDR out and buy myself a lot more time to transition to a new system.

Related Posts:

Timbles – Week 3

timbles_elephantAnother week passes by in what is becoming a worryingly increasing pace.

The work on Timbles last week yielded few, if any, outward signs of change. Definitely nothing that would warrant another youtube video. However, a lot of pieces dropped into place. There is some tweaking to do, but the Frantic mode is pretty much in place.

One of the difficult things to remember with Timbles, is that it’s about the numbers, the times tables. It’s about getting someone to play the game long enough and not think about the fact that they are playing a game of times tables. It’s essentially, learning your tables by rote. And to that end it is important that the player, just keeps playing.

It makes thinking about the design of the game a little difficult at times because normal rules of game design don’t always apply. I have added many fun things with the star bursts, and power ups and like. But in the end, they are only there to distract the player from the times table bit of the game, and lengthen the game time, and in turn increase the players exposure to the numbers.

 

bonus_7 bonus_3 bonus_5
I am within touching distance of a playable version. So, this week my focus is going to be on some frontend work, putting things like the main menu in place. By the end of the week I want to be running on an actual iPad with the ability to play the game and return to the menu, and then play another game.

Related Posts:

Timbles – Week 2

Last week I spent a good amount of time coding! I has my main framework in place last week so just need to start adding new things in. I found myself reading through the code of the original prototype and then coding these individual snippets up in the new system.

The original windows vb.net code
Screen Shot 2013-06-24 at 10.15.57

New C/C++ code
Screen Shot 2013-06-24 at 10.17.53

However, after wondering if there was anything online for converting vb.net to c++, I found something that would allow me to convert 100 lines of code at a time. So I quickly rattled through most of the code, and by Tuesday had all the original prototype code in place in the new system. I spent Tuesday, housekeeping, fixing up the stuff that wasn’t right.

By the end of it I had areas of code marked up as TODO: these were areas that I couldn’t incorporate fully yet, but I knew I would need to work through.
Screen Shot 2013-06-24 at 10.24.26

Timbles Design DocumentWhile working porting the old code, I realised that there was a whole area of the original prototype that I couldn’t remember how it worked, why certain actions were triggered, what certain variables were doing. So I started a design document to record this information as I worked it out again. This would give me something to work with as I turned the prototype into a real game.

It’s funny, that as the new prototype is now playable I find myself thinking about the actual game more. Which really is what it is all about. The original prototype was just that, a prototype. I now have a new prototype running under a new system, but it is still a prototype. It’s the base to build upon. The original prototype had a few game styles, but I decided to implement Frantic mode first. Frantic involves numbers appearing on the screen slowly, you must keep the screen clear. The more questions you get right, the shorter the delay between questions becomes. The game continues like this for a time and then stops adding new numbers allowing you to finish off clearing the screen, and then the next table is added and the process starts again.

While playing the Frantic mode, I found it too difficult! Yep, that’s me playing a game I wrote, that was only using the 2 times table. Is there any hope? 🙂 The issue is actually the size of the playing area. If the question comes up at the bottom of the screen and the answer is at the top of the screen, you can spend more time looking for the answer than you have, especially as the screen becomes fuller. Thinking about it, I found myself thinking about two solutions that would make it easier and more importantly more fun. Either the playing board is smaller and the imagery bigger, which is not a bad thing in itself, or the the questions and answers need to appear closer together. Of the two I happen to like to first solution, mainly because bigger graphics are always going to be preferable, especially on mobile devices. So if the game suggests that the board should be smaller and the graphics should be bigger, who am I to argue?

Thursday I added in sound code. My framework had no method for playing sound as I never used it in The Lords of Midnight. So I had to work my way through the Marmalade SDK to add sound support. Now I can start the process of implementing all the sound effects – a whole group of TODO’s ready to come off the list.

Friday was a right off, pretty much the same as the week before. Not sure what it is about Friday’s but I need to keep my eye on it. No working currently getting done on Fridays!

Video of me playing the new prototype!

Related Posts:

Blackberry Playbook

I recently registered for Blackberry development through Marmalade. The reason was because RIM were offering a free device on loan to test your application. I figured I had nothing to lose, so why not. Anyway, the process was pretty quick and within 10 days I was accepted on the program, qualified for the device, and it turned up today.

I installed the Native SDK, which in turn allows Marmalade to target the device natively. I registered all the certificates etc that I needed. Built the app. Deployed to the device. And well…

There you go. The process was pretty painless. But, check this out: The Marmalade SDK did it’s thing and it just worked. The previous work I did on resolution independence paid off. I just have a few tweaks to make because of the widescreen. But other than that… fully functional.

Related Posts:

“I slew score upon score of his foul creatures yet always there were more to take their place”

I can only apologise for the delays in this project, but can assure you that I more than anyone am eager to see this released.

The summer has proved much turmoil to my schedule. Not because I am too busy, but more because I am out of sorts with development in general. The house move came at a time when I was in full flow, and unfortunately, it had the dramatic affect of completely killing my momentum. And I am only very slowly getting that back.

Anyway, over the last few weeks I have pushed out 2 new versions for testing, and have already added some features read for next weeks drop. The first included changes to the Ice Crown quest. For those people who are very familiar with the original game, the quest mode is way too easy. So I wanted to spice it up a little. Ideally, I was going to move the location of the Ice Crown, or even have it randomly assigned to a location, so that you would have to do some questing to find its location, before you can perform the quest itself. However, I decided to leave that to later in game campaign updates. So all I did was add a few extra armies on the north western flank, the route that Morkin would usually take to perform the quest, and then add some additional logic for generating new armies that are interested in the Ice Crown, should it be lifted from its original location. Current testing suggests that the quest may be a little too hard! 🙂

Second update added some small features to the lord selection screen. The ability to instantly see which lords are at night, dawn, in battle, and to be able to filter on them.

Next weeks drop includes additional features for the map screen. Namely easily locating yourself on the map, scaling, and being able to select things from off the map. Hopefully, I will also add in support for iPhone5 for next week, because currently the wide-screen nature of it, is playing havoc with the game.

In other news, I have a Blackberry tablet dev kit winging its way to me, courtesy of RIM and Marmalade. Which in theory means that the game could launch on this device at the same time as iOS, something that I unfortunately cannot extend to Android.

And… still looking for artists… if you know anyone who might like to get involved, point them in my direction!

Related Posts: