So I'm starting on my own little "engine". I put that in quotes because it's not some sort of all-in-one engine like you might think of when you hear the word. This is more of a collection of modules that I can use. For instance I'm going to have a sound module (which might even consist of sub modules like streaming, ogg decoding, etc), input modules (for keyboard, joystick, xinput, etc), rendering modules (probably have a 3D and 2D module, perhaps put them together, not sure yet). So either way, right now I'm just coding very basic stuff. Starting with math library stuff, a memory management system so all of my objects can be managed, creating various templates for singletons and things like that. My question to you all is, what should I think about NOW that will be too late to think about once I'm working on the real meat of this project? Memory management was a big one on my list but I'm also wondering about things like multi-threading, some sort of a logging system, performance monitoring, thing like that. Any help or links to articles or book suggestions would be a great help! But please don't link me to the Enginuity tutorial that is here on GameDev. I already read it all, it only covers a tiny amount of actual "engine" code and then it just stops (and from what I've heard it's because the structure that was being created wasn't all that great.) Thanks a lot GameDev!

http://scientificninja.com/advice/write-games-not-engines

Quote:Original post by bubu LV
http://scientificninja.com/advice/write-games-not-engines

I'm using the term "engine" loosely here. If you read my full post you'd see that. I'm not trying to create some all-in-one engine that does it all. Just a collection of modules that can be put together and organized however you want in order to make a game.

There's no point in rewriting render code every time you create a new game. There's no point in rewriting audio code every time you create a new game. There's no point in rewriting input code every time you create a new game.

These are all modules that can be created one time and, if they are created properly, then they can be reused over and over again.

So...while I appreciate your response, I didn't ask for anyone to tell me why or why not to do what I'm going to do. I'm doing it because it's a good way to stay in touch with my programmer side and it's fun. What I asked was are there any caveats that I should consider before I dig too deep into this project.

Edit: Perhaps I should call my "engine" a set of libraries instead. Either way I'm writing them not to "make my dream game" or any of that business. I'm just writing this because I'm bored and it will be fun. I'm not attempting to distribute this for anyone's use but my own. And I'm not even gearing this towards a specific type of game or anything. If I get done with these libraries and cant use any of them for anything then that wouldn't bother me one bit (altho that's pretty much impossible). Let's face it. It doesn't matter if it's a FPS, a shmup, or a tetris clone; the process of playing a sound effect using OpenAL, or streaming an OGG using OpenAL will still be the exact same code. So why rewrite that code every time I'm making a game? Why not just make a very solid sound module/library/engine and use that every time?

"Engine" is a perfectly good word for what you are trying to do, and bubu LV's response is appropriate. What that article is saying is that your question cannot be answered without the experience of having written a few games and having learned what you will need those modules to do.

EDIT: Oh, and this is obnoxious:

Quote:If you read my full post you'd see that.

If you read the first paragraph of the linked article, you'd see that what you are trying to do fits perfectly in their definition of engine.

Quote:I'm using the term "engine" loosely here. If you read my full post you'd see that. I'm not trying to create some all-in-one engine that does it all. Just a collection of modules that can be put together and organized however you want in order to make a game.

But what you want is called engine... May not be all-in-one, but it's still called engine. Anyway, you should design your stuff to be fast and easy to use. If you collect portions of code and then you forget about them or how to use them then you fail. Give good names, comments and keep code clean.

Most important about designing the code you need to think how your games will always look (as code) and how each class/object from your collection will interact with each other. I had to rewrite a lot once because of this and was an unpleasant lesson.

But as bubu Lv said, you build the engine while making a game, otherwise you need to be a genius or something to preview all the things you may need.

Quote:Original post by Holland

Quote:Original post by bubu LV
http://scientificninja.com/advice/write-games-not-engines

I'm using the term "engine" loosely here.

<...snip...>

That is a good article to read though :). In the "engine" modules I have developed, particularly in the communications, I had to implement multi-threading as I expect more than 1 client to connect (via TCP). Also, the "engine" has many tasks to process - farming out process parts to other modules - while waiting for a command. So, that would be my recommendation.

However, a logging process was implemented as a I wrote code - nothing more than a globally accessible function WriteLog using basic File IO with a message. I would do this first because it allows you to 'debug' without watching your debugger.

