bytopia (working title)

For the last few months I’ve been working on a voxel-based construction/exploration game in my spare time. Figured it’s a good time to share some of my progress.

A quick video demo here.

It’s all fairly minimalist so far, but the major features:

  • First pass on procedural world generation.
  • Large worlds (currently +/- about 2 million blocks in any direction, including up/down).
  • Day/night cycle with sun and moon, as well as a rudimentary atmospheric scattering approximation.
  • Normal mapping combining surface normals with a bevel effect on blocks to give everything a nice blocky look.
  • Rudimentary UI, including inventory, main menu, HUD, and a debug console.
  • Fairly polished movement controls and physics for the player (this is a big priority for me–games like this often have awkward-feeling movement and I want to avoid that).

A few technical details:

  • Handwritten in modern C++.
  • Renderer based on OpenGL 4.5.
  • Physics (just for cosmetic effect for dropped items etc) using PhysX.
  • Font rendering/layout using freetype2 and harfbuzz.
  • Windows-only so far, but built with ease of porting in mind.

Game Jam Framework

Over the past year or so I’ve done several game jams and really enjoyed it; I’ve based each of the games on a simple set of C++ library code I’ve been working on. I’ve kept intending to switch to Unity, but it never ends up happening; truth be told, although I can get a lot more done with Unity, I just have a lot more fun working in plain C++ with my own systems, and each accomplishment just feels so much more earned when I’ve done it more or less from scratch.

To that end, I’ve been working a bit on improving the framework code (‘engine’ is far too generous a word) that I’ve been using for the jams and for other hobby projects, including the GPU Game of Life and Pacman parody projects I’ve posted here, as well as all of my Ludum Dare and Indie Speedrun entries so far.

I’ll post about my progress here occasionally as I work on it. It’s not likely to be hugely interesting–more just a chance to get some thoughts down as I’m working on it. This first post is a summary of what I’ve got so far. Be ye fairly warned: much boring nerdery lies ahead–

My guiding principle in working on this has been to make it as simple and pleasurable as possible for me to write small-to-medium-sized projects; much of what I’ve done has been focused on that goal. There are a lot of things I’ve done that are tremendously inefficient. Some of them I intend to optimize, but others I’ll likely leave as-is for maximum flexibility. After all, the projects I’m creating with this aren’t going to be tremendously complex. Performance is a minimal concern, while ease of development is crucial.

A few of the more notable features:

  • A resource loader front end inspired by XNA’s that’s designed to make it as easy as possible to load resources. The implementation is internally clunky, but the interface makes loading resources into a handle (including reference counting, avoiding duplicate loads, support for resource load parameters like shader macros, etc.) as simple as this:
    auto example_tex = resource::load<texture*>( "textures/example.dds", optional_parameter_blob );
  • Basic 3D support, including a model loader built on top of the Open Asset Import Library, and a basic forward renderer with ambient, point, and directional lights (currently using Mikkelsen’s Torrance-Sparrow implementation).
  • A fast sprite renderer, using texture arrays and structured buffer instancing to blast potentially thousands of sprites onto a frame at high framerates. It’s in the early stages and is missing a lot of functionality, but it’s already really fast. (I know I mentioned I don’t care much about performance, but this is a situation where I thought being able to draw truly extreme numbers of sprites at once could be interesting for a jam. Plus, it was just fun to write.)
  • A basic input wrapper to make reading single keystrokes, held buttons, and mouse movement easy.
  • Simple FMOD wrapper (sound playback, streaming music).
  • A math library wrapping DirectXMath (the XM* functions) in easy-to-use classes (with operating overloading where natural).

A lof of the above still needs some work, and there are some major features on the todo list:

  • Gamepad support using XInput.
  • An input mapping system to map raw keyboard/mouse/gamepad input to in-game actions more naturally.
  • A tiled deferred renderer (ported from another hobby project I did in 2012).
  • Eventually, hopefully integration with Box2D for 2D physics and PhysX for 3D physics.
  • Screen space effect chain (at least HDR/tonemapping/bloom, motion blur, depth-of-field, color grading).
  • Some kind of basic animation support–at least rigid-body animation to start.

