Notes

The Case for a Free Book

Why is the Dragonfly book free? There are several reasons. I've had concerns about academic textbook publishing for while (at least for the technical computer science-type books with which I am familiar). From my own publishing experiences, academic book prices are set directly by the publisher with no cost control by the authors. Many books that have an "academic" spin and might be used for a course are double or triple the price of books with similar content, but perhaps less high falutin' material or tone. Books that are targeted at college students seem to automatically be priced higher. And even slight modifications to the content becomes a whole new book version, making it hard for students to re-sell/re-use an expensive earlier version. And some courses don't need an entire book, but rather need parts of several books. In the past, I've tried to use services that "assemble" books based on chapters selected from several sources, but not all the publishers allowed piece-wise content this way, and, annoyingly, the resulting book was as expensive for the students as buying "normal" 3x-priced textbook.

On the digital side, online tools to read books are making it increasingly convenient to read books electronically, avoiding the need to carry around a cumbersome print book (and saving printing resources). Many of my students to prefer reading online or on a digital device more and more. Once a book is digitized, it can be divided up and linked to making it easier to share and used in modular fashion. And an electronic book version is more likely to be discovered by searches such as Google, making it more likely to be found and used in the first place. Electronic copies can be updated much easier than print copies, too, making it more likely that the latest and greatest content is available when it is used. In short, micro-selection and updated, convenient content mean (free) online books can be better than their print counterparts.

