This has been touched on before in other threads, but I'm more seriously considering it now so I thought I'd ask some direct questions.

Over the last few years we've put considerable effort into our basic toolset for making games. We now have a pretty solid C++ library that can do just about anything you'd want to do in 2D. From what I've seen looking around on the net, there's very little of any value in terms of an engine to create 2D games with. There are libraries that help of course, but they tend to still be pretty low level things that don't offer much in the way of functionality.

Some of the features our stuff now supports...

- All low level calls hidden. You think about the game. Not about the code. The games are inserted into a simple state mechanism. You create states and handle callbacks. That's it. The rest is handled including various technical issues like direct x surface restoration and so on... The framework also provides basic support for things like player tracking and other game related features.

- Simple overlay(image) and sprite interfaces with support for movement, scrolling/multi layered scrolling, trajectories, animation (include complex animation sequences), fonts, buttons, warping (Like bubble effects or bends), stretching, alpha blending, image and alpha mask loading (a few formats), collision detection, and more...

- Support to run under Direct2D or Direct3D - In Direct3D alpha blending is fast so while it's still a 2D engine you can toss in tons of effects without performance hit. 3D is limiting in the sense that people need better vid cards and the latest direct x drivers and there tend to be more compatibility issues due to driver bugs and so on...

- Support for sound effects and music.

Anyway... One things we've been considering is turning the engine, or a subset of it, into a commercial product. This requires a lot of work since we have to make documentation, prepare release builds, handle support and so on and basically we'd have to bring someone on just to do that work as almost a full time job. So I thought I'd start with a few posts and see if there's any interest at all.

There's a number of things I left out, but the basic question is. Would you consider purchasing a C++ library that provided these things and if so what would you pay for it? Would you prefer a one time license or a royalty based fee? Any comments would be appreciated.

I set out to build exactly what you describe for Katsu's Journey; I wanted a data driven game engine that could do just about anything. With my editor and engine I could create ANY 2D game. I rapidly became acquainted with just how many resources this would take and ended up hard coding a lot of stuff so that it was specific to Katsu’s Journey. So instead of an editor that would build any 2D game. I now have one that builds Katsu's Journey. A lot of the building blocks could be leveraged for other games but not without some extra glue code.

That said I’ve spent the last 8 months of evenings building technology for Katsu's Journey and am only now starting to see the first fruits of my labor with the initial gameplay elements FINALLY starting to appear.

Would I buy a good 2D engine that would allow me to focus on making games as opposed to making technology? The answer is HECK YEAH!

Wow, excellent question! I am also thinking about exactly the same question except for our engine is mainly 3d oriented and currently relying on autodesk's craps. :)

I think in 2d there are lots of good competitors like Sdl, allegro and all other *basic languages. Unfortunatelly the 3d arena has started saturating as well with the recent releases of very good engines. And as I have seen it requires massive amount of support.

Originally posted by bernie
Wow, excellent question! I am also thinking about exactly the same question except for our engine is mainly 3d oriented and currently relying on autodesk's craps. :)

I think in 2d there are lots of good competitors like Sdl, allegro and all other *basic languages. Unfortunatelly the 3d arena has started saturating as well with the recent releases of very good engines. And as I have seen it requires massive amount of support.

I think blitzbasic and darkbasic might be relatively good competition, but someone might be looking specifically for a c++ lib. I know as a developer I'd be reticent to use basic, even though they are excellent tools. I believe they're well suited to first time developers who don't have any other programming experience. I would consider using blitz3d for simple 3D game. I suppose it all depends what you're comfortable with and what your overall goal is. There's a little give and take.

Allegro on the other hand is far lower level than what I have to offer so it doesn't really count as "competition" in that sense. I haven't played with sdl so no comment there.

I would for sure, if it suited my needs... Software alpha blending would be good :)

