• 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

A few updates!

Sign in to follow this  
Followers 0


Hello GameDev! It's been long, far too long since my last entry. This is actually a new journal, because I've moved a bit from rendering lately for a bit to go back into my older, preferred hobby - cryptography, and generally screwing around writing code that nobody will probably ever use. Though I will openly admit this type of programming has immense educational value.

Back in June 2012, I started working on a cryptography library, called Ordo. A few of you might catch the reference to Neil Stephenson's Cryptonomicon. From the start it was never meant to be an all-encompassing library, so I restricted my scope to symmetric cryptography (that is, no RSA or elliptic curves, no SSL/TLS stuff, just low-level block cipher/hash function/etc code). Why? A few reasons:

1. I do not feel qualified to implement some of the more complex stuff, and I would not be a responsible developer if I released potentially unsafe code. There are a lot more edge cases to check, and it's definitely far too much work for a single person to take on.
2. Having a well-defined, bounded and achievable scope is the cornerstone of every successful project. It helps mitigate the infamous "feature creep" stage, and keeps you focused on your goals as much as possible.
3. Symmetric cryptography is a lot more interesting to me than the rest, even if all the cool kids say otherwise.

Ordo was initially created as an alternative to OpenSSL, which can be a nightmare to work with whenever you run into a problem (I think anyone who has ever used it for a non-trivial task can attest to that), and as such always had three main goals:

1. good performance and cross-platform compatibility (what is the point of creating an inferior product?)
2. easy to use and conventional API (heavily influenced from OpenSSL, with a few improvements)
3. good documentation (the OpenSSL documentation is at best sparse, and at worst nonexistent)

As such, the library was written in portable C89 with system-specific extensions. I'm sure many of you are already shifting uncomfortably in your seats, thinking "why not C++". Well, firstly, C++ doesn't make for very good libraries. Try exporting C++ classes from your library and see how many languages manage to interop with it (hint: not many). Then, there's the problem that C++ binary compatibility has always been a gotcha whereas C binary compatibility is fairly well understood. Finally, C is the lowest common denominator, and simply works everywhere. You can link to a C library (sometimes even statically) and expect it to work, in any language, on any compiler, on any platform. Furthermore, because C is comparatively simple, it was easy to get the boilerplate object-oriented code (involving function pointers and abstraction layers) out of the way and get down to actually writing algorithms.

Also, because performance matters, I decided to have code paths involving raw assembly code (most of which I wrote myself). This complicated things a bit and made for interesting challenges, but was overall worth it. Assembly is cool, and the performance gains are actually worth it most of the time. Of course, this is only used in the most performance-critical parts of the code. But you routinely see at least 120% speed improvements, sometimes up to 300% for particularly clever code. That makes a real difference. Of course there is always a standard C code path, and those assembly implementations are only enabled whenever the processor supports it.

The code itself is documented with doxygen. It's a bit hard to keep up sometimes, but it is actually reasonably well updated. Documentation has always been the hardest part, a constant struggle between consistency and redundancy, but I am determined to make it work in the end. I don't think I could bring myself to write a library without any documentation at all. I take great pride in making things work consistently and elegantly, and a complete and up to date documentation is part of all that. Code samples are important too, but those generally come at a later stage, when the library is sufficiently mature to make the samples meaningful (though I have already implemented a couple).

Finally, a very important part of library development is design. It needs to make sense, be well-structured, and not have stupid inter-dependencies. This is a header dependency graph for the entire library, at its latest version. The overall design has been refactored well over a dozen times, and I find dependency graphs an excellent way to eyeball the general code structure and a first step to spot any possible candidates for refactoring.


The internal dependency graph (of the source files) is more complicated, but the above is what is actually exposed to the user. As you can see, I ultimately went with a modular design. It turns out many of the features of the library can be stripped out without issues, when running very specialized builds or working in constrained environments. Also notice that the graph does not include any actual algorithm references (there are no SHA-256 or AES headers, for instance). This means the abstraction layers are working, and shows that the library scales.

As of the time of this writing, Ordo runs on (at least) Windows 32-bit, Windows 64-bit and all Linux distributions, on x86 and amd64 processors. I have plans to add BSD compatibility but a few issues need to be resolved first, and Mac compatibility is actually unknown (I have never tried, though I suspect it will not be much work to implement).

The github repository is at https://github.com/TomCrypto/Ordo.


All in all I have to say that writing a library of a larger scale than your average python script is an interesting learning experience and I'm learning a lot about software design/maintenance, even if I don't expect the library to ever become popular (plus cryptography is more or less saturated with existing open source or proprietary libraries, and adoption rate is extremely low by nature).

There is still a lot of work to do, and I think the finished product might be at least portfolio-worthy smile.png

By the way, contributions are highly welcome, as always (should you be interested in the field)

EDIT: currently working on Mac compatibility, and there are a few API improvements in progress.

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