Skip to main content

Before The Single Step, There Must Be Ground

I'm back on the independent game developer wagon... sort of!  In truth, after nailing the most important aspects of the game I wanted to develop, I now knew that I wanted to make a sort of an RPG with a simulated environment, with the geeky satisfaction to be found in a roguelike, Dwarf-Fortress-like game, and even city management simulators to some extent.  (Basically, the kinds of games I've been playing lately.)  This may have resolved a great deal of the cognitive dissonance I had for months now that has been preventing me from getting to work: I feel as though I actually know what I want to make!
Just in case you didn't get what that title is referring to...

On top of that, it turns out I had come up with a rather effective concept in the past that I partially developed on BYOND before giving up because of platform limitations.

So, knowing exactly what I wanted to make, I tried to create that in GameMaker, and immediately ran smack-dab into a core limitation that caused me to question my use of this platform again.

The trouble?  GameMaker's room editor has no way to cut and paste multiple objects at once.  These objects are the tiles that make up my maps, so making modifications can take a very long investment of time as I move each tile, one by one.  Even if I was using a text editor to create a map, it wouldn't take that long!

Actually, I think the greater problem I have with GameMaker is that it's surprisingly bad at procedural generation.  There is a very limited set of functions for performing operations outside of the current room.  Only the current room is simulated.  So, basically, you have to go to a loading subsection of a room and spin your wheels for a room to get built at all.  Also, the way the IDE is built, you keep getting directed to "drag and drop" game building which is incapable of procedural generation.

Pondering this, I wondered at my alternatives.  I looked to Unity, which is equally not bound by tiles.  How does it do in terms of procedurally generating tile-based games, I wondered?  So I did a bit of YouTube searching, and found something that make me realize just how important tiles were.
It was in watching the above video that some unexpected (and unintentional) genius came down from the 'bove.   At the very start of the video, quil18creates points out that creative type people who enjoy programming really like strategy/simulation type games that are tile map based.

This lead to a minor epiphany on my part.  I was thinking of tile-based games in terms of just being a technical consideration: tiles are easier to work with,.  However, hearing it from someone else, I thought that maybe there's actually something of ever greater significance than that: a tile-based game actually suits my mindset better!  It's no wonder I'm attracted to this kind of game, it's just the kind of guy I am, and I shouldn't expect it to sell to people who aren't.

It's time for me to find a new platform.

So now I realized that I absolutely need to put possession of an effective, tile-based engine as my first step in developing my game.  There's a couple ways I can go about this:
  1. Find a tile-based engine.
  2. Find a non-tile based engine, and define such rules in that engine that it becomes tile-based.
Option 1 is a lot less work, but option 2 has the potential for greater flexibility.  Option 2 would seem the wiser choice, but consider that a tile-based engine may exist that already has all the flexibility I need while possessing preexisting tile based function calls (for things like pathing, line of sight, and so on) in which case option 2 would be an unnecessary waste of time.

Today, I took a bit of a walk around the Internet.  Here's how I'm currently looking at some of the major offerings out there:
  • GameMaker - Just to be clear, I certainly could make the game I want to make in GameMaker, it's definitely flexible enough.  However, lately it's seeming like where GameMaker starts is actually a step away from where I want my game to be; this is great software if what you want to make is a single-room action game, but I've learned that my concept is bigger than that.

    It's the rooms that bother me the most: I can't modify multiple objects simultaneously in the room edit, and in-game I can't do much with rooms that are not currently being played on.  Besides, that user-friendly GUI just gets in the way of somebody with a little more experience, like myself.
  • Unity - I barely even know anything about Unity, but I saw the above video enough to get a basic impression. Compared to GameMaker, Unity is just as flexible, is 3D native, has a higher price tag, definitely requires a bit more technical expertise to use, but the IDE does not get in the way of coding as much.

    Is Unity appropriate for a procedurally-generated, tile-based game?  Well, RimWorld certainly proves that you can create one in Unity, but Spelunky already proved it's possible in GameMaker, and I'm honestly not sure it's any easier to do in Unity.  I'm not yet sure how Unity's scene-based approach compares to GameMaker's rooms.  I have learned that you can download effective tileset editors made by other Unity users, and this addresses the concern I had with GameMaker's tileset editor.
  • Torque - From what I gather, you have to recode fairly extensively to make Torque do something other than a first person shooter.  I don't want to make a first person shooter, so this is the long route for me.  There is a 2D Torque project, but it's fallen somewhat behind the 3D.  Of all the engines here, Torque and Unity are the most powerful, in sheer polygon-pushing capability.
  • LÖVE - Here's a cool, pretty-much-free, LUA based engine I found for making 2D games.  It's cross-platform between Windows, Mac OS X, and Linux.  No fancy IDEs here, but it's still easier than compiling your own engine.