My mercurial repository for the engine code is public: http://bitbucket.org/otresnjak/eph-engine. I’ll continue to update it as I add new features. It’s missing the front-end code you need to actually compile/run; I’ll make that repo public as well once it’s a little prettier.

 

Week 3: Atlas of the Inner Sea

Inner Sea Map (hand drawn) header

In a couple weeks I’ll be running a Dungeons & Dragons game for a group of my friends, for the first time in many (many) years. I’ve really missed the thrill of creating my own world and guiding a group of unsuspecting suckers intrepid adventurers through it, so, as my third Weekly Project, I’ve written a few pages about the campaign setting we’ll be playing in.

(To my players: there are no spoilers here, so it’s safe to read, but you’re under no obligation to do so! I’m just posting it for fun.)

Atlas of the Inner Sea v0.1 (PDF)

Map of the Inner Sea (PNG)

As usual for my weekly projects, this is all very rough–even more than usual in this case, since I don’t write much these days! Rather than creating a huge world, I focused on putting a lot of details into a relatively small region, and making every single point of interest unique and worth visiting. I tried to consider the history and languages of the various settlements–language in particular is something that largely gets ignored in D&D games, so I think it might be interesting to take it a little more seriously. All that said, I’m sure there are all manner of typos, internal inconsistencies, and other issues here. (And the hand-drawn map is pretty embarassing!)

It’s entirely possible that this new D&D game will just end up being a one-off, but I’m hoping it becomes a recurring campaign, so that we can all get to know the Inner Sea and its diverse and eccentric peoples together.

A couple side notes:

  • I picked up a bunch of the new Reaper Bones plastic miniatures for this game. I am in love with them. They’re every bit as detailed as traditional pewter minis but much cheaper and easier to work with. They even look better unpainted, to my eye–it’s a lot easier to see detail on the solid, matte white surface. This is nice because it’s highly unlikely I’ll have the time to paint any of them (although who knows; maybe I’ll make it a weekly project). I also bought some of the new official pre-painted D&D figures, but I wouldn’t recommend them. They’re ridiculously expensive and of mediocre quality.
  • I’m still reading through the new 5th edition D&D rules, but I’m pretty pleased with them so far. They seem to have entirely backed off from trying to emulate MMO conventions (one of the many unfortunate decisions they made in 4E), and seem to be emphasizing role-playing a lot more in this edition. There’s also a two-paragraph section on gender, encouraging players to experiment with their characters’ gender roles, gender identity, and sexual orientation. Unexpected and very cool. I may post more about my impressions of 5E once we’ve had a chance to play.

Week 2: Save the Tomato

This past week I’ve been learning Unity‘s new UI and its 2D graphics and physics systems, so for my second weekly project, I’ve made a little game with it. It’s incredibly simple and rough, but here it is (click the picture to download; Windows only):

tomato

I bought all of the art assets for 25 bucks at the Unity Asset Store (Fantastic 2D Art Massive Bundle). The goal of the game is to collect as many coins as you can without letting the tomato touch the ground. See how high you can get the score! My record so far is 33. Supports the keyboard (space to jump) or an Xbox gamepad (A to jump).

This was about 5-6 hours of work (much of it spent watching the excellent Unity tutorial videos). The hardest part was figuring out character movement; it turns out it’s pretty tough to get solid-feeling movement in a physics-based game! I’m still not completely satisfied with it–it’s a bit floaty and not as responsive as I’d like–but it’s good enough…

Anyway, this is my first Unity game, so they’ll hopefully get better from here!

Phase Shift: Ludum Dare 30 Postmortem

ld30

This past weekend’s Ludum Dare game jam was my second (and the third overall game jam I’ve participated in); here’s my entry if you want to play it yourself.

My first thought was to take the theme–“Connected Worlds”–literally, and make a game around multiple planets–perhaps a simple 4X game or something based on orbits–but that felt a little too obvious. (In retrospect this was a good call, since there were quite a few games along those lines.)

My second idea was to do an action game where you can shift between different dimensions to avoid obstacles, from a top-down perspective using abstract, minimalist graphics (mainly to get around my lack of art ability). To add some tension, there would be an explosion you’d have to escape before it reached you. This felt a little more promising, so I decided to go with it.

I’d never done an action-oriented game for a game jam before; my previous game jam entries had been an adventure game and a puzzle game. So, how’d it go? Well…

What Went Right

  • Graphics: I experimented with a variety of colors and effects to make the minimalist visuals look pleasing, finally settling on the white/blue scheme for the twin dimensions because it made them both easy to see at once without clashing too much (especially during the animated transitions). I added a bloom effect to the scene for a little color, and then as a final touch put in a perspective camera with the two dimensions on different z planes; the parallax helps convey the separation between the active dimension and the inactive one.
  • Audio: When you’ve got almost no talent in music and sound production, it helps to have great tools. Thanks to the magic of Ableton Live and NI Komplete, I managed to put together some barely-passable sounding pulsing techno beats in just under an hour. The sound effects (all four of them) are just little musical flourishes written in Ableton and tweaked a bit in Adobe Audition.
  • Procedural level “design”: The procedural level generation algorithm is incredibly, ridiculously simple, but with some tweaking it managed to produce results I’m quite happy with. I tested and refined it quite a bit and am happy that it produces difficult but winnable levels at least most of the time.

What Went Wrong

  • C++/D3D: Every time I do a game jam I contemplate using higher-level tools but always end up going with what I’m famliar with. C++ and D3D are what I spend most of my time with at work, but it’s become increasingly clear that they’re greatly limiting my reach (to Windows only) and how much I can get done in a couple days. For my next LD, I’ll catch up with the rest of the world and use something like Unity. I’d like to never have to debug a GPU crash during a game jam again.
  • Inadequate framework code: Related to the above, but I hadn’t even implemented anything to maintain a consistent update rate, nor any support for postprocess shaders like the bloom–both things that took up time I could have used making the game better.
  • Focus: My eternal bugbear with these events. It is really, intensely difficult for me to stay focused on something like this for 48 hours straight. (For example, this distracted me for about an hour at one point.) It’s slightly disheartening to consider how much more I could accomplish if I could make better use of the limited time I have in game jams. Something to work on, I suppose…

I’m fairly satisfied with what I came up with, even though there are so many things I could have done better. Can’t wait for the next LD!

Week 1: μShooter

The Microview is a tiny Arduino-compatible device with a built-in OLED screen. It’s really nifty, and I’ve been looking forward to mine ever since backing the Kickstarter earlier this year. The other day it finally arrived, so as my first weekly project, I’ve made a simple game on it: a minimalist Gradius-style side-scrolling shooter.

The source code (an Arduino sketch) is available here! It expects an analog input (just one axis) on the Microview’s analog pin 5 and a button input (active HIGH) on digital pin 0. You could easily switch it to use two buttons for the movement instead of a joystick (it doesn’t even use proportional input). Here it is on a breadboard:

I love that the joystick alone is bigger than the μView.

Features:

  • Two types of enemies, a ‘diver’ than speeds toward you at high speed and a ‘tracker’ that moves a little slower but veers toward you when it gets close.
  • High score kept in EEPROM so it persists between runs.
  • No timing whatsoever, aside from a delay(10) in the main loop. Framerate is surprisingly consistent (and pretty good!) despite that. I’m guessing updating the OLED is the bottleneck.
  • Fills up less than half of available program memory and only ~800bytes of SRAM on the microcontroller, so there’s plenty of space for new features. 🙂
  • Text-based graphics in glorious 1-bit color!
  • Poorly organized, barely commented source code and bugs, bugs, bugs!

This was a quick one–about 3-4 hours of effort (including fixing the Microview). I’ll be participating in Ludum Dare 30 over the weekend, so I’ll hopefully have a second game to post by Sunday night! (Not on the μView though. It’d make it rather hard for people to review…)