The problem I have with a complete engine suite (and probably the reason why they're not so popular) is that it's hard to customize. A complete suite is built so that all of its components work together. It's very difficult to write it in such a way that the user can replace one component with their own or add their own component. At least the suite I've been working on for the last few years is like that. I found that it's very inefficient to write independent components. So basically they're all interdependent or share some common data types. If I were to get someone else's suite I'd have to learn a lot about its code to modify/add stuff to it, and that's even if its source would be available. So while the idea is good, I don't know how convenient it will be for developers. That seems to be the reason you only see low level libraries mostly.

Originally posted by Fenix Down
The problem I have with a complete engine suite (and probably the reason why they're not so popular) is that it's hard to customize. A complete suite is built so that all of its components work together. It's very difficult to write it in such a way that the user can replace one component with their own or add their own component. At least the suite I've been working on for the last few years is like that. I found that it's very inefficient to write independent components. So basically they're all interdependent or share some common data types. If I were to get someone else's suite I'd have to learn a lot about its code to modify/add stuff to it, and that's even if its source would be available. So while the idea is good, I don't know how convenient it will be for developers. That seems to be the reason you only see low level libraries mostly.

Could you give me a specific example of the kind of things you wanted to modify or add that were difficult?

Our engine is still "low level" in the sense that it doesn't concern itself with a game type per se. It just can do everything that 2d games typically do in terms of display but provides some easy routes to make that happen. So for instance if you wanted a sprite to move in an ellispoid manner you could do something like...

--> sprPlanet.SetTrajectory(ellipse(radius1, radius2, focal1, focal2));

or alternately just create your own trajectory by deriving a class from TwTrajectory like...

-->class GalagaFighterPath : public TwTrajectory
-->{
--> .. some math...
-->}
-->sprGalagaFighter.SetTrajectory(GalagaFighterPath)

or if you didnt like the trajectory handling do something like...

--> sprBall.SetVelocity(10,20) // pixels per second

or even just...

--> sprBall.SetScreenPos(my_fancyx, my_fancy)

or...

--> sprBall.SetWorldPos(4000,2048)

Blitz Basic, and Allegro are nice. I use allegro for the Katsu's Journey Game Engine now. What I would be interested in is a 2D "Engine" in every sense of the word. For Instance GarageGames sells the Torque Engine; it has a terrain code, vehicle code, mesh loading code, a networking layer, a compiled scripting language, player classes etc. Game developers need only derive from these classes and program the game specific code for their game. They also provide a sort of world editor for building basic terrain and texturing it.

I would love if I could license a 2D game specific engine along the same lines, one with Sprite, Animation, Tile, Actor, projectile, and player classes that I could customize or derive from to implement my game. Actors would already have bounding boxes (or spheres) and collision detection would already be implemented. A simple map editor program that could create multi layered tile maps, set tile properties and place actors in the map. Maybe even assign movement patterns / paths to Computer controlled actors.

This is basically where I’ve gotten my technology to in the last 8 months and while it was interesting and stimulating to implement, it would have been better for my Indie game business if I had spent the last 8 months building and refining gameplay elements in Katsu's Journey as opposed to building the technology to support them.

Originally posted by Dan MacDonald
Blitz Basic, and Allegro are nice. I use allegro for the Katsu's Journey Game Engine now. What I would be interested in is a 2D "Engine" in every sense of the word. .

Our code can pretty much do everything you described with regards to building worlds and deriving actors and collision and so on. It also has a world editor which is good for large scrolling worlds made up of different tiled images (or even just big static images) Tiles are variable width and height and can be placed anywhere.

Originally posted by svero
Could you give me a specific example of the kind of things you wanted to modify or add that were difficult?

Well let's say I wanted to write a particle engine or tile engine to add to your engine. How easy would that be to do? I think it would be pretty hard without having access to the rest of the code. Or say there was a feature one of your components didn't have and I wanted to add it. Technically if you provide the code it's not much of a problem but the person does have to figure out how the code works, so they're not just learning a new API but also the source code. Even if I was able to make a component that works with the rest of your components what if you fix some bugs or change some functionality in the next release that makes my code not work? That kind of stuff.

Originally posted by Fenix Down
Well let's say I wanted to write a particle engine or tile engine to add to your engine. How easy would that be to do? I think it would be pretty hard without having access to the rest of the code. Or say there was a feature one of your components didn't have and I wanted to add it. Technically if you provide the code it's not much of a problem but the person does have to figure out how the code works, so they're not just learning a new API but also the source code. Even if I was able to make a component that works with the rest of your components what if you fix some bugs or change some functionality in the next release that makes my code not work? That kind of stuff.

Well... Those sorts of things should be trivial to add without touching the engine code at all.

I use some particle effects in both space taxi 2 as well as drop target and both a particular to the game in question. As for tiling... there's already some support for tiles, but it would also be easy to add your own tile code making use of what was already there. What stops you from adding particles or tiles in the tool you use now?

As for adding features to components, well that's the beauty of c++ -- You just derive from the component and add the feature. I suppose technically it's possible that some element of the component is hidden and it doesn't allow you to modify it, but in general the stuff was designed to be extended easily.

I don't think I would want to release source code with the engine. Too hard to support. I'd prefer to just provide good solid libaries of tools. It's true in general that you can run into some limitations, but I expect I would provide enough information that most people could tell straight away whether it met their needs or not.

As for API changes in new versions..well that's always a problem. But I don't see that it's any worse than say working directly with allegro or direct x. Same problem different API.

Well yeah if it's very flexible then that's good. What I'm using now is OpenGL/SDL. I wrote a whole suite on top of that including graphics (with font support), sound, input, texture manager, framerate independent movement/animation support, tile engine, simple menu engine, animation engine, particle engine and other stuff.

I did it partially as a learning experience and partially because I wanted to make a complete reusable engine. It might be feasible to sell your engine, but you have to make sure to set a price that's not too high. It definitely is hard to make a generic reusable engine though, so if you've accomplished that then good job. :) I think there would be a demand for such a thing from people who don't already have a reusable engine. Those people who mostly write game-specific code would find this useful I think.

Personally I wouldnt, or even use a free one, because I know exactly how my own engine works, and all the problems i might encounter. Its just too time consuming to go through and work out the API for another engine.
Ive worked (in my day jobs) with two big in-house engines, and the first thing I do is wade through all the code until it gets down to the 'metal' the actual Verts, and see how far removed I am from the actual directx calls.
If you are like me, you never really 'trust' an API unless you dig deep inside it and see exactly whats going on. Because I wrote every line of my own engine, I know the overhead of a sprite, and whether I should use them for particles etc.
Of course, I am probably not typical, and a lot of people enjoy just writing game code without having to wade through the directx SDK.
I think you can sell a 2D engine, but I don't think people are prepared to pay much, because unfortunately most people doing 2D games are amateurs, or speed and performance isnt an issue for them.
Just my thoughts anyhow.

Originally posted by cliffski
Personally I wouldnt, or even use a free one, because I know exactly how my own engine works, and all the problems i might encounter. Its just too time consuming to go through and work out the API for another engine.
Ive worked (in my day jobs) with two big in-house engines, and the first thing I do is wade through all the code until it gets down to the 'metal' the actual Verts, and see how far removed I am from the actual directx calls.
If you are like me, you never really 'trust' an API unless you dig deep inside it and see exactly whats going on. Because I wrote every line of my own engine, I know the overhead of a sprite, and whether I should use them for particles etc.
Of course, I am probably not typical, and a lot of people enjoy just writing game code without having to wade through the directx SDK.
I think you can sell a 2D engine, but I don't think people are prepared to pay much, because unfortunately most people doing 2D games are amateurs, or speed and performance isnt an issue for them.
Just my thoughts anyhow.


Well our engine is designed with performance in mind as well of course. Something like Planetary defense would be pretty easy to put together using the tools and not require any special optimization or tweaking. I don't think someone like you would be the right target audience though because you already have your technology built and running. I figure I'd mostly be targeting newcomers who want to bootstrap their development and not write their own technology from the start. Myself, I'm like you... I doubt I would ever use a 3rd party lib. I tend to like to use my own code. Still... depending on the game some tools are pretty tempting. I can think of quite a few nice little games that would be fairly easy to implement in blitz3d.

I think it will be difficult to competete. There are already some good 2D engines on the market, where the developer don't have to write a single code. The developer writes an event (it's like visual scripting). The advantage of this system is that the developer can spend more time in developing the components of the game design. And so the developer don't have to worry about the backgroud technology. Like collision detections, values, editors, etc. This kind of developers aren't mostly seen as "real" programmers, but in fact the advantage is that they can concentrate on the game design and not the opposite the technology. So in that case time is money is also a second advantage. Your engine is more a target for upcoming developers, who want to learn "real" programming. Everybody can learn of course. But not everybody got the patience to do this in a short time. So mostly people who want to write a game easy and quick will target on game development environments, where you can write the game without a single code. Or examples like Darkbasic, where coding isn't real hard. Another example is The 3D Gamemaker, this tool is more target at people who want to play and create a simple 3D game. Not for people who want to write serious commercial games. In that case Darkbasic or Blitzbasic is a better choice. Also Jamagic or 3D game studio could be seen as serious competitors. Also there are more people interested in doing the 3D thing, then for instance stay at 2D. That's the reason why you see many 3D environments. A good example is the developer of Jamagic, they sold before a 2D environment. They knew that they need to go on (they got many mails from customers etc.), so they moved in developing a new development environment that can do, 2D and 3D. Called Jamagic. The only problem is that Jamagic uses a scriptlanguage, similar like javascript (not real hard). There were people who liked it. But there were also people who don't liked it. They were interested only in visual scripting, so they stayed at the 2D environment. So it's not an easy market at all. But you need to do some good market research. Your niche would probarly the serious shareware 2D game programmer, who is interested in C/C++. And also got skills to do this. I think seriously that this would be very difficult. None of the mentioned 2D and 3D environment are real hard, like C/C++. So this is the first differences. Also most upcoming amateurs are mostly interested (who already know some C/C++), to find out the technology. If you do some research on perhaps gamedev.net, this can be further confirmed. The point is that they don't know (well enough) that there is a market for 2D. So again the best thing you can do is to take the time and make a plan, to find out if there is a big niche for this 2D engine. I doubt it, if you ask my opinion. Because there are so many different people. And perhaps only a small group (like us) consider 2D games as a serious business.

