next »

[Evan Balster]

The title of this topic is, I think, some kind of Oscar Wilde reference.


So I'm 'that guy'.  The C++ game developer who's writing his own engine, "plaidgadget."  Fool!  Egads, don't you know what you're getting yourself into?  For the love of God, just hack it until it works!  I know.  I've heard it all.  It'll come around and bite me in the butt.  Right?

As far as I know lots of fellows like me write out engines with the intention of releasing them, so that one day others might develop games using said engines.  But as more abstract approaches to game development become popular and more game engines pile up is anyone really apt to put to use something a dorm-room coder the likes of me made?

And the more relevant issue: is game programming made a slower process when one commits to separate the engine portion of the code from the game portion?  Could it be more efficient, perhaps by improving debuggability?


A quick rundown of plaidgadget's specs: (quite possibly to appease my starved ego)

• Focus: 2D (or "2.5D") games with discrete-color vector graphics.  (Think toon-shading, but not necessarily with the shading bit)
• C++
• Cross-platform
• Re-inplementable (uses SDL, could use other APIs with minimal modification)
• Supports object-graph serialization and runtime reflection
• To support scripting in Python
• GUI system
• Relatively simple control calls like player.keyboard.up.pressed()
• "Views" graphical system makes it so there are no "absolute" coordinates, for easy skeletal animation, GUIs, cameras, etc
• Common utilities like random number generation, geometry
• OCD-level object-orientedness (no global variables, virtually no global functions, possible to have two games running simultaneously in one executable assuming underlying API can handle it)

[Mipe]

Yeah, those game engines are popping up like mushrooms after rain... perhaps it would be more worthwhile to develop widgets/plugins/addons/libraries/thingamajigs that you plug into existing game engines, like you would add a wheel to the car.

But no game engine will really bust the block until the awkwardness of code wrestling is overcome. I am following a project that aims at non-coder friendly game development. It would depend on these widgets for added functionality (such as Box2D physics).

Think Lego.

Edit: funny, just realized you touched that subject in another thread you created. Deja vu.

[Glaiel-Gamer]

There is a great sense of accomplishment when you open up a blank c++  project and begin typing:

int main(){

return 0;
}

and it leads to a game. from scratch.

There's something WAY more satisfying about doing the engine work yourself instead of using a prebuilt one.

Also the end result if you know your own engine better than any other engine out there.