After you have the logging and multi-threading done, then your monitoring. IMO, I would go in that order. :)

Quote:Original post by ddboarm

That is a good article to read though :). In the "engine" modules I have developed, particularly in the communications, I had to implement multi-threading as I expect more than 1 client to connect (via TCP). Also, the "engine" has many tasks to process - farming out process parts to other modules - while waiting for a command. So, that would be my recommendation.

boost::asio does this. Already implemented.

Quote:However, a logging process was implemented as a I wrote code - nothing more than a globally accessible function WriteLog using basic File IO with a message. I would do this first because it allows you to 'debug' without watching your debugger.

ACE does same as boost::asio, but comes with all of that, plus everything else you might need in C++.

Quote:For instance I'm going to have a sound module (which might even consist of sub modules like streaming, ogg decoding, etc), input modules (for keyboard, joystick, xinput, etc), rendering modules (probably have a 3D and 2D module, perhaps put them together, not sure yet).

What is wrong with SFML or SDL, which do exactly that?


One thing is often forgotten when talking about engines, or learning about them. Engine craze existed years ago, simply because there was no alternative. There were no standardized C++ compilers, OS APIs were rapidly evolving or there were several competing ones, hardware architectures changed, ....

This is no longer true. For almost everything there exists a library today. So unless there is some large, long term benefit to be gained for large number of developers, rolling your own simply isn't needed anymore, or is done trivially.

Same thing happened in Web development. Just a few years ago, everyone was hacking their own PHP sites. Today, there is a select choice of high quality tools that go a surprisingly long way with minimal effort.

At the same time, the cost of development of such tools/frameworks/engines has risen exponentially. If single developer could produce well rounded results, it takes large teams today.

Only 15 years ago, it was not unusual to hear about a guy writing an OS from scratch, and one that was usable and comparable to what was available back then (namely, DOS).

Times change...

Quote:
I'm using the term "engine" loosely here. If you read my full post you'd see that. I'm not trying to create some all-in-one engine that does it all. Just a collection of modules that can be put together and organized however you want in order to make a game.

Asking these questions means you don't really have a clear goal, yourself, of the kind of functionality you'll need from the code you want to write -- regardless of whether or not you're calling that code an 'engine' or whether your use of the term agrees with mine or anybody else's at any given point in time.

The thing to take away from my article for your scenario should really not be that you don't have the experience to pull this off (maybe you don't, maybe you don't) if you have to ask these questions, but that if you have to have these questions you don't need that functionality yet.

YAGNI ("You aren't going to need it") is a good thing to embrace, it will make you a better programmer and a better designer of software systems. Build your games, when your game needs a feature, build it. If that feature is obviously game-specific, put it in the game code, otherwise put it in some more common shared code. Don't think too hard, you can always refactor later.

I'm not a fan of people linking the scientific ninja post about engines... People come here to get help, advice and brainstorm with other great minds. There's no need to slap a link on someone's face.

So I'm going to actually answer your question. I'm a huge fan of system architecture, and I love coming up with different ways for engine modules to be pieced together. I've written a few engines now, from a PC-OpenGL/DirectX based engine to an IPhone Engine. I've also worked on a Wii/360/PS2/PSP multi Platform engine.

First off, What platforms are going to be supporting? If you plan to only support one platform with this engine, then that simplifies things a lot.

Try to think about how the important modules are going to be accessed. (i.e You have a Texture manager, that stores/creates/loads textures. How is the Entity that you're making going to get to the Texture manager, is it going to be a singleton that can be accessed by anyone? Does the Texture manager just hold a bunch of static functions that do what you need? ).

Really it all boils down to...if you're making this engine ( collection of libraries, whatever you wanna call it ) for yourself. Try to think about how you're gonna make this easy on YOU to make a game.

The article is sorta right in some aspects.. try to think of SOMETHING anything that you can make with this... its the only way to test a module and see if that's exactly how you want a module to work, perform, be accessed etc. etc. Cause you can write a Sound Module, have it have every accessor function in the book, but it might not be whats best when you hook it up to the Bullet's explosion. If you don't want to make a game, try to create a Demo Engine that has a quake style console, lets you load models, shaders, that sorta stuff.

If ya have any specific questions, don't be afraid to ask.