Tales of the Rampant Coyote

Adventures in Indie Gaming!

A Couple of 2D Game-Making Options

Posted by Rampant Coyote on November 8, 2012

As most folks reading this are well aware, 2D games have made a resurgence, and it’s not restricted to indies. Nor are indies restricted to 2D. But modern technology has really blown the doors off the potential of 2D games from the bad ol’ days where developers had to hand-roll assembly code routines for sprite rendering and pull off all kinds of crazy tricks to fake smooth scrolling. (See: Commander Keen).

One of the reasons I’m so pleased with Unity 3D is how easy it can be to make 2D gameplay with the engine. You can simply set a camera to orthographic projection, jam everything into Z=0 (or not, for sorting purposes), and viola! 2D gaming done easy. But there are many more tricks you can do to create high-quality 2D… including some tricks borrowed from the 3D world. And then there’s a whole world of 2D gameplay using 3D graphics… featured as one of the main tutorials available at Unity’s site.

For a few ideas, I’m going to refer you to this great article by Size Five Games (Ben There, Dan That) on using Unity for 2D gaming:

Using Unity 3D for Swindle’s 2D

 

At the last Utah Indie Night, the presentation was on HTML5 gaming. A lot of indies are going that direction. I confess, I really don’t know much about it.   One of these days, I’ll have to cobble together a Pong game in HTML5, and see what I can do. Will it replace Flash? A lot of indies are banking on it, although right now support for some APIs (particularly WebGL) is still spotty – which could mean having to write a game multiple times for multiple “platforms” (web browsers). But it does seem to be the direction things are going. Is it fast enough to do really cool things? Again – it looks probable. Here’s an interesting anecdote:

HTML5 Games Faster Than Native?

Now, this is not strictly true, of course, because it’s ALWAYS possible to get native code to run faster. But it was an interesting discovery, nonetheless, with possibilities ranging from an optimization in WebGL that DirectX could do well to take advantage of, or simply that the developers were more conscious of optimization working in JavaScript than in C++. But whatever the reason, they were able to not only match the performance of their native-code engine, but far surpass it.

Of course, there remains several other great options to game developers looking for 2D game development technology. I’m still kind of fond of Torque Game Builder, though I don’t expect to ever use it again. GameMaker has REALLY made some impressive strides lately, and is priced in a pretty convenient indie range (including the all-important “free” price point). And hey, an HTML5 export option is available! Monkey Coder is another option I’ve heard some professional indies embracing. There are dozens more.

As for me… I think I’ve been won over pretty solidly to the Unity camp for the time being, for 2D or 3D.  As much as I like to pride myself on being able to program on anything, for the purpose of actually getting product out the door I’m best served by sticking to one technology and mastering it.


