• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

Juicy crunchy tasty sweet

Sign in to follow this  
Followers 0


I've scraped together a couple of free hours and spent some time hacking on Epoch Release 8 this weekend. A couple of minor task-list items have been knocked out, and I've done some architectural improving in the parser to help boost compile times.

At the moment I'm working on Issue 9 which involves adding thread pool support to the language's native threading features. Currently, any time you fork a task block or invoke a future, the VM spins off an OS thread under the hood. This is fine for really complex stuff, but for short calculations or general parallelism it really sucks. In most cases the overhead of splitting the thread is higher than the benefit that the parallelism provides.

To counteract this, we provide the option of thread pools. These are worker threads that are spun off at the beginning of the program's execution (well, technically, they are spun off whenever the threadpool function is invoked) and then sit around in a low-cost wait state until someone wants to use one. Once some code is on the worker thread's work queue, it wakes up, executes the code, does anything necessary to store the response and/or message the results back to the calling thread, and then goes back to sleep.

This reduces the overhead of forking a task or future to the overhead of an OS locking primitive (on Windows I'm using a simple Event), which is minimal on good platforms. The result is that it becomes dirt cheap to use multiple threads all over the place.

All of this is pretty easy to set up. Here's an example program from the upcoming Release 8 package:

// Demonstration of worker thread pooling in Epoch

entrypoint : () -> ()
// Create the thread pool with a limited number of threads
threadpool("demo pool", 2)

// Fork off a chunk of work for the thread pool to do
thread("task1", "demo pool")
message(caller(), result(pi()))

thread("task2", "demo pool")
message(caller(), result(pi()))

future(r1, pi(), "demo pool")
future(r2, pi(), "demo pool")

// Wait for work results to complete and display them
result(real(piresult)) => { debugwritestring("Result: " ; cast(string, piresult)) }


debugwritestring("Future result: " ; cast(string, r1))
debugwritestring("Future result: " ; cast(string, r2))

pi : () -> (real(retval, 0.0))
real(denominator, 1.0)
boolean(isplus, true)

real(div, 4.0 / denominator)

retval = retval + div
retval = retval - div

isplus = !isplus
denominator = denominator + 2.0

} while(denominator < 10000.0)

(You can see more example Epoch programs in the Examples repository.)

Note that instead of a typical task we request a thread. The thread construct accepts two parameters, in contrast to task's one. The first parameter is still the internal ID tag of the thread, so you can message it later. The second parameter is the name of the thread pool from which a thread should be used; this must match the name of a pool previously created by invoking the threadpool function.

A similar tweak is added to the future function: the optional third parameter controls which pool a future is computed in. All in all, using thread pooling is simple, intuitive, and concise - above all a supremely pragmatic sort of feature, which is exactly what Epoch should be.

Working on this has unearthed a couple of parser and validator bugs that I'm fixing; once that is out of the way, I still need to actually build the thread pool support in the VM (for now it still forks a thread, while I work on getting the parser stuff fixed).

Following that, there are only a handful of items left in the work list for Release 8:

  • Fix a bug with batch operations and output filenames

  • Add simple critical-section wrappers for CUDA library to give some primitive threading safety to CUDA integration

  • Add some build configurations to the VS solution to allow building Epoch with no CUDA support (for all the ATi users out there)

  • Perform a final code review, largely for documentation and exception safety purposes

Of these, the only really major chunk of time will be the code review. At this point I plan on doing a cursory pass over the code once to make sure it's bare-minimum acceptable for release, and then doing additional in-depth reviews over things as time permits. That should make sure that I can get this thing out the door by the end of the month, as planned.

Once R8 hits the shelves it's time to hop back into the CUDA integration side of things and really improve the supported features (right now you're kind of stuck with simple arithmetic on a single GPU-side thread, which is fairly useless). That and some other surprises are in store for R9, which will be the official GDC 2010 preview release - meaning I'll probably be cramming stuff into it right up until the first week of March.

Speaking of GDC 2010, I can confirm that I'll be present this year once again, and anyone interested in an Epoch preview kit can contact me here via PM to arrange a meeting at GDC. Ask nicely and I might even give you a hallway preview [wink]

That concludes our show; join us next time for nothing of consequence, or stay tuned to see absolutely nothing.

Sign in to follow this  
Followers 0


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now