So I’ve been building my own 2D game engine for the last few months and things are really starting to come together. I was wondering though how many of you feel it's valuable to build your own engine (be it 2d or 3d)? Would you have built your own even if there was an existing one you could license that did everything you needed?

One problem you have is there aren't any good 2D engines for sale (that I know of).

Also with the sort of game you plan to make the graphics engine is only 10% of what you have to do. You need an awesome script engine as well as pathing, combat AI, loading/saving code, interfaces, networking, editors, etc. Then you have to script the game and create its graphics. RPGs are a massive undertaking.

It really amuses me when I see inexperienced people and game companies rabbit on about 3D engines as if they are the most important part of a game. They are just the beginning.

Build or Buy is *never* the question for an indie.

It's "Where do I buy?" ;)

Multimedia Fusion (http://www.clickteam.com/English/mmfusion.php) and Macromedia Flash are often used to create 2D games. I know as a programmer it often beguiles me to think of using some pre-fabricated engine where all I do is script in a few elements.

One problem with paying for an engine is related to copyright. Once you look at the source code to the engine you open yourself up to litigation should you ever want to create your own engine.

This is something that every developer should consider before paying for a third-party engine. Personally, it's a risk I'm not willing to take.

I agree that the graphics engine is only a small part of the picture. For me, a much more valuable product would be a UI "engine" that had all the common controls fully implemented and had some sort of editor and/or scripting system. Right now, I'm using owner-drawn Windows controls and that gets me part of the way there, but I'm not too happy with that approach. And the problem with any off-the-shelf product is that it will usually require some degree of modification to get it to work with whatever it is you're doing and sometimes that's more trouble than it's worth.

chronos: That's the first time I've ever heard that risk voiced. Have there been any cases where this happened?

I've been buying and selling third-party components for years. Never once has the issue come up. I'm not saying that it isn't something to consider. Merely suggesting that it may not be as big a deal as you're making out.

DavidRM: I don't know precisely how big a deal it is, but if you're accused of copyright infringement by a licensor who gave you a copy of the source code, the fact that you had access to the source code may be used against you in court. On the other hand, if it cannot be shown that you had access to the source code it is less likely to be considered copyright infringement (independent creation is not infringement).

The concept of "clean room" procedures for reverse engineering revolves around the concept of independent creation. If the person who reverse-engineers a piece of software is also the person who writes the new implementation, he weakens his position significantly. There's a reason why companies adopt clean room procedures when reverse engineering a competitor's interfaces and/or algorithms.

One case that is somewhat relevant is Whelan Associates v. Jaslow Dental Lab Inc. Here is an excerpt from The Software Developer's Complete Legal Companion by Thorne D. Harris III: "In Whelan, a case that has been much criticized, a client of a programming consultant took the consultan's dental office management software, which was written in a particular programming language known as EDL, and created a BASIC program to accomplish the same goals. The court found that the client had access to the source code of the original and infringed by copying the structure, sequence, and organization of the original work."

An ACM Article (http://www.eff.org/IP/principles_of_copyright.paper) said about the Whelan case: "Clearly, the computer code in the two programs was dissimilar. Nevertheless, the court held that the scope of copyright protection for a computer program's expression may extend beyond its literal code to the structure, sequence and organization of the program." Later the article adds "Because the court found similarities between the defendant's and the copyrighted program's file structures, screen outputs, and structures of five subroutines, the defendant was found liable for copyright infringement."

While later courts have narrowed the scope of the Whelan decision, there are probably still some risks related to access to source code and non-literal copying. Even if you do your best to avoid similarities between two programs, it is difficult for a judge to determine the degree of similarity that is a necessary and unprotectable product of the programs' function.

Another concern is the engine's license. For instance, the license agreement for the Torque engine says the licensee may not "reverse engineer, or otherwise attempt to derive the algorithms for the Software (except to the extent applicable laws specifically prohibit such restriction)". Even if no literal copying takes place, the knowledge gained from looking at the engine's algorithms could be used against you if you ever develop your own engine. I don't know what other engine's licenses look like, but I'll bet it's not pretty.

chronos: Interesting.

But the logic only really applies to people who want to get in on third-party sales. Which excludes most developers.

The number of people who can successfully market and sell an engine of any sort is limited. There's a very limited market for that kind of thing, and only the frontrunners (like Id with the Quake engine, or Unreal) can realistically hope to recoup development costs in this way. The rest have no chance, and should be content with using their engine in-house.

The bulk of projects are going to benefit from the purchase and use, in one form or another, of pre-written components. Leave technology R&D to the projects with excess funding.

What about cooperative efforts? This is something that I and a couple of other indie developers that I know have tossed around.

The basic idea is to create a small potlatch economy in areas where as indies we don't compete. So if one guy has a cool 2D engine and I have a solid network layer or good UI skills or something, we offer up what we've got, giving others in the co-op free access -- you can think of this as a sort of a limited open source effort. As a potlatch, new folks have to be considered carefully, and those who take without giving back are subsequently excluded.

Think this could work? It could certainly help us conserve our two most precious resources (time and money) without risking the loss of a competitive edge.

That's an intriguing idea. Certainly there'd be a degree of trust needed, one that's higher than a conventional business partnership, so as you say, you need to pick your partners carefully. One of the biggest problems I see as an indie is that I just don't have the time (or, in the case of art assets, the ability) to do everything myself, so an arrangement like this one would be a real godsend. It'd almost be like trading cards: I'll trade you a DirectX-based framework for a network layer. :) And if you don't want to share source code, you could simply swap libraries or DLLs. Hmm, very interesting....

Honestly, I'd set up an open source group rather than try to be a limited "clique" of developers. You also limit yourself to about 5 people if you require everyone to contribute (since there are really only around 5 components - graphics, network, etc. in a game).

If you make your libraries open source, you can get people to contribute because they want to use something, and they will also add to what they are using. It seems to be working for garage games and the torque engine.

It all depends what you're after, shaft.

But I don't think that the number of people is limited at all: there are a lot more potential contributions than just one instance of the things you mention!

And anyway, for me, I'd rather maintain a small group of high-trust relationships than a completely open (as in open source) set of relationships with whomever happens to come along. But for others, the breadth of open source is worthwhile.

My own informal experiences along these lines have been really rewarding. There are a few individuals in the industry (indies) with whom I have this sort of high-trust relationship, and whose judgement I trust, so that I'm able to bounce ideas off of them, exchange design docs, exchange code, etc. It's great being able to commisserate, lay things out, get a sanity check, etc., all without having to worry that anyone's going to run off with someone else's idea and without having to hold a lot back.

I suspect that as the indie game dev industry grows and people get to know each other, we'll see more of this sort of thing, not less. I hope so anyway.

I definately understand your feeling about trusted only a select few for projects. Most "developers" are merely wannabies (which is fine) who talk a lot and perform very little(that's the part that's bad).

So I can see not wanting them to touch your stuff. But they actually won't... They'll just continue talking.

Just my experience but trying to regulate who does what, and trying to deal with only people who produce is a painful task. If I ever open up any of my source to anyone other than the people in my group, I'll just open it up all the way. Too much of a headache trying to regulate who's responsible and who's not.

Or if you do keep it to a small group, keep it to people you know. If you advertise, "I'm offering this, who will do this", you'll end up with a flood of people who won't produce.

Well, for me it was never a question. I always love to
build new functionality to my existing library. But I am
not really an indie. Yet.
This question always come up from time to time and it always
shows the differnce between developers. For me the main() reason
is that there is no such easily useable library. Usually theye are
bloated or just plain complicated for even a simple task.
After I manage to finish my current game I'll probably tidy up
our engine and release it on the try-before-you-buy bases. :)
Well, I have been developing it since '95 with others help, so
maybe it can help out some people, too. Not to mention it is
always crazy when you see your work generates pleasure or makes
someone's life easier. But of course I don't really want to compete
with PR or Torque or any other low-profile engine, that is why I've
hesitated now and then to release my precious gem to the public. :)