Filed Under: Programming - Comments: 14 Comments to Read



  • Albert1 said,

    The little game I’m working on (well, at the moment is really only an engine and an editor) is written in ANSI C+SDL 1.2, while the editor is in Python+Tkinter – as soon as I’ll have something satisfying I’ll post some pics on your forum. I’m however considering other languages for my future projects, precisely Standard ML (the MLton optimizing compiler looks very promising) or ATS: it seems their performances aren’t bad at all. These days I’m getting more and more interested in functional programming. Another interesting niche language is the old Icon. Frankly I think there will always be market for native applications. Now and then I happen to like D – it’s how C++ should’ve been. It also has deluxe support for floating point arithmetics. However, it’s still too complicated, OOP heavy for my tastes. I think we’ll see a renaissance of software rendering – honestly, they can’t require developers to develop their software in 3+ OpenSomething API, each one with its own custom “shading” language. I’m not saying GPUs will disappear – I just think they should be one of the many resources accessed by a VM a single – or two, let’s be generous 😉 – languages may target. Something like having a JVM that distributes you program computations on whatever CPU/GPU/GPGPU combination users have. Tried Haskell, didn’t like it. Tried Erlang: even though my knowledge of it is limited, I’d rank it 2nd, right after Standard ML, in my functional languages hit-parade.

  • Felix said,

    Um, you seem to be equating HTML5 with WebGL… while talking about 2D games. But the first and still primary API of the HTML5 canvas is 2D, and that works in any HTML5 browser, on any OS, and should benefit from 2D hardware acceleration even with the lousiest available drivers. And while HTML5 support for sound and input is still limited, the 2D graphics API in the canvas is amazingly powerful. I found myself struggling to port my games to other platforms while maintaining a decent amount of visual effects.

    Do try it, just for kicks. It should be interesting.

  • CdrJameson said,

    I love the many available options for game engines, but something in me prefers code libraries.

    Unity (& flash before it) make me oddly uncomfortable by being basically a graphics editing package with code in there somewhere, if you look hard, so as not to scare anyone off.

    Also much as I use many lovely, modern languages (I use Monkey for my quick stuff) I often find myself back at C++ just because of the years and years of good quality supporting tools (Debuggers, static analysers, editors, libraries) make life easier and code more reliable.

    Guess I’m just getting old…

  • Rampant Coyote said,

    CdrJameson – I am not gonna put down anybody who does it the ol’ fashioned way. 🙂 My first commercial indie game, Void War, was all me, C++, and DirectX.

    I will protest slightly about Unity – at the level I’m working in it, it’s all code (I use C#). The editor is a very useful tool for getting some stuff put together, but I spend most of my time either in the code editor (MonoDevelop IDE), or testing (as usual).

  • Xenovore said,

    Unity (& flash before it) make me oddly uncomfortable by being basically a graphics editing package with code in there somewhere, if you look hard, so as not to scare anyone off.

    I’m a little boggled by this statement. Uncomfortable, really? Me, I’m stoked that most of the heavy lifting is out of the way! I don’t want to re-write a renderer, and an audio library, and a network library, and a scripting language, and… etc. I can get to making a game instead. Not to mention, even with a top tier engine like CryEngine or Unreal, you still have to write code; there’s not ever going to be a “Make My Game” button.

    Back in the day, yeah, it was fun coding to the metal in 6502 assembly language, or learning OpenGL by writing a rendering engine, but what’s the point these days? There are some great engines and libraries out there; and, unless it’s to learn how something works, it’s just a waste of time and effort to ignore those and reinvent them.

  • Xenovore said,

    Having said all that, maybe the original point was that Unity3D doesn’t have access to the engine source code, and I’ll agree, that does bug me as well. (Which is why I haven’t jumped on that particular bandwagon yet, preferring Torque 3D.)

  • Maklak said,

    So SDL is no longer an attractive option, I take it?

  • Rampant Coyote said,

    I dunno if it’s an UNattractive option, but there are a lot of really cool, shiny toys in the toybox now than in its heyday.

  • CdrJameson said,

    @Xenovore

    I don’t mind reusing stuff, or not having to write things. I’ve been happy to use STOS, DirectX, OpenGL, SDL, Allegro & Ogre in the past. I’m just a bit wary of things that aren’t a collection of text files. Source access definitely helps.

    Probably bad experiences with ‘graphical’ tools in the past.

    Apple’s Interface Builder is a hideous example. Pretty, pretty to make things, but its cryptic save format means that you’re in for a fun time when you need to slightly move an interface element on each of 120 screens.

    RPGMaker: again, binary save format makes synchronising work over multiple developers essentially impossible. Luckily source access makes writing a text exporter at least possible (you have to use the built-in text editor, mind)

    GameMaker: Gave this a shot a while back. Thought I’d make a nice, simple vector-based game I had in mind. No dice though – it simply had no concept of vectors. Also had to make some modifications to tools someone else made with this, which was… Interesting. The joke in our studio was that it was the world’s first write-only system.

    Blitz tech: used this one for a project, and it actually worked pretty well, although we used it mostly for managing the pretties between the actual game bits. Was initially a pain moving pre-existing code to the engine, because it was doing it one way (main game loop model) and the game engine dictates that you do it their way instead (multiple scenes with defined interfaces). Would have been much easier if we started from scratch in the engine.

    I’m going to give Unity a go though, simply because so many people like it it can’t be all bad. Wish 3D graphics could be as standardised as 2D though. Bloody vertex ordering…

  • Albert1 said,

    @Maklak: I like SDL, as I wrote above I’m considering to use it commercially, however it’s really only what its webpage says: a thin layer on underlying OS&APIs – you have to implement all the rest, unless you start mix&matching lot of other libraries, but IMHO at that point an off-the-shelf engine is better. I’m more than happy to roll my own engine/renderer – it’s the part of gamedev I really like, which probably explains why I have hard time staying focused on the remaining part that still has to be written :). It seems, however, that the majority of people prefer working on the actual game and look for a complete game development framework, something SDL is far from being!
    @Xenovore: as a rule of thumb I don’t even consider using a C++ library (free or proprietary) that doenn’t give you full access to source code. BTW, take a look at C4 Engine. It’s made by one of the best 3D programmers.

  • CdrJameson said,

    More succinctly, a library is a toolbox to use however I wish.

    It gives me a hammer.

    A game engine helps me out if I do things it’s way.

    It makes me a nail.

  • CdrJameson said,

    More succinctly, a library is a toolbox to use however I wish.

    It gives me a hammer.

    A game engine helps me out if I do things it’s way.

    It makes me a nail.

  • CdrJameson said,

    (oops – there’s a lesson – don’t post from a dodgy wifi iPod connection)

  • CdrJameson said,

    Right – Unity fail at first hurdle.

    Tried to make a quick, wrap-around world for a game to take place on (go off the north edge, appear on the south, go off the east appear on the west) and apparently it doesn’t like that.

    Sheesh. We could do that one over 25 years ago.

top