Multi Yodel Scope

So, I've been on holidays for two months or so, and have been partaking in eclectic activities. Most of these are not significant to the focus of this blog, however I have managed to glean some constructive work from this time.

First up, I've given some attention to restructuring Synergy to support multicore processing. I had the design goals to allow the engine to scale with cores at run time, to have next to zero locking mechanisms in the code, and to have the multicore functionality as transparent as possible.

What I ended up with is largely a combination of two materials I read. The first is an introductory article to writing multicore games for the Xbox 360, which gives a good overall breakdown of an engine's structure into parallel processes. The second is Valve Corporation's presentation on Source Engine's multicore concepts.

Taking these two together, I basically have two `Delegator' threads that run through the structure outlined in the 360 article as 2 parallel processes. Every significant independently executable function within those threads is called with a function wrapper task(), which takes a pointer to the function to be run, and up to four parameters caste to void type. The task() function takes the information passed to it and builds a linked list with it, and then pushes that linked list onto a lock-less task queue.

All the while this is happening, there is a thread pool with some number of threads all executing a peon() function. As the name might suggest, peon functions continually check the task queue for a task, and if they can grab it they do so, break the linked list up into a function call, and then execute the function representing the task to be done. Upon completing the function, the thread returns to its peon() function to continue checking for more work to do. As you might guess, the number of peon threads in operation is related to how many CPU cores are visible to the engine. The more cores available, the more peons can be running.

Within all of this is a simple semaphore system whereby a task in the queue can be associated with a semaphore. This allows the delegator threads to wait until a certain cluster of tasks in the queue are completed before adding more tasks. This is a necessary evil simply due to the serialised structure of games themselves, and at the moment is the most logical solution I can think of. This is, in fact, a locking mechanism, but it's only operating when the actual logic of the program cannot proceed until the current tasks are completed, and it should minimise any kind of thrashing, since the peon threads never rely on the semaphores.

So that's Synergy's multicore structure at the moment. Nothing too sophisticated, and still yet to actually be tested! But at least in theory it meets all of my design goals for the moment.

Next up in my projects is a Team Fortress 2 map! I've been itching to do some mapping for a while, but struggled to settle upon a good idea until I was reading over the Valve Developer Community Team Fortress 2 pages, and there was an article about Circular Control Point map types. This is a game mode currently not implemented in any official map, but has the potential to be an extremely dynamic game type if implemented appropriately.

After reading about it, I had a rapid explosion of ideas for a map, and begun to sketch out every area in photoshop, paying careful attention to attack/defend dynamics, flanks, killzones and setup areas. As well as the obvious considerations for each class.

After about a day I had the whole map sketched out and detailed with all major routes, spawns, setup areas, rocket jump access, etc, and began to actually rough the map out in Hammer. As of writing this I have the entire map roughed out in seperate map files and am currently bringing them all together and playing a juggling act to get them to all fit together. Some points have considerably larger areas than others, and so alot of scale harmonising needs to be done, which is a little tedious.

I'm hoping to have a tight, playable alpha of the map ready by the next tf2mappers.net game day, so it can have some testing done by fellow mappers. Anyway, though it's hardly eye-candy material at this point, here's some screen shots:

Battle area below D

Attacker's far staging area at C

Primary indoor contesting area of C

Oh and here's some random sketch I half-finished up the other day:

What if the mountain defeats you?