One of those "smaller things," is this final project I worked on for my Computational Geometry class a year and a half ago; I wanted to release it publicly. My goal was to make "A teaching tool for other students to learn the Monotone Polygon Triangulation algorithm." The old version was buggy, but I finally got around to cleaning it up. If you want to play with it, you can find it here: https://16bpp.net/page/monotone-polygon-triangulation (source code is available too on GitLab).
I remember first seeing this book in an newsletter from the Pragmatic Bookshelf a year ago. It caught my attention because it seemed like a publication that was on a very niche topic yet fun. I didn't get a copy of it when it was released because I was busy at the time with schoolwork (and then forgot about it). Though a month ago I was down in on a weekend trip to D.C. and I saw it in a bookstore I visited; I decided to buy a copy since I have a lot more free time right now. Being interested in game development, computer graphics, and procedural generation, I found this book to be a delight to read.
The Code
All of the code for each chapter (except for a POV-Ray file) is in Ruby. My best guess why the author (Jamis Buck) chose to use Ruby is that he is a former contributor for the core team on the Rails projects. His GitHub page is also littered with Ruby projects, so I assume it's what he's most comfortable with.
If you have zero experience in Ruby, fear not, neither did I before reading this book. Not knowing Ruby should not be an obstacle to understand what is going on. As long as you have a lot of experience with many different languages it shouldn't be difficult. Most of the source reads like Pseudocode. Only a few times did I find myself checking the Ruby documentation (e.g. Array.sample, or Ruby Blocks) to understand something unknown. If you are looking to get familiar with the syntax of Ruby (or only to get your feet wet), I think this is a good start, but keep in mind that author's goal is not to teach you Ruby. Personally, I would have preferred the sample code to be in Python, but that's just me.
Of the tech books I've read, I've gone through many that have given me incomplete code examples (i.e. snippets) or code that breaks on running it. It's one of the most frustrating things out there! Buck and the rest of the team that worked on this project did a very good job on making sure all of the code worked as it should. I wasn't able to find a single issue with anything. All of the code provided were complete examples. A+
Everything builds on top of what you've done in the previous chapter, so I don't recommend skipping around. Lots of inheritance and code reuse, which is good!
The Content
Most of the book's pages are dedicated to the generation of mazes in a 2D space. In the beginning he talks about some simple algorithms like Binary Tree and Sidewinder, but later moves on to other methods that generate some more interesting maze designs. There really isn't much of anything in the realm of solving mazes outside of discussing Dijkstra's Algorithm. I really wish there were more included.
There was more covered than maze generation for rectangles. I found the sections on polar, triangle and hex grids really fascinating, but the Weave grids were the best in show (to me at least). There was also some pages for fitting mazes to odd shapes and designs.
In the later chapters Buck does show you how to generate a three dimensional maze (and talks a tad bit about 4D), but I found the representation of them to be a little difficult to follow (little red arrows are used to shift dimensions). I would have favored something with 3D graphics instead. That's a lot more complicated than 2D drawings and beyond the scope of this book though
One thing that was really well done was how algorithms were described with step-by-step drawings. More books really should be doing this. I've seen it too many times were only a single image or two are given when really seventeen should be provided to show a run-through of an algorithm. This made the algorithms really easy to understand without having to read any code.
Extra Cool Things
Something that I really appreciated is he included some code on how to display the mazes in a terminal window. These only work for the 2D rectangular mazes (the early chapters), but I still found it nice since I love ASCII art.
At the end of the book there are two appendices that cover the maze algorithms explained. The first one is an overview of what each algorithm does along with a picture of it. The second one goes over some benchmarking/statistics of the various algorithms; very useful.
Final Thoughts
This book was worth the money I paid for it. I don't think I'll be using anything I've learned in it immediately, but I know I will sometime down the road in my video game endeavors. It's not a definitive source on mazes but a really good starting point. I really would have loved some more chapters on maze solving. One on interacting with the puzzles we generate would be cool too, but that falls more into game programming. It has also done something for me that I've never expected; opening me up to Ruby.
It's been a while since I've read a programming book that wasn't overly dry. Everything flowed nicely and kept me interested in learning what was coming next. I really recommend reading this book if the subject matter sounds interesting to you. It will be enjoyable.
Over the last semester, I've been working on a game engine. It was meant to be a personal challenge for myself, to see if I could make my own game engine with some bare materials. Those being C++, OpenGL, and Qt. I wanted it to be more though. Seeing as most professional game engines these days (developed by community or company) feature some sort of scripting engine, I decided to make my own scriptable game engine.
After some troubles with trying to embed Python & Lua inside of a C++ dummy projects, I discovered this thing called ChaiScript. The tl;dr is that it's a scripting language for C++ that's dead simple to use. I decided to use it for my project since it gave me a no hassle way to add scripting features to my project. It was dead simple as "include the headers," and "give me a pointer to your C++ function/variable, and tell me what you want to call it."
Of course with simplicity, comes some cost. One of the first things for example are the long build times. If you statically include ChaiScript (which is the simplest way of using it), expect to take a small break when compiling. This can be easily remedied by dynamically linking ChaiScript's standard library and including a .dll/.so file alongside your executable. I did this when developing Masala.
I also ran into performance issues with ChaiScript. At the current version (5.8.1), the language is executed using an Abstract Syntax Tree. While this is necessary for parsing a language, using it to run code is much slower than it could be.
Enough about ChaiScript, let's talk about the engine itself, Masala!
Masala was built using C++ (14), Qt 5.x, ChaiScript, and OpenGL. I had the goal of trying to create a reusable game engine where you write all of your logic inside of ChaiScript files. It follows a very lose XNA/MonoGame-like pattern. Right now it features:
- 2D
- Cross platform (Built with Linux)
- Featureful sprite object (with animations!)
- Tilemaps (Flare maps)
- Basic sound effects
- Keyboard Input
- Interactive debugging terminal
It's pretty simple. I mean, very simple. I don't think it stands up well to other engines that are out there, so I really consider it to be an experiment in using ChaiScript for a game engine.
I implemented two simple games, one being a clone of the classic Atari Pong:
And another more original one I've dubbed "Grab n' Dodge:"
I would say that I accomplished my goal in writing a game engine. Something that I have never done. As for the cross-platform part, I was able to get the code to compile on OS X and Windows, but had some trouble upon running it. One of my friends said that he was able to get it working on OS X, but I haven't seen the proof.
If anyone wants to help me getting this running on Windows or OS X, contact me. Since it was made using cross platform tools, it should work on all of the OSes Qt & OpenGL support.
And last, you can find the official code repository over here on GitLab. It's GPLv3 licensed.
Back around mid to late July in 2014 I set out to create Blit. One year on now (as of last Wednesday), I've made a lot of progress from practically nothing. Thinking back I ask myself “why did I want to make Blit?”
I've made many other projects before. Some of them successes whereas others were really failures (cough buzz cough). Those projects had something in common. They were short, small, and contained. When I look back on all of the stuff that I've made, I noticed that there was nothing that I could call a “grand,” or “large,” project. I wanted something that I could call a major project that I built. More importantly I wanted to know how to manage a larger project; something I've never done before.
So I set a goal for myself: “Make something large. Something that you can never really call 'complete,' but work on it for an entire year.” That's what I did. I had nothing more than a silly GitHub streak to motivate me. It now says “371 days.” There were a few days where all I did was just update a TODO file, add some extra documentation, or ones that I didn't want to work on it at all (but I did anyways).
Blit still isn't really what I originally imaged it to be. Some sort of 2D Animation solution for pixel art and larger things (and hopefully pencil testing too). And I'm still not sure 100% what I want out of it. I consider what I've done so far to be nothing more than a prototype for a future vision.
I've met my goal of “work on something for a year,” but I plan to still chug along with it until I feel that I'm done. It's been fun so far.
Here are some stats:
- 371 days of continuous development (avg. one hour per day, more on the weekends)
- 75,868 additions / 47,902 deletions
- 7,846 lines of code (core application, mostly C++ w/ Qt)
- 2,887 commits
- 352 tickets
- 247 closed
- 105 open
- 43 more issues until the next one
- 12 (active) branches
- 1 (and a 1/2) milestones completed
- 1 contributor (me)
This is what my network looks like.
Cheers.
I was planning on doing another post after Imagine RIT, but I've been pretty busy. I was able to display off MEGA_MATRIX there along with a small fork of Blit where you can create animations then upload them to the device. It's was pretty popular with the kids. I'll be posting some of the creations soon enough.
Speaking of Blit I have been still working on it daily since the first release back in February. The big thing that I had to do was refactor the underlying monolithic Animation module into a more flexible and reusable system.
Some small stats:
- 3.5 months
- +1,100 lines of code (exactly)
- 655 commits
- 51 tickets (felt like 151)
I've also done a few other things like add a shape tool, line tool, fill tool (you know, the basics), and a few icons. There are many other features that I want to add too like exporting to GIF and video files. I think I'll be able to get them done for P-2.