Given that, why do I charge for any version of the Dragonfly book (e.g., the purchase options)? Well, some people prefer print to electronic (in fact, I typically prefer a printed book to an electronic one), and printing and shipping costs money - someone has to pay. Distributing electronic books is significantly lower in cost than print (but not free), so the modest price I charge for the full electronic edition provides some incentive for me to do the work needed to maintain the online content. (But if someone really needs a print copy and cannot afford it, drop me a note and I'll see what I can do).

This does not mean all authors should make all their books free nor does it mean that all books should be free to everyone. But for the right topic (teaching about game engine development) and the right person (me), they make a lot of sense. Hence, my decision to make the Dragonfly book content available for free online.

(For a longer narrative that further motivated me to put the Dragonfly book online for free see the case for free online books by Remzi Arpaci-Dusseau, co-author of Operating Systems: Three Easy Pieces.)

ASCII Graphics

A reasonable question is why Dragonfly provides ASCII-only (or text-only ) graphics. In a nutshell, creating and providing support for text-based graphics is relatively easy - much easier than 2d and especially 3d - and constrains the aspiring programmer in helpful ways.

The 2d, grid-based layout of text is conceptually easy to design and implement, allowing the programmer - both the game programmer and the game engine programmer - to focus on other aspects of development (like learning how to make a game engine!). Along these lines, text-only graphics has the added benefit of making the size and scope of the programming effort to create a game engine from scratch manageable, meaning it is more likely the aspiring programmer will complete the work.

Text graphics have basic (x,y) coordinates with a potential "canvas" as big as as the terminal window. Traditional terminal windows are 80x24, but modern displays don't impose such limits, giving even more flexibility. Text is supported by nearly all computers and there are even libraries solely used for text graphical output, such as Curses. With text as the lowest common denominator, Dragonfly can be developed in a mostly platform-independent fashion.

Last, but not least, having art limited to just text characters is a blessing in disguise when learning to program. In versions of the course before using Dragonly, students using game engines that supported a full range of 2d or even 3d graphics spent a lot of time on the art, trying to make their games look good. Being tech students, most of them were generally not good at art, so the games still looked bad. Even worse, the time spent on the art took away from the time they should have been programming, learning the technical coding aspects of how to build games and game engines!

Being limited to text-only graphics, there is no need, nor even the ability, to spend time making detailed art, much less realistic graphics, since the underlying display manager does not support them. And this is important lesson to share with aspiring game designers - for many games, the visuals do not make or break the game, anyway. A game that is boring with simple characters and text-based shapes will not suddenly be fun with fancy graphics. Conversely, a game with interesting gameplay and eye-popping graphics will still be fun with basic text-based graphics. This is the guiding principal behind the Perlenspiel game engine (developed by my colleague, Brian Moriarty) which helps students focus on game design by limiting art to colored squares. Similarly, text-based games reduce the temptation for the programmers to spend time on art, and the development emphasis shifts to the game design and programming. In other words, "programmer art" is perfectly fine (and even better) for developing games with the Dragonfly game engine!

Creating text-based graphics does not require any special tools (e.g., a stylus) or software (e.g., Photoshop or Zbrush). Instead, students can open up their favorite text editors and start creating ASCII art. And personally, I like the retro-look that ASCII graphics provides. It looks similar to arcade games of the 70's and 80's and this genre of game (arcade style action) is well-supported by Dragonfly.

While text-based graphics may seem limiting, they are not as limiting as one might think. Check out an extensive text-graphics only version of Star Wars (Asciimation) to see how text-graphics can visually convey a whole story. Better, check out the compelling game trailers of the variety of style and look of games created (thus far) with Dragonfly!

Timeline

The major developments in the life of Dragonfly:

2011

Dragonfly egg

The Dragonfly game engine and subsequent book arose out of a new teaching assignment I was given for a course on technical game development. When I was assigned the course, I said "No problem. I know technical content and I've built a lot of games ... I got this!" But what I soon realized, as I often has as a professor, was that having to teach something to others requires another whole layer of understanding. In my case, I knew what a game engine was in theory, and had even used several externally to make games, but knowing what a game engine did internally? ... not so much. So, like most good professors, I sought to shamelessly copy what other, better professors had done for the same course. Unfortunately for me, there was slim picking for what I wanted - our technical game development course is rather unique, certainly at WPI but also across other technical game development programs.

So, I went to the stock professor "plan B" - find a good academic text on the topic and use it to anchor the course. The summer before I was to teach the course, I bought/borrowed and read a lot of books on game engines, looking for a single book that explained game engines in sufficient detail to really understand them in the span of a single volume.

But this search let me down, too. Quality varied a lot. Books that sounded promising either dumped a whole lot of code without explanation or did not have enough details to illustrate their ideas. I did find an excellent book close to what I wanted - Game Engine Architecture by Jason Gregory. Gregory wrote an academic-flavored text with a solid practical foundation, a good level of detail on many game engine components that included specifics from commercial engines throughout. It was tantalizingly close to telling me exactly what a game engine was so that I could, in turn, teach it to the students in my upcoming course.

But before committing to a book for a course, I first define the programming projects that students will do to apply the fundamental course concepts. I implement the projects myself, start to finish, and make sure they apply the concepts studied in class (or the book) and are able to be completed in the time allot ed (typically weeks at most). Usually, this is a lot of trial and error as I figure out the right scope. But once done, I write them up into project descriptions to give to the students in the course. In this case, I still did not know what, exactly, the students would be doing, even if imbued with the Gregory game engine knowledge.

I drew inspiration from MINIX, a Unix-like operating system (and precursor to Linux) that I studied in graduate school. With MINIX and the accompanying text book (cover shown), a student could study an entire operating system, even building it if desired. The whole system was about 12,000 lines of C-code. Moreover, MINIX was modular, which allowed course projects to focus on pieces of interest, if the entire OS was not needed. I thought ... "Hey, what about a MINIX-type approach for a game engine?"

So, having absorbed a lot of game engine material coupled with my prior game-programmer knowledge of several engines, I set out to make an engine myself - the first version of Dragonfly. About 5000 lines of code later (that's another story), I ended up learning a lot, and, most importantly, what I learned seemed fundamental to the discipline of technical game development. I felt anyone and everyone in technical game development should not only know what a game engine is through theory and use, but should know what a game engine is from developing one. In short, I made a plan to anchor the course I was to teach by having every student to build a game engine from scratch.

2012

Dragonfly hatching

I first used the game-engine-from-scratch idea in IMGD 3000 Technical Game Development I. The foundation was a series of projects that saw the students build a tutorial game, then build a game engine from scratch (broken into pieces so as to be manageable), followed by making a custom game using their own engine. The first Dragonfly book content emerged in the form of Powerpoint slides, presented during class lectures that illustrated game engine design, discussed design rationale, and provided software engineering and programming techniques critical for building a game engine.

(The free clipart shown was the first Dragonfly logo I used before created my own ASCII version, applying the principle that programmer art is ok.)

This initial slide deck grew up quickly, going through two iterations since it was revised after the first course offering and used in a second course offering less than a year later. The projects similarly evolved, with some Dragonfly features moving from early versions to later versions and vice versa based on student feedback and project assessment.

2013

First Dragonfly book

While the previous courses had gone well, a common complaint from some students was the lack of reference material they could use to outside of class to either read about the course material (for those that learned better that way) or supplement their knowledge/notes from class lecture. In essence, the students wanted a book to accompany the course.

So, I set out to create the first version of the Dragonfly book from the slide deck. For 3 months during the summer, I took the hundreds of previously developed slides - slides that already had a solid organization as well as pseudo-code to illustrate concepts - and put them into book form. Basically, I added the lengthy descriptions and discussions that accompanied the slide content during lectures, as well as fleshed out background and details that might have been more sparsely presented in class due to time constraints.

For editing and printing, I did not yet have a publisher and did not know if I even wanted one (see the The Case for a Free Book above for reasons for my misgivings). Some quick searching showed self-publishing was possible, but even that seemed more than I wanted. What I settled on was self-printing copies, in this case using the excellent print services from Book1One. I fronted the money for printing books for the entire class and had, for the first time, a copy of the Dragonfly book for each student. For editing, I was on my own (I did writing in emacs and typesetting in LaTeX), but encouraged students to submit errata and content-change suggestions, much of which have greatly helped improve the text over the years. I used this printing and distribution mechanism for the next 4 years.

Dragonfly journal paper

By this time, it was clear that the Dragonfly idea was working, backed up not just by student evaluations of my teaching ratings, but also by student evaluation of the course content. The chart shows student responses to the statement "The educational value of the assigned work was", with responses provided on a 5-point scale. Each bar represents the percentage of respondents that gave the indicated numeric score. The blue asterisk (*) shows the mean.

The responses are quite positive, with the mode "excellent" and the mean 4.7, suggesting the game-engine focus of the assigned work was of high educational value. This was backed up through my assessment of their projects. Most students were able to build a functional game engine, demonstrated by a near 90% completion rate for the core game engine project (done solo!), and a majority of project (80+%) good (having a B or higher grade).

Feeling others would benefit from the Dragonfly approach, I disseminated the results in a paper on the benefits to programming from building a game engine from scratch:

Mark Claypool. Dragonfly - Strengthening Programming Skills by Building a Game Engine from Scratch, Computer Science Education - Special issue on Games in Computer Science Education, Taylor and Francis, Volume 23, Issue 2, Pages 112-137, June 2013.

2014

Question-Answer forum

As each offering of the course saw students working through their own, unique implementation challenges, it became clear that some problems were encountered each year. Moreover, as is often the case, students were sometimes able to help each other better (and quicker) than waiting for help from the teaching teaching staff (professor and teaching assistants). Inspired by my use of Stack Overflow for tapping into the wisdom of the programming masses, I setup a private server and software for The Dragonfly Question & Answer Forum (DQA).

DQA was a question and answer forum where Dragonfly programmers (both game engine programmers and game programmers) could post questions and read community answers from teaching staff and fellow students. And while I ended up answering most of the questions, the site was useful for archiving past answers for future questioners.

Dragonfly in other courses

For general computer science education, it seemed likely that the small-scope of Dragonfly would lend itself to projects beyond just engine development. In Spring 2014, for an upper-level undergraduate Distributed Systems course, I used Dragonfly in a course project where students built a multi-player, online game (a distributed system):

Dragonfly Wings - Extending the Dragonfly Game Engine with Networking

Students extended the core Dragonfly game engine (my version of the engine - they didn't build their own in this class) to support Networking, and created a two player game using their engine.

The chart shows student responses to the statement "The project helped me better understand distributed systems", with responses provided on a 5-point scale. Each bar represents the percentage of respondents that gave the indicated numeric score. The blue asterisk (*) shows the mean. The responses were quite positive, with a mean around 4, suggesting the multi-player game as a distributed system worked well for reinforcing distributed systems concepts.

2015

Simple and Fast Multimedia Library

Up until this point, Dragonfly had been using Curses (actually, NCurses) to draw text-based graphics in a terminal window. I had been a fan of using Curses in systems course projects for decades (e.g., a pong game) since it gave students simple graphics, while allowing focus on the systems-level concepts (e.g., concurrency and shared memory). However, for Dragonfly, Curses presented some challenges, particularly for Windows developers since this (mostly) required using Cygwin (which I also like a lot, but many students found cumbersome). In addition, the mouse support in Curses was limited (Curses did not provide mouse movement events at all) as were key-held events.

In order to ease development environment struggles (a part of programming, but not necessarily the main part of a course) and to provide better mouse and keyboard support, I re-factored Dragonfly to use the Simple and Fast Multimedia Library (SFML) instead. This required major changes to the DisplayManager and InputManager since these two components were inter-twined with Curses, doing graphics and device input, respectively. But there was minimal impact (nearly none) on the of the rest of the engine. This really gave me an appreciation of the elegance and power of object-oriented design and layering, using encapsulation to minimizing code re-write!

As a bonus, using SFML had the added benefit of providing easy access to audio, giving rise to the first support for sound effects and music by Dragonfly. As one of my colleagues Keith Zizza famously always said, "Sound is one-third of the experience!" - so it was long overdue that Dragonfly supported a full 3/3 experience.

Another paper

Based on experiences using Dragonfly for my Distributed Systems course, I published a paper describing the networking and multi-player online game project:

Mark Claypool. Teaching Network Game Programming with the Dragonfly Game Engine, Syllabus Journal - Special Issue on Teaching with and about Video Games, Vol. 4, No. 1, 2015.

Assessment showed the project helped students understand networking and distributed systems, and greatly helped understand game engines and C++ programming.

Dragonfly for research

For most my computer game research, the ability to drive a game in an automated fashion is helpful. For some latency-compensation research, I created a sped-up, headless (no graphics) version of Dragonfly and used it for evaluation, resulting in the publication:

Mark Claypool, Tianhe Wang, and McIntyre Watts. A Taxonomy for Player Actions with Latency in Network Games, In Proceedings of the 25th ACM International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV), Portland, Oregon, USA, March 2015.

2016

I again used Dragonfly in my Distributed Computing Systems course. This time, adding an additional project in which students deployed Dragonfly as a cloud game system:

Cloud Saucer Shoot - an Implementation of a Cloud-based Game

Dragonfly as a cloud game system was surprisingly elegant. Building it gave me a bunch of new research ideas, too - some of which should appear in timeline entries on this page in the next few years!

2017

In the summer, I published the free online version of the Dragonfly book (see the Case for a Free Book) available at the Lulu.com spotlight store:

Dragonfly Book @ Lulu.com

For the first time, PDF copies of all chapters were on the Web available online for free, with a full PDF available at low cost. Printed books (both color and black & white) were still available for those that wanted paper. The release was announced on reddit.

For fun, I also made some T-shirts and mugs with the Dragonfly logo available for purchase:

Dragonfly Merch @ Spread Shirt

2019

A graduate student used Dragonfly as the basis to evaluate latency compensation for cloud-based game systems (e.g., Google Stadia), resulting in a publication:

Jiawei Sun and Mark Claypool. Evaluating Streaming and Latency Compensation in a Cloud-based Game, In Proceedings of the 4th IARIA International Conference on Advances in Computation, Communications and Services (ACCSE), Nice, France, July 28 - August 2, 2019.

2021

Another Dragonfly-inspired publication was accepted. This time, a chapter in a book on teaching about games and game development featuring IMGD 3000 Technical Game Development I using Dragonfly:

Mark Claypool. Technical Game Development I (IMGD 3000), Chapter in Teaching the Game - A Collection of Syllabi for Game Design, Development, and Implementation, Volume 2. Editors Richard Ferdig, Emily Baumgartner, and Enrico Gandolfi. Carnegie Mellon University: ETC Press, Pittsburgh, PA, USA, 2021.

The Name Dragonfly

Several ideas were explored en route to an appropriate name for the game engine. I have always had a fondness for Greek mythology, so the name Hephaestus was seriously considered. It seems appropriate that a game engine, a vehicle for powering and creating games, would be named after the Greek god of craftsmen and artisans. However, Hephaestus is a bit tough to say and even tougher to spell - not so accessible for the aspiring game programmer.

Turning to modern day engines, the name Hemi was considered. A Hemi is a combustion engine (such as for cars and trucks) where the roof of each cylinder's chamber is hemispherical in shape, hence the name. While Hemi by itself sounds good to the ear, it looks like something is missing, like the name is only part of a word (which it is). Plus, Hemi does not readily conjure up any images in the name itself.

An engine name that does roll off the tongue and feels complete is Evinrude. Evinrude is a long-established company that makes outboard motors, such as would power a small boat. The size and variety of such engines seems fitting for a game engine that is designed to power a variety of small games. However, the name Evinrude itself is undoubtedly copyrighted.

It so happens that Evinrude is also the name of a character from The Rescuers, a Walt Disney cartoon based on books by Margery Sharp. In The Rescuers, two mice travel into a swamp to rescue a mistreated orphan girl. The mice ride through the swamp on a leaf powered by the rapidly beating wings of a sturdy, loyal creature named Evinrude. Evinrude propels the mice to the girl, helps get her out, and ultimately brings everyone to safety. He is the engine for the leaf-boat. Evinrude is, as can now be guessed, a dragonfly.