I guess I should probably post my own thoughts on the topic since I started this thread ;)

The following are conclusions I've come to working on Katsu's Journey over the past 8 months.

First off, the nice things about building your own technology.Boy was it fun! When I first started Katsu's Journey I was all keyed up to learn the new 3D API in DirectX8.1 and harness it's power for a 2D game. I wrote my own wrappers, resource managers, heck, even my own MFC like classes to render dialogs, scroll bars, buttons, list boxes, etc.. In a directX window.

I learned a lot about GUI mechanics with that task and have a much greater appreciation for the windows gui then I had before.Learning direct3d was a blast as well, solving all the little issues with texture coordinates and getting it to work on older cards like voodoo's was fun.I now have some cool skills to list on my resume as well.

But there's always a cost associated with good things. I spent 3 months developing my little DirectX MFC, in the end it was ridiculously tedious to get new dialogs and controls built. The typical process involved initializing a dialog, then placing some controls on the dialog programmatically with relative x, y offsets. Then re-compiling 4-5 times while i tweaked the button offsets only to repeat the process for all the controls being added to the dialog.

The end result was a very slick, sinkable, UI, that could be built in only a few lines of code. The downside was that it was adding a lot of time to development. In the future if I were to attempt such a system I would make the GUI scriptable and a resource editor that created xml documents that the gui elements would be initialized from. But that in itself is a huge effort.