At the beginning of development on Katsu’s Journey I was doing 2D in 3D using DX8.1. I've since switched my game engine to Allegro to be more compatible with my target market, but my editor still uses DX8.1. If I hadn’t just spent months building my own technology and wishing I was building my game I would probably still be one of those people who would never buy a pre-fabricated engine.

I know 3D, I know 2D, I know networking, I know enough to build all these pieces and that was the biggest reason why I wouldn't have used anyone else’s engine in the past. But I think I’ve matured to a point where I’ve realized that the most important thing for Rainfall Studios is releasing games, not building technology that we'll never profit from. I no longer take pride in being able to say I wrote every single line of code in this game. That was once a badge of honor for me as a developer, but I’ve realized that I’m no John Carmack and my programming skills aren’t so 1337 (elite) that I need to code everything myself to get maximum performance, it's a 2D game for crying out loud.

What I now place value on is producing fun, well polished games that will help build Rainfall Studios into the company I want it to be. Building fun sellable games is much more challenging then building technology anyway. Spending tons of resources on tech means I’ll have less to spend polishing and refining my game, this is not good. Now that I’ve realized that, I’d rather spend 2 weeks educating myself to the nuances of someone else’s engine (then 6-10 months building my own) so I can get onto the business of building games which is really what I want to be doing.