Point in case for me: Box2D. In order to get it to actually do what I wanted to, first I had to learn how to use the engine (a couple hours for me, it's an easy engine). Then I had to learn how the engine works so I could edit it to do what I actually needed it to do (~3 days, then the following 2 weeks). Then I had to hack in my hack (1 plane ride for basic functionality (for some reason I work 10x faster on planes), then a week to finish it and 2 weeks to polish and integrate).

A lot of that time was just trudging through the internals of the engine, cause I had no idea how it was structured or how it worked.

When I need to do that level of hackage in my OWN engines, it takes me 1/4th the time.


There's the other fact, the more external libraries I use, the more often one of them will break (no code is perfect), and let me tell you finding a bug that is not caused by code you wrote is HELL. Believe me. I've used flash heavily since version 6, and AS2 was a very buggy language.

[Evan Balster]

It's definitely more rewarding, and easier to work with. But at the same time I see other people's projects in dev hell owing to a fixation on writing a quality, reusable engine. That seems silly. I doubt I'd even be content to use the thig again after completing my project, knowing how by then I'll have grown as a programmer and learned all sorts of new tricks. Conceivably I might use the engine tohammer out a few quick gamelets while the main project is still underway, but beyond that...

Glaiel, you do make a good case for writing one's own engine, if only for the ease of debugging and addition of new features.  The question that leaves is whether there's much of a cost generally implied by having a separate 'engine' component of a game's code. I guess that's mostly just an organizational thing.

[Kekskiller]

I usually think it's easier to write an own engine. You know, it can be a pain to learn other engines or technologies. I don't want to learn a scripting language for somewhat bigger engines, or how they manage this and that, which functions here and there, maybe where to get editors, etc... It's easier to enhance your own toolkits. And it's satisfying, cause you know what you've done. That's I'm coding my own engine.

[David Pittman]

I love writing my own engine. I think it is rewarding in and of itself (for most of the same reasons Glaiel already mentioned). But I'm really only writing it for me, with a very specific set of features to support two or three games I want to make. I've been able to make judicious cuts because I know the needs of my entire user base. When you write an engine with the intent to release it, it's harder to make those assumptions.

I tend to agree with the suggestion that no one is going to use someone else's "dorm room" engine; I'm slow to trust any library that hasn't been put through its paces by both the author and a community of users. There's also a learning curve to become familiar with someone else's code. It took me maybe an hour or two to be certain I knew what I was doing with small, simple libraries like TinyXML and zlib; realistically, it could take days or weeks to become comfortable working with a robust engine. Finally, there's an implicit set of rules and constraints that come with any engine, and maybe those are well-documented and maybe they're not. The author has a ton of knowledge in his head while writing the engine, and he knows how all the pieces fit together and how to make it do whatever it needs to do. It is extremely important (and difficult) to communicate all of that knowledge to end users in a meaningful way.

I'm not sure I understand your last question correctly. Are you asking whether having your code clearly delineated between game code and (reusable) engine code is a bottleneck? That line is pretty fuzzy in my engine (and probably in most). Although I have separate libraries for major systems, I tend to treat the code base as a whole and will gleefully hack into those libraries as needed to support new features. I doubt there will ever be a time when I could just compile those libraries and never touch their code again. And yes, a well-organized engine is a lot slower to get up and running than a code-like-hell project, but the payoff is that it is more robust and reusable and easier to maintain.

[Tycho Brahe]

I've used flash heavily since version 6, and AS2 was a very buggy language.

Flash generally and actionscript is hell. The number of times I've looked over a piece of code I KNOW is correct, yet is doing something totally strange would shock most non flash coders. AS2 also really hates the whole timeline thing, for example on one project I was working on gotoAndStop() would only work when I compiled the project, not when debugging.

Thats why I use C++ 

[BorisTheBrave]

Flash generally and actionscript is hell. The number of times I've looked over a piece of code I KNOW is correct.

I've never had this in AS3.

Anyway, on topic: I have written many engines, but given up on most. But I've done the same for games, too, so perhaps I"m just a quitter. The joy for me is in "making it work", not all the niggling details of getting to production quality or producing levels.

There are too many engines, out there, and too little quality. So the logical thing to do is don't start from scratch, but join an open source project and make something good better (this is what I do for Box2D). There are projects like that going on on these forums all the time, though many programmers here have severe NIH syndrome (as distinct from other legitimate reasons to write from scratch).

Sure, as Glaiel says, it's generally slower to hack onto something you didn't write. But that's only because you don't know it thoroughly. It cannot be the case that it takes longer to grok a piece of code than write in the first place. And even if it did, you probably learned a load in the first place. Or because you skipped on yummy features.

Also, good libraries should be quick to learn, or at least get into. Vastly quicker than writing. Alas, most libraries/engine are not good.

[Dacke]

I guess it depends on what you want to do. Many people out there seem to think that game-making is about actually creating and releasing games. To me, programming stuff (like engines) is the most fun, while the games are just fun bi-products to show off to friends. It's like solving cross-words. Intellectual challenges and all that.

But if you actually want to create games, I think it is wise to not start with the engine-part. A better idea would be to do what (I think) for example Alec and Adam Atomic have done. They have created many games to begin with. The more games they have programmed, the more tricks they have learnt and they have learnt to identify commonly emerging game-design-patterns. Using their built up experience, they have then set out to create engines. But by that time they already know what features are important, useful and commonly needed. So their engines (or at least Adam's Flixel) is super-practical pieces of pure usefulness.

[st33d]

Whilst we're bashing Flash...

I spent my whole morning debugging the shitty implementation of the timeline in as3.

I would be jumping to the "game" frame of the timeline and Flash would execute the addEventListener code on items that would never be visited on the timeline. So I have events firing that I have no ability to halt because the fuckers are in situations I'm never going to encounter.

I'm constantly having to write if(timeline.currentLabel == "correct_fucking_frame") protecting my event listeners from being attached.

So why work with the timeline? Because I have to work with an artist hand in hand who needs to see the art there and then every five seconds. The artist is not the problem. I'm not the problem. You. You Flash are the problem.

[Eraser]

I love writing my own engine. I think it is rewarding in and of itself (for most of the same reasons Glaiel already mentioned). But I'm really only writing it for me, with a very specific set of features to support two or three games I want to make. I've been able to make judicious cuts because I know the needs of my entire user base. When you write an engine with the intent to release it, it's harder to make those assumptions.

I tend to agree with the suggestion that no one is going to use someone else's "dorm room" engine; I'm slow to trust any library that hasn't been put through its paces by both the author and a community of users. There's also a learning curve to become familiar with someone else's code. It took me maybe an hour or two to be certain I knew what I was doing with small, simple libraries like TinyXML and zlib; realistically, it could take days or weeks to become comfortable working with a robust engine. Finally, there's an implicit set of rules and constraints that come with any engine, and maybe those are well-documented and maybe they're not. The author has a ton of knowledge in his head while writing the engine, and he knows how all the pieces fit together and how to make it do whatever it needs to do. It is extremely important (and difficult) to communicate all of that knowledge to end users in a meaningful way.

I'm not sure I understand your last question correctly. Are you asking whether having your code clearly delineated between game code and (reusable) engine code is a bottleneck? That line is pretty fuzzy in my engine (and probably in most). Although I have separate libraries for major systems, I tend to treat the code base as a whole and will gleefully hack into those libraries as needed to support new features. I doubt there will ever be a time when I could just compile those libraries and never touch their code again. And yes, a well-organized engine is a lot slower to get up and running than a code-like-hell project, but the payoff is that it is more robust and reusable and easier to maintain.

I hate writing my own engine. It's time consuming and I barely ever get much finished with it. The downside of using premade engines is that they also have their defficiencies, and generally you don't know the internals of the engine like you would if you made it yourself.

[Glaiel-Gamer]

Whilst we're bashing Flash...

I spent my whole morning debugging the shitty implementation of the timeline in as3.

I would be jumping to the "game" frame of the timeline and Flash would execute the addEventListener code on items that would never be visited on the timeline. So I have events firing that I have no ability to halt because the fuckers are in situations I'm never going to encounter.

I'm constantly having to write if(timeline.currentLabel == "correct_fucking_frame") protecting my event listeners from being attached.

So why work with the timeline? Because I have to work with an artist hand in hand who needs to see the art there and then every five seconds. The artist is not the problem. I'm not the problem. You. You Flash are the problem.

AS3 is not shitty. AS2 is shitty.

Hint: addEventListener(type, function, false, 0, true) to make it automatically get removed when the underlying clip is removed

[Triplefox]

A finished game is some % engine and some % ugly hacks. The better your engine is, the smaller the hacks % is. The only way to know how well you did is to make a game.

This is true even with "Rapid development" software like GM, MMF, Construct, etc. because you are still obligated to code up some of the necessary hacks for your game, no matter how closely you hew to the engine built-ins.

[LemonScented]

So, why are you writing your own engine? By which I mean, are you writing it because it's your preferred way to put a game together, or because it's something you eventually want to release and have other people use? If it's the latter, the chances are slim that many people would be interested in it (there are plenty of engines out there already), but if you're actually working towards a game, cool.

For what it's worth, here's my take on things:

1) Don't "just" write an engine. Write a game. That way, you have a game to show at the end of it, and you have an engine to run that game that has been tested against the rigours of what a real actual game needs an engine to do, not a theoretical idea about what an engine "should" do. I was evaluating an engine just yesterday, and was shocked at how (a) it didn't come with any demo whatsoever to show off its capabilities, and (b) was based on design decisions which sound great on paper but which I know from experience can bite a game in the ass, big time.

2) If you are writing a game, writing your own engine is perfectly valid, in fact it's often preferable. As well as being fun and educational, you sidestep the problem of having to hack or debug unfamiliar code when the engine doesn't do what you want/expect it to do. Knowing how your codebase works gives you a lot of power. However, I wouldn't necessarily advocate reinventing ALL of the wheels. For my current project I've cherry-picked libraries for physics, asset loading/parsing, audio, and countless other bits and pieces. However, the renderer, the entity handler, the event manager, memory manager, maths library, all of that stuff that glues all of those libraries together into something coherent, is mine. It feels really good that way and is much easier to work with that just taking someone else's engine wholesale and trying to figure it out.

3) An engine (or, if you want to break it up for re-use later, a set of routines/libraries/components) is a great investment for the future. The oldest code in my current engine probably dates back to 2002/2003, and it's been tried, tested, debugged and optimised to hell and back. It's clean, it's modular, and it's been re-used more times than I can remember. Assuming I keep making games (it seems like a safe assumption), I'm likely to still be using some of that code (in an updated, modified or ported form perhaps) 10 years from now. I just build up the toolbox slowly, polishing and keeping useful parts and dumping the dirty hacky game-specific parts once a project is finished.

[mcc]

I feel like setting out to write "an engine" is by itself not a terribly good use of time. It seems like games are all so different you can't really predict ahead of time what any given end user of your engine wants, and especially if you are coding in C++ it's probably the case that a user might spend as much time learning how your system works as they would "doing it themselves". Coders probably fall into two categories, those who know enough already to implement their own engines, and those who don't know quite enough yet that they can just pick up your engine and start going without spending a lot of time learning it. On top of this, as several people have observed, it's not like there's a shortage of engines. I feel like there is more a shortage of good toolsets (i.e., I've downloaded this game engine, now how do I compile it?!) and good detachable singular components or sample code, like the libraries David Pittman refers to above, that do one single thing and do it well (i.e., if all I want is a simple game UI library, is there some way to get it into my program without installing this huge multi-megabyte "Ogre" library it's a part of?!). This is just how things seem to me.

I did myself write a rapid prototyping "engine" (although describing it as such may be overselling it because it is so simple, maybe it would be better to call it a game template) and I hype it in threads here occasionally (it's in my sig) but I created this only with the goal of creating it for my own use. I made a game and as I was writing it whenever I could lay things out in a reusable way, I did so (though I did try to avoid, whereever possible, spending actual time on making things more general than the game at hand strictly needed); after the game was finished I took a few weeks to go through and clean out anything that wasn't reusable, so I had a nice base for my next project or two. Okay, bang, that's an "engine". I think this worked out well. In this case I was able to provide exactly what the end user wanted because I was the end user-- I knew what kinds of things I was interested in doing next and I was able to make something that was a good starting point for doing these things. I did put what I'd done up on my website in case it was useful to anyone but as far as I know no one has ever used it for anything. That's okay. I got to use it.

I in general think it is most important to concentrate on the game you are making and worry only after about reusability considerations. I've known a couple of people who got so wrapped up in making this super-awesome game engine that they never got around to actually producing a game and, because the engine hadn't been tested by having an actual game living on top of it, they never got the engine to the point it was robust enough to release either. I do know some people (Dacke makes this argument above) don't really care if the game gets finished, they are making a game engine because they are enjoying writing an engine. I think that's fine? But you have to know what your goal is.

I do think a C++/OO game library like you're describing which is set out from the beginning for python integration sounds like a neat and useful thing. I think at a minimum I'd download it and use it for sample code to see how the python integration was done. I'm sure I wouldn't be the only one who would be to some degree interested in it. What I'm not clear about is whether you'd see people specifically starting projects with it from the beginning, for example I'm not sure I'd know of an exact reason why someone would specifically pick that engine over, say, cocos2d. I think that could be a very rewarding project but I'd try not to build up unrealistic expectations about how it will take off. My experience seems to tell me that the most important question you should be asking yourself is what benefit you will be able to get out of your engine building work, for example, will spending X amount of time on writing this object tree thingy in a generalized way save you Y amount of time cleaning out use-case-specific hacks when you adapt that code into a future project.

[Ivan]

I don't know, it's all about what you enjoy writing as someone said earlier. If you enjoy writing the engine part, then god bless you.

I've been writing an engine myself for nearly two years now and have been enjoying every minute of it. The fact that I will be (soon) releasing it to the public is just a by product of all the fun I've been having with it.

[st33d]

Whilst we're bashing Flash...

I spent my whole morning debugging the shitty implementation of the timeline in as3.

I would be jumping to the "game" frame of the timeline and Flash would execute the addEventListener code on items that would never be visited on the timeline. So I have events firing that I have no ability to halt because the fuckers are in situations I'm never going to encounter.

I'm constantly having to write if(timeline.currentLabel == "correct_fucking_frame") protecting my event listeners from being attached.

So why work with the timeline? Because I have to work with an artist hand in hand who needs to see the art there and then every five seconds. The artist is not the problem. I'm not the problem. You. You Flash are the problem.

AS3 is not shitty. AS2 is shitty.

Hint: addEventListener(type, function, false, 0, true) to make it automatically get removed when the underlying clip is removed

That doesn't work. It was the first thing I tried.

I even added a weak referenced onEnterFrame event to see if the object was persisting in memory despite never being visited on the timeline - and sure enough it was. Guess what happens when I actually go to the frame. I now have two events firing! Yes I know about added to stage events too, I tried those as well. Broken, broken, broken.

I like AS3, but you cannot tell me that they have not royally fucked up the timeline.

[Evan Balster]

I'm writing a game first and foremost.  I'm just making a point of keeping the engine code fully separate so I can work on other projects with it simultaneously, make ports, and write more games with the engine later.

Admittedly, though, I'm going to a lot of trouble to make a robust and decently general engine.  It is restricted notably to 2D (parallax) vector graphics with no color interpolation save for antialias.  (Alpha is permitted too, just without interpolating alpha values.)  The graphics restrictions center around a stylistic choice.

Incidentally: http://www.facebook.com/album.php?aid=332682

[floatstarpx]

I'm writing a game first and foremost.  I'm just making a point of keeping the engine code fully separate so I can work on other projects with it simultaneously, make ports, and write more games with the engine later.

This is the way I usually aim to do things. I think its the best way. You don't want to account for everything the first time round, just enough that it can be flexible in the future, and that it works.

I totally agree - if you end up writing an engine, you can fall in to the trap of trying to write code which is "too perfect", spend all your time doing this, and not thinking about what the game actually requires. You'll never get it perfect the first time, because you don't know the pitfalls yet!

[oahda]

So, why are you writing your own engine? By which I mean, are you writing it because it's your preferred way to put a game together, or because it's something you eventually want to release and have other people use? If it's the latter, the chances are slim that many people would be interested in it (there are plenty of engines out there already), but if you're actually working towards a game, cool.

For what it's worth, here's my take on things:

1) Don't "just" write an engine. Write a game. That way, you have a game to show at the end of it, and you have an engine to run that game that has been tested against the rigours of what a real actual game needs an engine to do, not a theoretical idea about what an engine "should" do. I was evaluating an engine just yesterday, and was shocked at how (a) it didn't come with any demo whatsoever to show off its capabilities, and (b) was based on design decisions which sound great on paper but which I know from experience can bite a game in the ass, big time.

2) If you are writing a game, writing your own engine is perfectly valid, in fact it's often preferable. As well as being fun and educational, you sidestep the problem of having to hack or debug unfamiliar code when the engine doesn't do what you want/expect it to do. Knowing how your codebase works gives you a lot of power. However, I wouldn't necessarily advocate reinventing ALL of the wheels. For my current project I've cherry-picked libraries for physics, asset loading/parsing, audio, and countless other bits and pieces. However, the renderer, the entity handler, the event manager, memory manager, maths library, all of that stuff that glues all of those libraries together into something coherent, is mine. It feels really good that way and is much easier to work with that just taking someone else's engine wholesale and trying to figure it out.

3) An engine (or, if you want to break it up for re-use later, a set of routines/libraries/components) is a great investment for the future. The oldest code in my current engine probably dates back to 2002/2003, and it's been tried, tested, debugged and optimised to hell and back. It's clean, it's modular, and it's been re-used more times than I can remember. Assuming I keep making games (it seems like a safe assumption), I'm likely to still be using some of that code (in an updated, modified or ported form perhaps) 10 years from now. I just build up the toolbox slowly, polishing and keeping useful parts and dumping the dirty hacky game-specific parts once a project is finished.

Haha. You are going to hate me.
I even made strings and vectors and that kind of stuff from scratch for my engine project.