We are nearly halfway through the trimester now, project-wise, and nearly back with the Designers again. On Monday, we were asked how we did with our KillBot path finding on the weekend, all three of us kind of shrugged. Personally, I didn’t get to work on my bot at all last weekend, as I explained in last week’s Weekly Roundup, but I did not explain what I actually did for their game. Their game, Beat Rider, is actually a really cool concept. It is similar to AudioSurf, where you have songs which you must hit approaching notes in order to play the notes, to form a song. I implemented a method of song creation and then the serialization of that song into the game, which is then chosen by the player and played.
So since all three Programmers had not come close to finishing their bots, we were given the option to choose either to spend all lesson getting help with our bots, or all lesson learning about flocking. We were indecisive for a good ten minutes before Eli had the genius idea of pulling up a random number generator from online and putting ‘0’ for bots and ‘1’ for flocking. The website returned the number 1, so flocking it was. What we actually learnt was about Emergent Behaviour in AI, which entailed learning about both A-Life and Flocking. Emergent Behaviour is the result of small, simple rules, working together to create unplanned complex behaviour. For flocking, four simple rules create complex group-behaviour: Obstacle/Enemy avoidance, Separation (not getting too close to each other), Cohesion (move near others) and Alignment (follow others). We were shown a program that Greg wrote, showing off a simulation of these four simple rules working together to form group movement, flocking. By the time we had finished learning about this sweet flocking behaviour, it was too late in the lesson to actually learn how to implement it, so we were told that Wednesday would be the day.
So on Wednesday, we did exactly that, Greg put his computer up on the projector and he coded away, walking us through how to create flocking behaviour, implementing these four rules, one-by-one. Afterwards, Greg again asked how our bots were going, and if we are all ready to have the competition at the second session of this class, but yet again, we let him down. None of us had our bots working 100%. Ryan was definitely the closest to complete, only having some minor bugs and no wall-checking, I was second-closest, having my program go through creating a path at init, and then thinking it didn’t create a path so my bot would just perambulate towards 0,0 instead. Eli was probably the furthest behind, he didn’t show us what was wrong with his bot, but said it couldn’t create a path properly. We all huddled around Ryan’s computer, as greg helped him squish some pesky bugs and pointer-ise most of his variables (it was hilarious how many had to be changed to pointers because of one variable we pointer-ised). I also fixed two bugs I had with my bot, both semi-related to the matter of no bot movement, but still would not solve the issue.
The bugs were:
- Map would generate with each row having one less wall, starting with the first having full walls, and ending with the last having no walls (this gave a diagonal wall pattern).
- Even though I was using the rand function that comes with C++, each time I would generate an end x and y location, the same location would be set, (10, 4), persistent through builds, so I ended up using m_rand.norm() as I saw that Greg had put the time(0) seed in so it would seed the randomiser based on how many seconds it has been since the Unix epoch, which is a pretty good “unpredictable” seed (you’re guaranteed your seed will be the same only once, unless you start your program multiple times within the same second).
Now for this weekend. On Saturday, I did finally get a pathfinding solution, after rewriting the whole thing in a different way. The only thing is that it is fully in console right now, but in theory, it should be really simple to make my bot move along that path. It looks really cool in console and works great! The reason I did it in console was that there was now an additional, smaller step, before implementing it for the bot to move, and I knew if I got it working in console, then from there it would be easy enough to make my bot move along the path. I also wanted to literally see the map and how the bot would move along it, and perfect that first (also implementing 4-directional AND 8-directional movement, just to test it out when the bot is alive).
Sunday was dedicated to helping the Designers again, this time implementing a new movement method, where you can swap around the musical bars in order to hit notes, instead of the player moving. The bars are separated into three groups, we will call them Group 1, Group 2 and Group 3. Hitting the left arrow will swap Group 1 and Group 2, at the same time moving the notes with the groups. If you then hit the right arrow, the order of the bars will now be: Group 2, Group 3, Group 1. It works great! and it only took two hours to implement (geez I say ‘implement’ a lot…) instead of the six hours that was spent on the last thing I did for their game. They told me exactly what they wanted done this time, instead of loosely specifying the requirements last time, forcing me to write 4 different methods of doing it and then asking the Designers to spell out exactly what behaviour they wanted, then the final, and accepted attempt, only taking me 20 minutes to do. They still did not have a TDD to show me what I needed to do this time, but I made sure to draw a diagram and send a picture of it to one of the Designers so that they can confirm we are on the same wavelength.
We have rescheduled the bot tournament to some time this week (Week 6), I hope it is second session Wednesday, as I have stated that my bot doesn’t move along the path yet, but I am very close! I hope you will look forward to reading my next Weekly Roundup, hopefully I win this tournament as well 😉
This is Daniel Jochem, signing out.