In the past I thought building technology was equivalent to building games, but it's really not. There's so much game code that still must be written after the technology is built, I think your biggest problem will be convincing other people of that as well. Most people on GD.net are of the same perspective I was. They think the glory is in building super tight super efficient engines for their games. When the glory, in my opinion, is actually in delivering a complete, polished, and enjoyable game...

I totally agree Dan. But I'm glad I made all this stuff because it made me a much better programmer. Of course, if I was already a good programmer it would've been a lot more logical to use an existing engine. You not only get the benefit of not having to develop your own engine and get a head start on the game, you also get to use tested code that is potentially used by many other programmers so bugs will get reported and fixed quickly.

With your own code you're probably the only one using it, so if there are bugs in it you might not encounter them until many weeks or months after you write the code. Again though, the only problem I would have with someone else's engine is not having access to the code, but if it's flexible enough that I can build my own components on top of it I wouldn't mind as much. The bottom line is that from the business perspective it makes a lot of sense to use existing technology than writing your own. I wasn't thinking about this when I started writing it a few years ago, and I don't think Dan was either.

Nope, I sure wasn't ;)

Dan, how much of your DirectX effort went into the actual engine, versus the time you spent working on your editor framework, then switching to WTL? How much do you think you would have saved if you'd done the editor with a higher level tool, like MFC or VB (the assumption being that you're good with the higher level tool)? 6-10 months for a 2D engine seems a bit extreme.

Another thought: if you licensed a 2D toolkit, you could possibly lose the benefit of being able to offer your level editor with the game, as the editor would be the toolkit maker's product, not yours.

Well, everybody who thinks about take a plunge into the engine development bussiness, should really read the story of Grubbers' Fastgraph libarary and Egerter's Pr. They are both very good libraries and exist from the dos times, but both are struggling for getting very good results. Strange. The stories of these two excellent libraries alone hold me back from participate in this market. :(

Originally posted by Siebharinn
Dan, how much of your DirectX effort went into the actual engine, versus the time you spent working on your editor framework, then switching to WTL? How much do you think you would have saved if you'd done the editor with a higher level tool, like MFC or VB (the assumption being that you're good with the higher level tool)? 6-10 months for a 2D engine seems a bit extreme.

Very little effort went into my engine actually, once the editor was coming along (saving and loading maps etc) I just copied and pasted the base classes and I basically had my engine up and running. A LOT of time was spent creating a resource manager (to support ALT-TAB), texture and font wrappers, D3Ddevice wrapper etc. Since Direct3d only has the ability to render primitives I had to make my own box routines and draw them as sets of vertices representing line primitives etc. I spent a month getting the basic D3D stuff up and running and then about a month writing my first version of the game editor, it had a text based interface but had basic tile map functionality. I made a lot of mistakes with this one and the code wasn’t scaleable so I started over.

I spent about 3 months developing my own version of the MFC's which was folly. It was a pretty cool little system (and it worked great), but without a proper resource editor like MSVC it was slowing development. I eventually lost all the code in a freak double hard drive crash. I started over with WTL and it took me about a month to get back up to the point of functionality where I was before “the crash”. It was actually at this time that I copied and pasted the editor code to make the engine. After realizing that the engine would need to be implemented with older technology I switched to allegro and it took me approximately one week of evenings to learn allegro and port the engine to use it. (Allegro is nice)

Since then I’ve been adding features like the ability to assign movement patterns to Computer Controlled Actors in the game and implementing guard views etc. adding more and more of the basic gameplay elements.

Could I have gotten to this point sooner if I hadn't made a bunch of mistakes and had implemented everything the right way from the beginning? The answer is yeah, no question about it. But unless you have experience you will make expensive mistakes no matter what, if I had started with a nice functional 2D engine, I wouldn't have had to make all those mistakes and use up all that time, I would have just spent 2-3 weeks learning the engine and be off adding custom things like my guard viewing regions.

Instead I had to spend months learning to build technology the hard way. Sure I learned a lot, but it wasn't the lessons I wanted to be learning. I want to be learning lessons about gameplay, look and feel, and marketing, things that will make me a successful Indie developer. If I could purchase something that would keep me from learning all those expensive technology lessons so that I could focus on the game related ones, I would be very eager to buy it.

Originally posted by bernie
Well, everybody who thinks about take a plunge into the engine development bussiness, should really read the story of Grubbers' Fastgraph libarary and Egerter's Pr. They are both very good libraries and exist from the dos times, but both are struggling for getting very good results. Strange. The stories of these two excellent libraries alone hold me back from participate in this market. :(

Well.. I'm not really sure fastgraph counts as a game engine. There's nothing really specific in that lib that has to do with games. It's a set of wrappers that hides low level stuff from you. As a game developer I want to worry about...

OnShipHitsRock()
{
ExplodeShip();
}

and *NOT*

void fg_ddfreedc (HDC hdc);
Release a device context and unlock the DirectDraw surface

My feeling is that the work we did could have been simplified by starting with fastgraph and building on top of that. But there still would have been maybe a year or two of programming to turn it into what I'd call a tool for making games.

But all the same I'd be interested in reading about this. Is there an article somewhere that discusses it?

I would say "No, I don't want a library", but "Yes, I would buy the source". This is what we have with the Torque Game Engine (http://www.garagegames.com/pg/product/view.php?id=1) for our 3D games. The source is the key, and it's the thing that no one really wants to give up. For you giving up the source probably doesn't seem so smart. For me the game developer, the source is THE single most important thing I could get for my money.

Dave Myers
Vice President
21-6 Productions, Inc. (www.21-6.com)

The torque engine seems like a good deal. Garage seems to be doing some good things. I liked their release, marble-blast, quite a bit.

My one concern with code releases is the issue of technology theft. That is... many user licenses that come with code bases prohibit you from using the technology in a similar product. No doubt Torque is no exception to that rule. After all, the developers of torque don't want you to take the code, make a new 3D engine and sell it. (or even parts of the code for that matter) The real problem here is that in these sorts of engine things there are often only a few good ways to do certain things. So as someone licensing source code, who maybe also wants to build my own proprietary technology down the road, I'd be afraid of possible lawsuits etc... A company doesn't have to be right to go after you in court and as soon as something like that starts you've already lost the battle as you have to spend money defending yourself whether or not you violated the license agreement. Maybe I'm paranoid but that makes me wary of using something like the Torque engine. Since you've already developed a game using it maybe you'd care to comment? I'd also be curious to hear how it's been working with garagegames vs real. They're two very different companies I know, but any snippets of info could be of interest.