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! Also please read the vacuum for pet hair reviews by following the link.

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:

We fought side-by-side on the Plains of Blood in the last war against Doomdark

Since the start of this project there has been an interesting issue with Doomdark’s armies reaching Blood too soon. I’d noticed it while playing, and the testers have brought it up more than a few times. I have checked the code, doubled checked the code, triple checked the code, and the fact is, there is absolutely no reason why Doomdark’s armies cannot reach Blood the first night.

There are two regiments that start the game at the keeps at the Gap of Valethor, lets call them regiments 100 and 101. These are both riders set to wander.

A wandering regiment has 6 turns in the night. Firstly it checks up to 3 locations away, if there is anything interesting between it and 3 locations, it will make 1 turn step toward it. If not, it will randomly pick a direction, and as long as it isn’t frozen wastes, make 1 turn step in that direction.

Movement costs depending on terrain and direction. eg: Cost is *2 turns for a warrior, and a mountain costs 4 turns. So a warrior walking out of a mountain will take 8 turns. You take the terrain cost from the terrain you are leaving not the one you are stepping into. So a warrior walking from plains into mountains will take 2 turns, leaving 4 turns. The next move will cost 8 turns, but the fact they only have 4 turns left, is not important, they take the move, but then have -ve turns left, and thus their processing ends.

The process will be repeated until the 6 turns have been exhausted.

Now regiment 100 starts at the keep directly north of Blood. If on its first move, it decides to move south, then that places it within 3 locations of Blood, which means the next turn will focus it on the stronghold, and therefore it will guaranty hitting Blood in the first night. A movement of southeast, or southwest, will reduce the chance that the regiment will hit Blood in the first night, but it is still a possibility.

So, the original AI for Lords of Midnight, makes it possible that Blood could be hit on the first night. But it hardly ever happened. On my version, it happened almost every time. And every time makes it impossible for you to recruit Lord Blood, let alone try and mount the Blood Defence.

I figured that the random number generator mustn’t be functioning, so tested that, double tested it, and then tested it again. It seemed to be giving a reasonable stream of numbers. Didn’t change the fact that the results I was getting were not desirable. So I considered placing a delay command on those regiments, just to slow them down.

Last night I was talking through the issue again with Mike and we decided to throw out the random routine, and use another one instead. He gave me the C code version of the one used in Midwinter. The results were the same! But then I noticed something. The random number functions generate a number between 0.0 and 1.0 And thus picking number between say 0 and 8 just involves multiplying 8 by the random number, and there was the problem. This number needed to be converted to an integer, a whole number, and it was being done with a cast to int. And this truncates, which means the number is ALWAYS rounded down. In theory it just means that in this instance, 8 would almost never be picked. And in the case of these wandering regiments, that just means losing Northwest. However, changing that one line of code in the random number generator, has put those wandering regiments, back on the right track.

Blood can still be hit, but it is hit much less often than before.

Related Posts: