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:

Lords of Midnight – Update

I thought I’d better post here, because it seems it’s been a while!

I know many people might be thinking that this project is going the way of all the others… vapourware, and to be truthful there is always the chance of that. I do find it very hard to get the work done in the evenings, when I have so much going on. And we’ve had such a good summer, in the scheme of things, that I’ve found it very hard to do any coding in the evenings.

The last few months has seen me going through a merry go round of my work contracts, and in particular I’ve been working silly hours.

I also had a lot of problems with Marmalade, the SDK I’m using to give me the cross platform. They have only recently been resolved.

Anyway, enough of the excuses, other than to say that 6 months has disappeared and the project hasn’t moved on a great deal!

The intention is to fire up the quatro, and make a real push to get work done started again from Jan. I’ll also try and keep the blog up to date.

I noticed that man people have visited and will have seen no movement for a while… 🙁 sorry about that!

So, watch this space…

Related Posts:

Lords of Midnight – iOS

Thought I’d post an update for LOM. I realise that it’s been over 2 months since I last had anything to say on the subject.

Firstly, it’s been a busy few months for both Mike and myself. Mine work related and Mike’s more personal. That combined with a little bit of sidetracking on Eye of the Moon.

Two of the issues with this project is time and getting it right. Neither of us are working on project full time and it’s very easy to lose a week before you know it, just because you were overly tired or didn’t feel like sitting in front of a computer. I’m sure that winter is the best time to do development and not in the summer.

The getting it right aspect is about thinking about the project more than actually doing it. Over the last 2 months I’ve been going round in circles about the graphics of the game. I’ve been thinking about a number of different approaches that we have considered for the look and feel, and the way the user interface will work.

The original LOM had a very distinctive look and feel. Simple, but very affective. Somehow with the very powerful modern technology, we have to achieve the same result. I sat down recently and gave some thoughts to the way LOM was going to look, and was not happy. I’ve had firm ideas about the direction of the graphics for a long time. Mike brought new ideas to the party when we start discussing the new game. And in general we had a consensus about the way forward. But then I started to doubt… I kept thinking about Jaws. Jaws works because the brilliant robotic sharks that Spielberg was going to show off all over the place, didn’t work. In the end he had to work around them, utilising them sparingly. The end result, much more suspense to the film.

For LOM, the shark was the graphics. Mike wrung an awful lot from the spectrum, but in the end, the setting of the story was defined by the minimalist graphics – a world full of white snow! So, as you start to up the quality of the graphics you are moving further into working shark territory. LOM was stylistic and I feel it has to remain so. Simple and stylistic.

I discussed this with a few people and then went back to Mike in order to tell him that I thought we were the wrong people to be thinking about the graphics. And that if we continued down the path we were following, I felt we were going to make a mistake. Mike agreed.

So, last week I had a meeting with an artist. Fergus McNeil ( some of you may remember his 8 bit days with Delta4 ) and asked him to take over artistic control of the project. I’ll keep you posted with anything I can on the visuals.

In the mean time. Tonight I am back at the computer – coding!

Related Posts:

Getting up and running…

It seems a little strange, that after all this time, something might just finally become of this project! 🙂

The first stage was to get the Midnight Engine up and running under iOS. Well I tried that about 3 years ago without any major success. However, it’s a little more important now. So I downloaded the Airplay SDK which Mike and I had decided to evaluate, and started porting the engine.

It was a pain! Differences in compilers, changes in the language, blah blah blah… it took a couple of days of monotonous work before I had a project that loaded the TME data in. While I was working on that, Mike was playing around with some graphic ideas that we had talked about implementing – mainly to do with lighting.

Continue reading “Getting up and running…”

Related Posts:

Apple Tech Talk

I was lucky enough to get an invite to the Apple 4k Tech Talk in London a couple of weeks ago. It was a worth while trip to the big smoke just for some of the snippets of information your get from some of the talks. Sometimes it doesn’t matter how many forums or blogs you read, how many articles or books you scour through, it takes someone talking to make something make sense.

I didn’t take copious notes like many other people did; there were a large number of people sat there typing in to their Mac Books, almost verbatim anything said!

Anyway, here are a few items I scribbled down that may be of interest.

The first two sessions I took were “Effective iPhone App Development” by Lawrence Coopet.

Data Storage
1. When storing config/session states, be careful about writing lots of objects into a dictionary as individual items. Create a session object and write that instead and don’t just write everything to NSUserDefaults.
2. Think about where you store this data… Archive and implement NSCoding and Data Recovery.
3. Use SQLite
4. Use CoreData
5. Store sensitive data in the KeyChain. This has the benefit of being able to share between projects – company data – application data.

When Caching data, make sure you place it in the correct place and never hard code your paths to this data.
All the paths are stored in NSPathUtilities.

NSTemporaryDirectory – this will always be cleared and will never be backed up.
NSCacheDirectory – this is saved, can be cleared, but will never be backed up.
NSDocumentsDirectory – never cleared, always backed up.

Choosing the right place for your data will determine how much iTunes has to backup when syncing your device.

Targetting iPhone OS
1. You should ALWAYS set your Base SDK to the most current OS version – ie. currently 3.1.2 – regardless of which OS you are considering deploying to.
2. Set you Deployment Target to the minimum OS you want your app to run on.
3. You should check for presence of OS features in your code. eg use NSClassFromString and respondsToSelector. However do this at the start of your app and set flags accordingly so that you are not taking speed hits during normal app operation. checking straight global C functions is very quick.
eg if ( UISaveVideoAtPathToSavedPhotoAlbum )

Application Flow
1. Stay focused!
2. The best system is generally – List View – Info View – Detail View. Allow the user to choose to drill down on data rather than forcing too much information on them in one go.
3. Always use the 1 screen 1 controller model.
4. Make sure you are not hardcoding references back to other objects in your application. Using the Model Controller View model your controller talks back to your model but your model should never talk directly to your controller. Your controller talks to you view but your view should never talk back to your controller. And you should never every have your view talk directly to your model. If parent communication needs to take place, then implement delegates. This way you can avoid App specific communication paths.
5. Use Delegates
6. Use Notifications through NSNotificationCentre

Memory Management
1. Make use of the measurement tools regularly – checking for leaks and generally memory usage.
2. Under Snow Leopard make use of XCode Static Analysis – it’s a fantastic tool. (BTW: It really is!)
3. Use the 1 controller 1 nib model.

Application Life Cycle
Compatibility
1. Prefix your classnames with your own token to avoid namespace collisions. eg UI, NS etc…
2. Avoid underscores at the start of method names – these are reserved to Apple.

Proper Code Paths
1. Follow correct code paths. eg. You implement drawRect and call setNeedsDisplay. NEVER call drawRect.

Interruptions
Make sure you handle applicationWillResignActive, applicationDidResumeActive, and applicationWillTerminate.

Concurrency
1. Make sure you use the Async API for Networking and Reachability.
2. Use NSTimer – don’t sit around in threads counting down!
3. Use NSOperation and NSOperationQue. Subclass NSOperation and override main.
4. Keep object access confined to one thread.
5. Design out the need to use locking/signalling/syncing
6. Avoid performSelectorInBackground and detachNewThreadSelector – if you are using these then you are doing it wrong. Use NSOperation.

Related Posts: