• 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

Entries in this blog


Music FTW

"It'll only take an hour and it'll make this feel like a real game," I said last week. I was off by an order of magnitude on the first count, but it was worth it.

OpenAL streaming is tricky. The Programmer's Guide example was sketchy as hell, so I took an example from the OpenALSoft source, adapted it to use libsndfile to read OGG, FLAC, etc, and rewrote it to fit my game. My original SFX code was crap so I rewrote that too, dropped a dependency (ALURE: fancy C++ OpenAL helper lib), and added a Playlist class and playlist scripting in the scene parser, with per-track repeat count & volume. Good to go!

One slight problem when playing OGG: I hear a crackling noise whenever there's a peak (clipping) in the input waveform. I've noticed that in some released games too. I narrowed it down to OGG+sndfile and did some searching... some MuseScore devs figured it out 2 years ago: it's a libsndfile bug that'll be fixed if version 1.026 ever gets released. I could take my chances with the dev version. But... LibSndFile requires libogg & libvorbis which I never got to work in my Windows build; it's trouble. More likely I'll switch to stb_vorbis if it works ok; there'll be some extra buffering complexity between it and OpenAL but it's just one C file. Word.

And I did some recording this morning...

Here's a preview > https://soundcloud.com/tnovelli/fine-companion

I don't know about you but I can listen to that over and over. I think it'll make the final cut for one of the safe (-ish) areas in game. Apparently it's from an early 1600s play about a douchebag slacker guy, however, it reminds me more of the Companion from Firefly... and what RPG would be complete without the oldest of professions? :D

1 down, 5 more like that on my list, and 10+ originals to go... a few in that style, some edgier stuff for dangerous areas, heavy metal for combat, and foreboding silence in the woods, swamps, etc.

And... what a difference from the old days! Remember when music was all tinny OPL synths and MOD/S3M/IT?


Color.. not that simple

Last year when I started drawing characters for my "Cult RPG", I noticed how the standard RGB and HSL/HSV color pickers are no good at selecting real-world colors. So I studied up on color perception. The good news: this problem was solved 100 years ago. Bad news: software developers are still in the dark. So, fellow devs, check it out...

I won't go into all the details. Here's a good visual overview of the "color spaces" I'm talking about: http://www.colorbasics.com/ColorSpace/. And if you want to read some code, https://github.com/fponticelli/thx.color looks like one of the more complete colorspace conversion/manipulation libs, but I haven't looked closely.

To see just how bad RGB/HSL are, try to draw your skin color in a paint program. Using HSL, you have to guess at the closest hue (red-orange, if you're lucky) then adjust the saturation & lightness toward a tan or brown. Then tweak H toward red or yellow, then readjust S and L. Unfortunately there's no way to add a little pink, or vary between tan and brown; you have to move all 3 sliders blindly.

The crux of the problem: HSL shows a 2D gradient of shades for a given hue (e.g. black-white-orange) and a 1D scale of hues (a rainbow).

Can we have a 2D view of hues and a 1D black-white scale?
Yes. The old XYZ colorspace from 1931 does exactly that. LAB and LUV and LCH are improvements on it.

Color picker implementations

I wrote a JQuery perceptual colorpicker plugin (pictured above). I use it in my homebrew game graphics editor. It's not great but it's an improvement.

GIMP recently added one. It's too small and glitchy as of GIMP 2.8.10, but it's a start. I think Photoshop did it better and slightly sooner.

The ideal would be a huge perceptual colorpicker filling half the screen (with room to view your artwork in the other half), zoom controls for fine-tuning the hue, and smaller RGB/HSL/etc colorpickers so you have all the options.

What matters

RGB monitors can only represent a subset of the colors we can see in the world?
Yes, it's true, but there's nothing you can do about it when you're making game art.
"Wide gamut" monitors can represent more colors...
Most LCD monitors have bluish white backlight LEDs, but you can get professional color-calibrated monitors with wide-spectrum backlights and IPS panels; basically they fill out the red side of the spectrum. I have one (Dell U2413) and it's nice... a huge improvement over cheap monitors. But for gaming I'd opt for a high-refresh TN panel instead. I have one of them as well, and I can barely tell the difference, and I have eagle eyes (when I'm wearing my glasses).
So, a "pro" monitor is nice to have, but any decent monitor will do.

Which colorspace - LAB vs LCH vs LUV?
CIE LAB is the standard colorspace you'd use to tell someone an exact color. But the math is more complicated. LUV is simpler and corresponds more closely to RGB monitors. LCH is a more uniform version of LUV, with fancy math.
LUV is good enough for picking colors for game art.

Saving colors... RGB or perceptual colorspace coordinates?
Standard 24-bit RGB "#aabbcc" notation is adequate for any color a monitor is capable of displaying.

Colorspace conversion math is overkill.
To convert RGB to LUV (etc), you do a matrix transform to XYZ then another transform to get to LUV.
That's overkill for a color picker. I could probably come up with a simpler colorspace with a one-step RGB conversion formula but I haven't gotten around to it. Maybe someone else has.

Finishing the job

I've been getting back to my main game project after a few months of home renovations. It started when I bought some drums and moved my studio to the basement. Then I had to put in a sump pump. Then I was on a roll so I started scraping off the ugly ass 50s wallpaper in my hallway, patching up the century-old plaster, painting, and wrapping up some other little unfinished projects. It never ends, but I like to alternate between programming and manual labor so it's allright. And it's sweet having a basement studio/workshop, away from the office. Keepin' my work and [s]play[/s] ..other work.. separate. smile.png

So I finalized the story/dialogue system, complete with speech bubbles... layout needs work but the UI is 100% functional. And I overhauled the rendering pipeline. Not much to show in that regard, but there's an OpenGL stencil mask around the eyes to clip the iris & pupil, and sprites are split into tiers from back to front (backdrop, scene, set, actors, objects, etc) kinda like a theatre production. That was mostly a matter of changing the scene file format and parser. There's not much of a system to it. The render loop is one big special case, with potientially 2 or 3 procedural graphics tiers mixed in. Combat collisions are only actor-vs-actor and actor-vs-object. Motion collisions are only actor-vs-set. Shrug. No need to over-generalize.


There are problems I decided not to solve. This game is what it is: pure 2D, fast paced, close-up, action RPG, with freakin' vector splines in realtime... that's enough. I could go part-3D and rely on depth buffering to solve draworder problems, since it has become clear that my old HTML5 Canvas version of this engine is hopeless performance-wise. Some glitches are acceptable. And I don't even want this game to look too sexy. People like us can't compete on that front, when every other thumbnail on GOG, Steam, Youtube and Netflix is T&A clickbait... which means crap content anyway. So in a way that makes creative decisions easy: when in doubt, female NPCs shall wear pants. Animating those skirts is a pain in the ass by the way. Long dresses, forget it except in scripted setpieces. I tried, I failed. This is a very limited engine. It's meant to be fast and not to overshadow gameplay.

(I haven't completely given up on HTML5... Firefox and Chrome are bloated and rotting, but now we have PaleMoon (salvaged from the wreckage of Firefox) and some other serious contenders. I don't bother looking for HTML5 games to play anymore because 99.99% of them are utter crap; but if I happen to hear of a good one I'll give it a chance. I'm not hopeful about HTML5. It's not my first or second choice... but it's still an option... and I'm still doing a little maintenance on HTML5 projects I started.)

The other day I felt inspired to crank out a backstory. It no longer takes place in a cult (glad to be rid of that old RPG cliche!) ... but it's still governed by a Machiavellian inner circle, and it's still a microcosm of society - the concept that spawned this whole project.
Time to get on with maps and gameplay... then writing, art, music... and release it. New ideas can wait til the sequel, if there is one.

I'm tempted to make a classic turnbased CRPG next... with crappy (but vibrant) graphics... not even iso. It's in the planning stage. Here's a very early prototype: http://tnovelli.net/junk/rpg3a

The new language

Making a new language:

  1. brainstorming, code mockups
  2. feature triage
  3. design specs
  4. experiments
  5. implementation

I've been iterating on the first 3 steps for a year, my specification is pretty well nailed down, and now I'm laying down plans for a compiler. Turns out I'm closer than I thought. In 2010 I was experimenting with a Lisp-APL hybrid, then I had some doubts about Lisp so I set it aside unfinished. But the main parser/compiler functions were working, and that's all I need for a gamedev language without Lispy stuff like closures and GC. However, for games I'll need the ability to write game code that links with C/C++ libraries, and to that end I dug up some old ELF loader/linker code from my 2003 osdev projects. Still works, just needs some 64-bit support. So I'll do a few experiments with that, let the design stew for a few months, then try to bang out a working prototype in a week whenever I'm able to clear the decks.

Gotta say gamedev has been incredibly liberating. Compilers are easy compared to games and game engines. Text files in, machine code out, no big deal! biggrin.png
I'm getting ready to combine and improve some HTML5 Canvas stuff I prototyped two years ago - Ocean Melee / Great Guns and the 2D character animation modeler for the future "Cult RPG" (crude demo here). My ultimate goal is to create complete online editors for both games, and other games... a separate editor app for each game, and some shared core libraries.

For starters, I want an online map editor for OMGG so I can start recreating historic naval battles. The old map+ship graphics are Inkscape SVG... it kinda works, and I've written SVG load/render code in both JS and C++, but I never felt right about any of it. I vaguely remember a major WTF about certain "modern" browsers failing to parse SVG (XML) correctly. Anyway, I only need to display scanned map images, scale/rotate them into position (rubber-sheet orthocorrection not necessary), and trace over them with polygons and splines. Ships will just be splines, with hidden collision polygons. No need to import the old graphics - it was just rapid prototype stuff.

The character modeler lets you draw spline shapes, choose fill/outline colors, and edit some metadata. There's also a bunch of skeleton animation stuff tied into it. It saves/loads JSON files via a tiny PHP backend.

I've also ported the cultRPG spline renderer (used in modeler & demo) to C++, which forced me to use "primitive" data structures... namely lots of interleaved [x0,y0, x1,y1, ...] point arrays like OpenGL requires, which I'll need in JS if I port any of this stuff to WebGL. It goes against a lot of compsci theory and best practices, but this is definitely a change for the better.

Server stack constraints: assume only PHP 5.4+ and MySQL. NodeJS should also be available for some build scripts.

Well, that's what I've got to work with, so here's the plan:
- Rewrite the modeler.
- Animation stuff as a separate library. Don't need it cluttering up the OMGG editor. Need it for cultRPG, so do implement & test it - don't kick it down the road.
- Shape editing library - splines (existing), polygons, images/textures.
- Save to MySQL instead of JSON files. Versioned structures TBD. For now, KISS.
- Incorporate OMGG build scripts into the PHP backend. One-button test build & launch game in new tab.
- Incorporate cultRPG model format exporter (because C++ + JSON = headache).
- PHP+MySQL user account system.
- Access control, just enough so I can let a few artists into the system. smile.png
- Deploy to a public server and get crackin'...

P.S. - those dashed red and green lines you can see if you click the map thumbnail - I don't even want those anymore. Just the shoreline. I had an idea of tracing 5-foot and 20-foot depth contours and LERPing between them to see if you've run aground. That way a Navy frigate could wreck on a reef while a shallow-draft pirate schooner escapes, for example. But it just makes the gameplay confusing, so forget it! :D


I just read @rbritt's journal entry about scripting... and I said, check out LuaJIT. If in doubt that's what I'll use for my C++ game. But I really want to roll my own. I've been messing with language design & implementation for 20 years on and off. I've done it before, I can do it again. Might even be practical. But it won't be anything special. So why bother?

Well, coding a simple compiler is nothing compared to coding a substantial game; weeks vs years. Being a game script lang helps keep it simple. And I don't have to worry about a user community; it's just me and my game and a few demos.

Ultimately I hope there'll be languages that are less than ideal, but popular and standardized AND simple enough that any decent programmer can write a compiler that'll run any code written in that language. Forth was kinda like that, and I think we can do better... simple but more mainstream. Unlikely, but maybe my language will be a big hit. Maybe I'll find some other language I like, write a better compiler for it, and suggest a few tweaks. Maybe other people do all that before I get around to it, and I catch a free ride. Doesn't really matter. Any of that would be better than the most likely outcome, that all languages will suck forever and ever, so get used to it. But that's no reason to give up. If this problem is ever going to be solved, who's gonna solve it? Gamedevs!


Sweet... I've passed another architectural milestone. Archery required a bunch of details: weapon slots, Bow subclass, lightweight Missile subclass, gravity, collisions. It's all working as intended. Now the other weapons will be a cakewalk.

Next, movement controls... it's time. Then sound and scoring. That's all this game needs to start being fun.

(Why so many arrows, you ask? That's how it was really done in combat, according to videos of Lars Andersen, Turkish archery techniques, etc... pretty cool!)

P.S. - I finally added a pause button.. handy for screenshots!
My animation system needed rethinking, as it didn't quite fit the gameplay, plus it was overcomplicated. So I let that stew all week until I had something worth coding in C++ yesterday.

First step was to ask: what controls do I want? A: Simple ones!
Just gamepad Dpad+ABXY or keyboard WASD+arrows. Nothing analog. Aim by moving around, emphasis on timing.

hmmm.... 4 attack buttons, 4 arms and legs.
Not QWOP-style though - running's instinctive! So, A=left jab, B=right cross, Y=kick... or hold the button to grapple... X to pull your opponent toward you. All kinds of *natural* combos emerge. Down-up-B=uppercut. Y-B-X=trip. A+B=head grab, X+Y=knee smash... awww yeah!

With this scheme, animation makes sense. Originally, I had a stack of animation cycles - stand, run, jump, sword swing, sword thrust - which could each control any combination of bones in the skeleton. Now there's ONE looping "base action" cycle (stand, run, fighting stance) for the whole body, and ONE temporary override cycle (punch, kick, etc) for each arm and leg and the head+torso. Temporary overrides correspond directly to the attack buttons... although some attacks control 2 or 3 limbs. For instance, the torso leans forward to give right-hand attacks the same reach as left-hand attacks. Realistic? Hell no - but it *feels* realistic. I take that as a damn good sign I'm on the right track. smile.png

Next: collisions...

In the demo I made for LD26, I did line-intersection tests between all bones of each character. Weapons dealt damage, and *any* collision caused a 50-pixel knockback. You can't walk past each other. It's also too easy to impale yourself on the enemy's sword with them even trying. So... now I'll *only* do collision tests on *attacking* weapons (including hand/elbow and foot/knee)... and I want more body hits, so arms will only protect you if you execute a well-timed block (X+A?)
Then... gore!

I just remembered... in HTML5 Canvas I showed cuts as red dots because I couldn't draw accurate cuts without killing performance. If I just drew a red line across on arm, it'd stick out into the air. Now, with the OpenGL rendering technique I'm using in C++, I've got this lovely stencil buffer to crop it. So that's cool. And if I can be a really productive coder... a powerful slash delivered to a wrist, elbow, neck, etc, will sever said appendage and blood will spurt out of the stump -- in the adult version with the badassery knob cranked up to 11. ph34r.png
Did some more porting this weekend... C++ version is now able to load & render a character model from my HTML5 Canvas demo (far right screenshot, in Chrome). A few glitches to debug, but it's basically done. Performance is better indeed... 3% CPU with one character, probably 10% during busy gameplay -- versus 60% in HTML5.

Next: animations, keyboard/gamepad controls, and collisions.

Hoping it won't be a total pain to do a Windows build so I can run this on my laptop at a local gamedev get-together on Tuesday.

Some concept art

Feeling inspired. Made a few Inkscape mockups & freehand sketches for my most ambitious project. It's a sidescrolling RPG with intricate AI and hand-to-hand fighting.
Unlike my topdown sea shooter, this game is too demanding for HTML5, so I've begun porting the engine back to C++/OpenGL. This allows for easily 1000% more visual complexity if needed, and I could use some shader magic for fog, blur, lighting, hair, etc. I have a decent browser-based drawing program I'd like to keep (I'll switch from Canvas to WebGL if necessary). That would be a distraction at this stage, though, so I'm using Inkscape/GIMP/etc to explore a wider range of possibilities.

Why line art?

A) 3D modeling is too much work if I'm doing all the coding, music, and artwork - which seems like a healthy assumption if I intend to finish.

A2) 3D bores me. I must be getting old.

A3) Everyone's doing hyper-realism.

B) ANOTHER neo-retro fat pixel game? I don't think so.

C) Steve Yegge's 2nd to last blog post in which he points out the cartoonish cel-shaded graphics in Borderlands. Uhh, yeah, that's 3D, but it harkens back to traditional animation and comics. I'd never obsessed over that stuff at all, but it's a style I've long admired.

D) Around that same time, March 2012, I'd been fooling around with HTML5 enough to realize it was just about good enough to achieve that look in 2D games. Maybe not quite, but it got me experimenting.

E) I actually had the (2D) drafting chops to do the artwork.

F) I was blissfully unaware of "vector art" Flash games (which mostly use cheesy bitmap cutouts exported from Illustrator) and the fact that hardcore gamers kinda despise that whole genre

So it's just a challenging little niche I stumbled across... an interesting intersection of code and art.