I ended up loosing the whole thing when my hard drives crashed in my laptop and desktop within 1 hour of each other. I'm thankful it did, I was forced to learn the windows template library (WTL) which is a subset of MFC implemented as template classes, it's easy to use and it adds next to nothing to you download size when compared with the MFC runtime. In one month I had all the functionality that had taken me 3 months to create previously and had even added new functionality.

I was able to copy and paste a lot of the code between the editor and engine because they were both very similar. But then i realized that directX 8.1 wasn't a good choice for our target market and ported the game code to allegro. I can still copy and past a lot of code between the editor and the engine because the classes were designed well enough to support that, but the engine and the editor are evolving in two different directions.

In order to keep the development time down, the editor is implemented only to create content for our game. The classes underneath are flexible but the UI initializes them in such a way that they only create ninjas and samurai. I made this decision because developing the ultimate 2D engine that could be used to build just about any 2d game was taking too long and it wasn't a good use of my resources.

The result however is that I’ll have all this technology that I developed from scratch and it's completely un-sellable. I've invested months and what will likely end up being over a year in something that will never get me a single dime on the market. The only thing of value is the game that the technology will produce. From this perspective it was stupid for me to go and write all my own code and have all this Intellectual Property that I can't sell.

Some would say, "well you can leverage your code for future projects." This is true, however it is also true of someone who invested time learning some existing technologies like Flash MX, Multimedia Fusion, or some of the other 2d scrolling engines available. Learning and using existing technology would have drastically shortened my development time, just like using WTL (and it's resource editor) shortened the development time of my editor. I would have the sellable portion of my efforts (the game) much sooner and be leveraging what I’d learned on my next project. When you have no intention of ever selling what you’re making, as an indie trying to run a business it's probably not worth your time to make it.

For me, I will probably have to make one more title with my existing code just to justify the amount of time spent creating it. If it shortens the development time of my next project it will pay for itself a little, but frankly its probably never going to pay for itself.

In short, use existing technology when ever possible, unless you are building technology you plan to sell on it's own merits.

That's a useful story, Dan. I remember reading somewhere (I've been searching for the reference, but can't find it) that the only time you want to develop your own technology is if your product (in the case a game) relies on it. id, for instance, is a technology company. Valve is not. Valve took the Quake engine, and added what they were good at, which was story. If Valve had tried to develop their own engine, Half-Life would likely not have happened.

Still, a lot of the time (especially with indies) games are different enough that it makes some from-scratch work unavoidable. Licensing a shooter engine is ideal if you're making a shooter, not so ideal for a puzzle game. Hmmm....Katsu's Journey with the Q3 engine. I can see it now. :)

