Comments for Deozaan's Blog

Comment on cInput 2.0 Released by Deozaan

Deozaan — Sun, 08 Apr 2012 03:23:44 +0000

In reply to mouser.

You’re absolutely right. After we released cInput 2.0 we got some really good feedback and after a couple of days had implemented some new features and we were ready to send out cInput 2.1.

But before we could submit the update to the code, we had to go over and update all the documentation, the websites, the example code, the instructional videos, demo project, etc., to make sure everything else was up to date.

That delayed the update by a couple of days. I’m still surprised by how much effort it takes for a release besides just getting the code to work.

Comment on cInput 2.0 Released by mouser

mouser — Sun, 08 Apr 2012 00:11:50 +0000

QUOTE “But once we started using the code in the demo project or explaining the code in the documentation, we would find bugs or realize missing functionality that was imperative to the usefulness of cInput 2.0. Time and time again as we worked on these little pieces, feeling like we’d be finished any moment, something new would pop up”

nothing can prepare you for the amount of work you will have to do and the bugs you will find when you start making a demo of your tool. everytime i do a screencast of one of my programs i find bugs and features i need to implement. it’s crazy.

Comment on Programming Theory – Predicting Turn Order by Deozaan

Deozaan — Thu, 20 Oct 2011 18:11:12 +0000

In reply to mouser. @mouser: Thanks for the response. Your solution does indeed sound more elegant than the one I came up with. Now I just need to prototype it and see how it works in action.

Comment on Programming Theory – Predicting Turn Order by mouser

mouser — Thu, 20 Oct 2011 11:30:03 +0000

Very interesting question/subject matter. This is why programming is fun, trying to solve problems like this.

I think you described the nature of the problem pretty well.. You want to make a turn based order of play, but you have speeds expressed as arbitrary values. The perfect example is a board game where you have cars on a track with a fixed number of spaces on the board, but car speed is in miles per hour. And your goal is a system that assigns turn order — AND MOST IMPORTANTLY you want to capture the idea that if car X is twice as fast as car Y, it should get twice as many turns.

Your solution sounded like it was on the right “track” to me, though i got lost a little bit. However i believe there is a more elegant solution that would look something like this:

For each agent, you will keep track of its current turn “meter”, which will start at 0.
Now on each turn you “normalize” the speeds of the agents to make them scale from 0 to 1; you do this by simply dividing all agent speeds by the speed of the fastest agent (this preserves the relative speeds which is all we care about).

TURN LOOP BEGIN:

For each agent, ADD the agent’s normalized speed (which will range from 0 to 1) to their current meter value.

Sort agents by current meter values.

Iterate through list of agents. If agent has more than 1.0 in their meter, they take their turn and SUBTRACT 1.0 from their meter. If not, they are skipped.

REPEAT TURN LOOP

I contend that this will get you what you want. I think intuitively the way to think about it is that it tries to convert the relative speeds into “fractions of a turn”. So that the fastest player is always taking one full turn per round. Other players take virtual “fractional turns” — not moving but building up until they can be spent for a full turn.

Another way to think of it is to imagine player A is twice as fast as player B. So on each round we give player A 2 chips, and player B 1 chip. And it costs 2 chips to move. So on each turn player A spends his 2 chips to play, and player B must *SAVE UP* chips so he can move every other turn. That’s essentially what we are doing here.