Tag Archives: programming

Topics Too Small to Blog About

I’ve been reading The Kobold Guide to Board Game Design. I’ve been tie-dying shirts. I’ve been experimenting with GameMaker for the Mac, getting test libraries compiling in XCode, and making a simple version of Space Invaders in Scratch.

No single one of these things has turned into a project that was quite enough to write about. Either that, or I’m just having trouble writing lately. Could be both!

Nothing to See Here…

I’m breaking with convention and not doing a Salta Champ update this week. Not that I haven’t worked on it, but it’s largely been refactoring my mostly-C code into proper C++. Which, aside from introducing a few (pleasantly few) typos that I’ve had to track down, isn’t too exciting from the outside.

It has been a good exercise, though, working yet more muscles that I hadn’t had a chance to stretch in a while.

Satisfaction Part 2

As I mentioned yesterday, one of the weaknesses of a work-to-schedule AI approach, with an exponentially growing search space, is that you can easily spend most of your time on an analysis that never ends up getting used. After all, if at each search depth you take more time than all of the previous depths put together, there’s no point starting a search in the whole second half of your allotted time. Continue reading Satisfaction Part 2

You Get What You Need

stopwatchIf I recently taught my AI to despair, then currently I’m teaching it satisfaction.

See, a planning AI is often about look-ahead. The more turns in the future it can consider, the smarter its answer is apt to be. But, of course, that takes time – exponentially increasing time, in fact. So, how far ahead can you afford to look, and still finish on a tolerable schedule? Continue reading You Get What You Need

Version 0.4 is Up

Version 0.4.0 of my Salta project has been posted. The first thing you’ll notice is an actual installer. Other notes:

  • The game now autosaves on exit (unless it’s in a Game Over state)
  • Sound! Only a few, but it’s a big difference.
  • The button array was getting crowded, so now there’s a separate menu screen for things that don’t need to be quite so accessible from in-game
  • Added “New Game” button, now that (because of autosave) you can’t start a new game any other way
  • Various AI changes, generally making it a bit smarter.
  • Game detects when either side is left with only disadvantageous jumps to choose from, and plays a somewhat applause-like sound in congratulations
  • Changed the way the Undo buffer works. You can no longer undo an entire game, but you can still undo plenty.
  • Implemented final scoring! It’s not particularly explained, but after the end of regular play, any side that doesn’t have all its pieces parked yet has to count the moves required to do so, taking that number as a (penalty) score.



End scoring demoI alluded yesterday to a problem with the way my AI ranked moves. In fact, it’s a problem with the way the whole game is scored. See, I took the rule where each side finishes parking its pieces “as if the opponent’s pieces were non-existent” and got it into my head as “as if the other pieces were non-existent.” This is one of those easier-said-than-done kind of distinctions! The latter is simply the total shortest-path distance of each piece from its destination. Easy-peasy. The real rule takes planning, which means more AI work. Continue reading 7/11