Q3? bah! Torque, Power Render, or OGRE more likely ;)

Doh! I forgot the second indie rule: buy cheaply!!

Something must be said for the intrinsic value of learning how to build a wheel. If you never try to reinvent something, you'll be limiting your knowledge to particular APIs and functions. Twenty years ago as a young teen I can remember coming across a problem of needing to order some of my data alphabetically. I knew this was called "sorting," but I never saw it done before. So I sat and logically thought out how I could order my data algorithmically. I thunk and I thunk and came up with an algorithm -- and I thought this was THE algorithm; I mean I thought for every problem there was a specific solution, and that was it, you just had to discover it. I made the neophyte assumption that there is only one way of doing things. You've seen people who are at this stage: If they ask you for help, they're looking for a rote answer, and get mad when you try to help them think out a solution. They think you're being a pain in the keister but you're trying to help them reframe the problem so they can answer it themselves. There is no right way. Later I found out what I "invented" was a bubble sort and there are dozens of ways to sort data; many are faster, but it depends on the characteristics of your data which is fastest. Anyhow, my point is having done this type of exploration in the past helps me enormously to solve (coding) problems now. There's nothing wrong with reinventing the wheel as long as you can afford the longer development times. The pay-off is long term. It's also, if you ask me, fun.

Certainly there are times when it's inappropriate to explore a build solution when a buy is cheap or free. One of these times might be when, say, you quit you job and your hemorrhaging money from your bank account. :rolleyes: Ah, so I'll shut up now. Heheh.

elund, oh no doubt about it. There is a high value to be associated with learning how things work. Re-inventing the wheel so to speak. I think most people see this value and typically default to this model. The point I was trying to make is that when you are trying to do business as an indie game developer. Your income comes from games as opposed to engines. The faster you get your games out there and selling the better off you'll be. That's why I advocate using existing technology if you are making a game for profit.

Hobbyist programmers need not fall into this category. Hobbyist programmers program because they love to figure out how things work and see if they can do it better, or at least different. There is absolutely nothing wrong with this and it will make you a better coder in the long run. However after my own experience trying to start an indie business, shorter dev time is king, and what ever you can do to help you reduce your dev time will equate to more $$ in your future.

Well.... From my point of view there's little substitute to building your own library of code if you're in this for the long run. 3rd party libs and tools are nice bootstrapping processes, but in general I've always found I had to abandon them for one reason or another. When I started working on Twilight full time one goal was to simplify the game creation process to a point where development was thinking about and implementing the game itself and not the technology. Nowdays writing a game is more about ... I want to place a guy here and have him run there in so many milliseconds and hardly ever about learning some new facet of DirectX.

The long term benefit of creating your own tools can vary greatly though depending on your skill as a programmer. A skilled developer with the right experience implementing general tools can greatly influence the ease and speed of development of later projects, whereas someone less experienced, or with less skill can create a fairly useless toolset that's quite difficult to work with.

One example is our fairly recent move to support Dirext3D for extra effects. The basic implementation of this took a little over 1 week. We are now able to run all our games (with only slight modification) as direct3d or directdraw3. We had to fill in about 7 functions to accomplish this and battle a learning curve. Had we not wrapped up directx correctly and implemented our earlier stuff with a nice level of abstraction, the same process could easily have been a job several months long.

