Saturday, March 02, 2013

Notoriously Tomed 0.0.2

After a long deliberation about where to go next with Notorious, a few Roguelike Radios have peaked my interest enough to return to ToME as a dev environment for at least building out a single player experience, possibly more with web server integration.

First off, review the old code and see if it works on the new ToME 1.0.0 engine. Moving the code over was easy enough, but it immediately fails with a lua file error. Looks like all new spells from the summoner code I pinched now have particly effect associated with them. Finding and copying the code is simple enough. Great! It works!

Next is reviewing the development path laid out from a year ago. Even though the design has changed a bit, the next couple of steps still seem to be the same as they were back then. I should Google doc it to make the tracking a little easier.

I'd left the code with lighting issues. What I'd like is that any arbitrary minion or hero can be linked to and highlight the map regardless of where they are. Turns out that it was only a case of changing to The first code looked only for entities within field of view, whereas the 2nd applies the light regardless. Nice & neat.

Next is to turn the heroes onto the other side. They still should be visible if they are carrying gems. Looks like the faction setting allows membership, so removing it from player affiliation makes it work.

Next is to place the heroes at a distance. The target code doesn't seem to work very well, and I'm thinking it's due to the realtime nature of the game not having the targeting in the same turn as the summon. Might be worth more investigation later as some talents might need a target. Arbitrarily placing the point 5 tiles below and to the left is pretty easy though. When approaching them the temporary war hounds go after them pretty well.

Rather than the warhounds chasing down heroes then returning to me, lets see if they can be anchored to the point where they spawned to give them a 'home base'. Hmm, seems easy, but having great difficulty locking down a suitable structure. It looks like there's late binding (or no binding?) on variables as well as the ability to pass completely different structures to the same variable. This is making for some imploding bugs later on, and isn't boding well for robust code down the track. Might need to see if there's a way to make Lua a little more tightly bound.

After a look into Lua's tables, the way they have been used in ToME started to make a little more sense. There is some scary bits:

> t = { apple=5 } > a = "apple" > b = "apple" > c = "app".."le" > print(, t[a], t[b], t[c]) -- all the same value because there is only one "apple"! 5 5 5 5

What .. the .. ?

.. Actually reading it again it's not as bad as I thought. They are using a,b & c as the keys, whereas I thought it was saying that "apple" is defined both inside and outside of the array.

Back to coding with a little more enthusiasm and after about 1 & 1/2 hours of digging into and around the problem, the solution was identical to what I had originally intended, I'd just applied it to the wrong summoning code :/.

Oh well, it still feels like time well spent getting to know the system. 4 hours all up to move the goalposts a little closer and get it to a more comfortable release point:

Notorious 0.0.2