That's option 2, the "Find a non-tile based engine, and define such rules in that engine that it becomes tile-based" option.  I sort of like the looks of Unity, it could be fun to play with, but this is no minor undertaking.  But then, none of the engines from option 2 are a minor undertaking because they basically start with no game rules defined, that's why they're so flexible.

Option 1, the "Find a tile-based engine" option has the advantage that it's already closer to being the type of game I want to play.  The main question is whether or not that engine does everything I want to do.  Here's a few choices I found:
  • BYOND - You know, BYOND is really, really cool.  It's not only a great tile-based game engine with a great IDE, but it's also a multi-user dungeon right out of the box, so I could pretty much shoehorn in a persistent state multiplayer environment into my game concept, and largely effortlessly.  That's huge

    I also learned a lot about object oriented programming within an interpreted environment while playing with BYOND, and this is probably why GameMaker is just too simple for me to use anymore.  It's unfortunate I was unable to complete a game in BYOND, because I sort of felt I owed it a debt of gratitude for what I learned using it.  (Perhaps the year or two of subscription I had paid will suffice.)

    However, I have two big reasons not to want to use BYOND anymore.  First, because faulty file I/O, fuzzy large value handling, and the limitation of 65535 mobs and objects has broken my heart.  Second, because playing a BYOND game generally requires the BYOND interpreter and account, and the audience willing to install that is rather small; this is why you usually never hear of a BYOND game.  Maybe later versions of BYOND will resolve these issues and I'll be back on board.
  • RPG Maker - When I tried out RPG Maker, I was rather impressed with it.  It really is a marvelous creator of tile-based role playing games, and has flexibility to be other things, to boot.  Why am I not still using it?  Mostly because of that damn resolution limitation.  Seriously, Enterbrain, who's going to want to play a 544x416 resolution simulator on the PC?  I guess it's not impossible for me to create something on it, but that resolution limitation makes me want to do something else!
  • T-Engine - I haven't used T-Engine, but you know that this is the kind of engine that has the support to do everything a fancy roguelike can do because it is the engine of one of the fanciest of roguelikes, ToME.  Now, what I don't yet know is just how flexible T-Engine is: can it only be used to create games that are roguelikes, or can it do something like Dwarf Fortress? 
  • Libtcod - If T-Engine isn't flexible enough for my needs, this would be a pretty good way to go.  It's basically "a free, fast, portable and uncomplicated API for roguelike developers providing an advanced true color console, input, and lots of other utilities frequently used in roguelikes."  Like in T-Engine, map generation, line of sight, pathfinding, map handling, and things like that are already done, and that would save me a ton of time. 

    The down side?  This is no already-compiled engine, but rather a code API, which means I'll need to hunt down and install an IDE for C, C++, or Python and modify the code directly for it to suit my needs.  (Granted, if you're a programmer, you're probably disappointed in me that I haven't already.)