Today we have a toolset which is quite powerful for 2D games. I guess there's pretty much nothing you'd want to make in 2D that the engine couldn't handle at a very high level. Compared to the 3rd party tools I've used the process of building a game simpler and the tools I have to work with more powerful. I think the engine itself has value on it's own as well. I'm not sure if there's a market for it, but I expect that I will one day release some commercial form of the engine, likely starting with a "light" free version that does a lot of the basic stuff with the possibility to use the full version should someone want to licesne it. There are actually a few trusted 3rd parties using this code already to develop new games and so it's already paying off on it's own as we will receive a percentage from those titles.

Does anyone have any suggestions for a simple GUI system? I'm just about ready to implement my own, but would love to save the trouble.

Jack

The way I did it and it worked pretty well was to have a seperation between data and display classes. I had a bunch of base objects like CDialog and CButton. When I needed a new dialog I would derive it from CDialog and give it some members like CButton and CTextbox. I would then create a "data" class where I actually stored the values that would be in the textbox and what ever else data was contained on the visible dialog. Then when I drew the CDialog derived class on the screen by calling its "Draw" method, the textbox controll had a pointer to a character array in the "data" class. In this way the data for the dialog was persisted and all the changes were stored in the dataclass while the GUI class could be created and destroyed at will, any changes that needed to be made didn't have to locate the gui objects (which were often in a depth sorted list), the changes would be made to the data class and the GUI classes were responsible for rendering and dealing with any changes in the data class.

In the future, If you are going to be doing anything beyond the simple menues in your game, build a resource editor that enables you to do Drag and Drop to build GUI components. It will save you countless hours of torment and well worth the investment. If i was to do it again, I would make small scripts that could be associated with each button so that functionality could also be implemnted at run time via this editor. You wouldn't have to re-compile every time. It's a little overkill however, at a minimum I would make a resource editor.

I've attached an image of my Old editor in action *sigh* i kinda miss that GUI :_ )

I used to be the guy that vehemently opposed reinventing the wheel. I wanted to move away from learning how to write the fastest line drawing routine to developing content and hence used APIs - Turbo C's graphics initially, then Windows API. I worked in the film industry developing plugins for Maya using its scripting language MEL and its C++ API. I soon realised that I was painting myself into a corner and was becoming addicted to APIs! I was always looking for APIs to help me code.

I am now trying to repent for my sins. I started reading "Code" by Charles Petzold to learn how a computer works and had several a-ha moments that previous posters have mentioned. However, you still gotta stop somewhere. There is an enormous amount that is yet to be learned and not enough time for it. You stop at a level of abstraction that is comfortable to you.

Isaac Newton said "If I have seen farther, it is because I sat on the shoulders of giants". If you have the time, you could redevelop everything that others have done before. Since you have the absolute control it maybe most suitable to what you are doing. But is it worth the time you are investing? The libraries, APIs done before are possibly as fast as they can be, proven in production and well-tested. It may not be possible to give the same guarantee about your own code. And finally, computers are extremely fast nowadays. Is it worth shaving off a few milliseconds with your super-dooper fast code?

But having the knowledge to develop something from scratch is valuable. If you have it, all power to you. Those that dont should strive to gain it but use APIs in the meantime.

IMHO of course.

(edited for clarity)

Originally posted by jaggu
But having the knowledge to develop something from scratch is valuable. Whether you have the time to indulge in it is the question.


Absolutly, and I would argue that as an indie developer trying to make money and maby go full time, it's in your best interests to get your game out the door and selling copies.

Meaning you probably dont have the time to indulge in re-inventing the wheel.

For me it has always been a no-brainer. I've never had any money available to spend on resources (including my computer, 70% of it hardware that friends and family considered useless/worthless and gave to me for free). I'll always look for APIs first, but I have two strict requirements: (a) the API does what I want it to do and reliably, and (b) that it be free. When I started my project about three years ago, I found all free gfx apis at the time to be far too limiting, potentially glitchy or having missing/non-implemented parts, or just plain difficult to use. So I ended up making my own.

