Hello World

by Kyzrati on 20111031 , under

Proper X@COM development has been put on hold while I get busy reinventing the wheel.

After weeks of debating the issue with myself, I've decided to write a complete game engine from scratch rather than continue with libtcod. I originally intended to write a new libtcod framework that would replace Umbra and make coding X@COM a lot easier, but finally convinced myself that with just a little extra work I could write my own engine right on top of SDL, one that would be both simpler and much easier to modify to fit my own needs. Libtcod is a really cool library, but since I already have my own rather large collection of game classes (on which X@COM is based), I was only using a tiny fraction of libtcod's features in the first place (namely the console display).

After a little bit of planning (probably too little), Rogue Engine X was born this weekend. Here's a shot of "REX" in action--very impressive stuff, really...

Okay, maybe not so impressive. Right now it can't do much of anything except load a bitmapped font and draw one full-color console window. The color support is essentially the same as libtcod, although with a slightly different HSV pattern for the default colors.

REX features (eventually):
  • Based on SDL
  • Fully object-oriented (C++)
  • 32-bit color console
  • Command-driven input processing
  • Sound/music support
  • Access to archived resources through PhysFS

I already warned that X@COM's alpha debut is quite a ways off (two months, maybe?), so taking a detour to crank this out doesn't really change that. Consider this taking several steps backward in order to make huge leaps forward!
8 comments more...


  • Paulo Mendes

    Hi, just stopping by to say that this project seems pretty exciting, and that I'm following it with great interest. We need more games based on X-Com, that upgrade and expand its gameplay.

    Since you're starting on the engine from scratch, and since you've mentioned object-orientation as the architecture, I'd suggest that you check out "Entity Systems". I'm using a sytem partially inspired by that, and liking that approach instead of the usual OO approach (although my version is a hybrid of both, differing from the one described in that post). Just throwing it out there, you might like the approach (it mentions pretty good uses of similar systems in games, such as Thief and Tony Hawk Pro Skater 3).

  • Kyzrati

    You sure you weren't sent by aliens to sabotage X@COM? :)

    To be clear: I'm not actually rewriting any logic processing code here, just a new generic engine that can be used for any console-based game. The mechanics run pretty smoothly in their current OOP manifestation, and if I keep rewriting everything to try out cool new programming ideas the game will never reach 1.0! (or, more importantly, beyond 1.0)

    Thanks for the link, though--that's a great series about Entity Systems. I looked into ES a few months back when I was thinking about writing a massive, detailed roguelike world relying on a "property"-based internal representation for easy flexibility. Then I decided to put that game on hold since I'm wary of starting another huge project that's going to suck me in for years without much to show. I figure that a remake of a classic with well-documented mechanics will be pretty quick to implement as a foundation, then go from there adding new features.

    I'm not against new ideas, and am playing with several in X@COM and REX, but trying out a whole new architecture when all I know is standard OOP would probably kill the project's development rate! (I have to consider that I'll be getting busier over the next year with Real Life, too.)

  • magikmw

    Do you intend to make your engine open-source? All this looks pretty slick, and I'm sure you could compete with libtcod on the field of roguelike developement framework.

    As I see it, you probably won't (X@COM is closed-source, right), but it doesn't hurt to ask :).

    Anyway I'm following your project with great interest, just keep it up!



  • Kyzrati

    X@COM is closed source, right, but I could eventually release REX as a standalone engine useful for just about any roguelike/console project (it's not connected to X@COM in any way).

    It wouldn't have nearly the wide appeal that libtcod enjoys since it's C++ only, but it is a pretty neat engine so far... I pretty much finished it over this past weekend, but have yet to migrate X@COM to the new system, so I'm not 100% sure everything will scale well when handling a more complex game.

    I have considered open-sourcing the engine, but in the short run I wouldn't want to spend the time required to create and maintain a proper public release. It might make sense to do that after the engine matures, like some time after X@COM 1.0.

  • Canageek

    Why are you using SDL instead of just outputting to a console? I always wonder what the motivation behind people making rogueikes is to re-implement the console is. Doesn't that just make it less portable? Wouldn't it be easier to just have the console load a specific bitmapped font?

  • Kyzrati

    SDL is actually more portable than writing to a console, especially if you want to support features that consoles don't provide (as X@COM does), like sound, true color, images, blended layers... the list goes on. In the end, I'd say it's far less trouble to do your own console emulator, since then you have complete control and can solve almost any potential problem.

    Also, bitmapped fonts aren't compatible with standard consoles.

  • Canageek

    I was just wondering, since I love the fact that since Nethack is a console game at heart I can tweak all the symbols and whatnot without trouble. Also then you can play via telnet or ssh and whatnot, which I hear is quite popular.

    I didn't know you wanted to insert actual images-- What won't be done via characters? I've heard art is hard to get for open source games, are you doing it yourself or do you have someone lined up to do it?

    Also: You can have sound on the console: I use a command line movie player, mplayer, since then I can do everything from the keyboard without having things poping up during the movie.

    Why couldn't you take the characters you want to show, assign each to a codepoint (letter) then make a X@COM.otf file for the console to load? That should bypass any bitmap font issues. Also that would make it easy to use it when writing the manual or such-- Just install it as a system font. You could even use a webimages font mechanism to then have the actual characters from the game on your website.

  • Kyzrati

    I thought about ssh/telnet and whatnot, but overall I don't think those or any of the other console-friendly features are worth more than what I perceive are the advantages of emulation.

    I won't really be using many, if any, images, but it's nice to have the option available. The possible images I'm thinking about would be much larger than a single character, so wouldn't fit in a normal console grid. Images could even be used for full screen overlays and special effects. I'll need full control of the window's appearance since part of the immersive "console" experience I'm going for might require it.

    I'll be using mostly different fonts for the manual, so reusability outside the engine isn't really an issue.

Post a Comment

Note: Only a member of this blog may post a comment.