Looking at these choices, I'm pretty sure that, if I went with option 1, libtcod is probably the most likely direct solution for the kind of game I want to make, but it would require enough technical expertise that I'm honestly not sure if knocking up a Unity tile-based engine from scratch would be harder.  I should at least give T-Engine a look, first.

Of course, this is far from the only choices on the face of the Internet.  It could very well be that a better option exists that I have yet to find.  Here's a list of all sorts of cool game development environments, many of which I've yet to investigate.  Note that it's not a complete list, as it does not mention some of the environments mentioned here.

You could mention there's a third option: coding your own engine from scratch.  The main trouble with that solution is I want to be a content developer, not a code monkey.  If you start with the programming language IDE and little else, you're going to spend months - even years - just creating the engine that runs your game.  If you want to make an engine, that's great.  If you want to make a game, find an existing engine, or at least an API.  Let somebody who wants to make an engine make an engine, and then you can promote their engine by creating a cool game in it: this is the power of the Internet.

Still, I learned something today.

Even if I made this game on GameMaker or Unity, I'm still going to have to go up to my elbows in coding to teach the computer what it needs to know to realize the game I want to make.  Consequently, there's no way to know before the fact whether or not there's a genuine speed benefit to going with option 1 or option 2.

Comments

Popular posts from this blog

Empyrion Vrs Space Engineers: A Different Kind Of Space Race

In my quest for more compelling virtual worlds, I have been watching Empyrion: Galactic Survival a lot this bizarro weekend, mostly via the Angry Joe Show twitch stream.  What I have concluded from my observations is Empyrion is following in Space Engineers' shadow, but it is nevertheless threatening the elder game due to a greater feature set (the modding scene notwithstanding).

Empyrion is made in Unity, whereas Space Engineers is built on a custom engine.  While this does put Empyrion at a disadvantage when it comes to conceptual flexibility, its developers nevertheless have a substantial advantage when it comes to adding features due to a savings of time spent that would have gone into developing their own engine.  Examples include:
Planets.  Empyrion already has planets and space to explore between them, whereas in Space Engineers planets are in the works but still awhile away (so you just have asteroid fields to scavenge).Enemies.  Space Engineers' survival mode boasts onl…

Resonant Induction Really Grinds My Gears... In A Good Way

From about 2pm yesterday until 8pm today, I've been dabbling with my latest custom mod mix for Minecraft 1.6.4, which is this time very much Universal Electricity focused.
Aside from the usual GUI enhancers and Somnia, the primary contenders in this mix were:
Calclavia Core - Of course: this is the base of the Universal Electricity system.Resonant Induction - This seems to be largely focused on increasingly more advanced methods of refining ores divided across 4 ages of technological progression.  It also includes some really cool things such as assembly lines.  I'll primarily be talking about just a few blocks out of this mod today.Atomic Science - A mod dedicated to generating more of those lovely universal electricity volts via the power of splitting the atom.  Build your own nuclear reactor!  Deal with nuclear meltdowns!  You maniac!ICBM - A mod dedicated to generating more destruction using those lovely universal electricity volts (and more than a little gunpowder), it cer…

Greasing The Grind: Adding Lasting Appeal To Virtual World Sandboxes

Game design, being about entertainment, is not as much science as art.  We're coming up with interesting things that the human mind likes to chew on that "taste" good to it.  Different people find different things, "Fun," and a game designer is tasked with coming up with fun, appealing things.  As pertains to virtual world sandboxes, I identified three of them.

Challenge Appeal.

Dwarf Fortress and Fortresscraft Evolved have the same end game appeal preservation mechanic: wealth equals threat.  The more money your Dwarf Fortress is worth, the bigger the baddies who will come for you, including a bunch of snobby useless nobles who do nothing but push dwarves around and eat.  The more energy you make in Fortresscraft Evolved, the more and bigger bugs come to shut down your base.  Rimworld does something a little different based off of which AI Storyteller you choose, but it generally adds time to your wealth accumulation when deciding what kind of threats to throw a…