It didn't take me very long to get functional graphics and input systems up and running, using Directdraw and DirectInput as the hardware abstraction layers, and using JPEG/PING libraries for image compression. About two months for the bulk of it, really (most of that time was dedicated to figuring out how to use ddraw/dinput). Since then I've put a lot of hours into improving the graphics end, making it easier to use and adding some pretty rare and oddball features and functionality. But I also acknowledge that I'm not nearly as good a gameplay coder as I am an engine/system coder, so this route kinda lends itself to my personal strengths.

And, of course, I worked on Mikmod for three years prior to that, so that's what I use for audio. Fortunately, I haven't had to touch it in years, except to add ogg vorbis support the other day. :) And I used the Ogg libraries -- I didn't write one from scratch... ;)

- Air
- Hour 13 Studios (http://www.hour13.com)

Well, as I have thought after I am also using prebuilt libraries like Armadillo, Dx, Opengl or Bass. Afterall we all use proprietary libraries in some way. It would be very hard to code nice graphics like in the pre-VESA time, where one has to program for every vga card. Not to mention the sound card hell. :)

Originally posted by bernie
Well, as I have thought after I am also using prebuilt libraries like Armadillo, Dx, Opengl or Bass. Afterall we all use proprietary libraries in some way. It would be very hard to code nice graphics like in the pre-VESA time, where one has to program for every vga card. Not to mention the sound card hell. :)

Direct3d is almost like that again these days. Especially when dealing with vertex or pixel shaders. All the device caps are different. DirectX fails as a standard on that level. It would be nice if we directx enforced a support level for each card and we could rely on every piece of hardware being able to handle the calls in the interface. Must be nice programming for xbox or ps2 in that sense. Uniformity of hardware... mmmmmm

That's actually a very valid point. Being someone who comes from the DOS hayday of mode 3h and modex and vesa and the like, I can attest that basic unaccelerated DirectDraw is considerably more complex than doing some basic Mode 13h/X stuff, and still a good bit more difficult to set up than even Vesa still (and vesa wasn't too easy to use, being a BIOS interrupt extension all)-- Even though the end result is nearly the same (ie, fullscreen software-rendered gfx).

But both of those hinged on the fact that back then hardware standards were of upmost importance (and consideration for accelerated options was nil). Without a HAL, the hardware had to be the HAL in itself, which meant features were limited but were also guaranteed. Nowdays hardware vendors chuck features onto cards in whatever ways they can see fit to squeeze them on, and then just hope they can factor in support for those features via DX and OGL as HALs.

OGL stays independant of most of that stuff, while DX, being the more competitive product and adhereing to the Microsoft approach, tries to be the give-all and end-all of card-specific feature sets. It doesn't always seem as interested in finding ways to make a coder's life easier as it is in finding a way to pass a database-worth of information from manufacturer to coder, so the coder knows what he must do in order to get things to work. Interestingly, VESA did the same type of thing really.

- Air

Originally posted by svero
Direct3d is almost like that again these days. Especially when dealing with vertex or pixel shaders. All the device caps are different.

True, but the shaders are a world better then the TSS nightmares. At least with the shaders, you know you have some numerical level of support (1.0/1.1/1.2/1.3) and if you work within that spec, everything "should" work. With TSS, you have all of those details you can't even get from the caps. All the little things like, on some cards you can only use the vertex color as arg2, or you have to swap args 1 and 2 if you use a particular blend mode, or you can only use alpha in the second stage, or all the little pain in the rear things like that.

Almost and also at the cutting edge. But it is nothing compared to the old trident, tseng, s3 etc. compatibility problems. Not to mention the hercules, cga, ega cards. There were differences even in the textmodes. My dx6 code works perfectly on virge, 3dfx, riva, ati or geforce cards. Furthermore all underlying codes are organized into layers which means I can use glide, opengl or sdl device and those cover every card on the market. Of course I don't use any extensions nor shaders.
I think any technology needs some time until it settles down. Like the hardware acceleration on consumer level a la diamond edge. It took 4 years until it was available in every card. In the same way shader technology or Cg both need some time before they get in the mainstream.