What would you do? I would probebly end up with a 100cc engine.

id say it would be reletive as to what you wanted it to accomplish...

ok, I'll define large project..... an fps comparable to doom :D

it'll take me years to get to that point

id say youd want everything in there, but only very general stuff so the engine could be re used for any 3d game.

yes i'd agree , anything that you can reuse later

Normaly it is a good idea to estimate the time you need the multiply it by 3 or 4 and then you will have an approximativ value of the real time you will need. I'll assume that "years" means 10 years, so we will end up with 40 years. Now assuming that a person starts working with 20 and retires with 60 then this will be a whole life's work.

I voted for MFC like because it's rubbish to judge code on it's size anyway.

PS: what's cc?

im assuming "cc" refers to cubic centimeters- what a lot of engines (in the us anyway... especialy for off road vehicles) are measured in.

Small, the simpler the better.

Game making tips:
Make a few really good objects and reuse them instead a million crappy ones.
Don't be afraid to hardcode stuff when needed.
Hard coding is way better than having to pass long parameter lists.
Nobody cares about a story line.
Unless you have time to waste pick a game stile has no story line and even the world/levels are reusable.
If your game is going to be multiplayer I think you should consider dropping the single player mode altogether.

I though you'd use cm³ for that?

there interchangable, they both mean the same thing

if you mke the engine too big then you loose sight of actually making the game, unless your objective is to make an engine sdk in which case make it as large as possible!

my personal belief is that there should be 2 maybe 3 levels to an engine. the core should be just that a cleanly written very fast heart to your game. the second level / part should be the translation level which should include code that translates your game data files to information your core engine can understand. such as a script parser, and resource manager. the 3rd otional componet is for online games which is the networking componet which is pretty much self explanatory.
the reason i believe the first part should recieve the most work is becasuse it is responsiable for dislaying your graphics and controling hte movement of your world. this is the area that should recieve the most work because it would realy suck to have a game that requires a 4 GHZ processor. i remember when i got tribes vengence and saw that it required a 1 GHZ processor as a minimum requirement the first thought i had was they should have been able to cut some fat out of the game somewhere.

uh, don't call me noob, but I'd like to know the exact definition of 'engine'. I thought it was a piece of code about something you wanted to repeat a lot in your program and didn't want to write it every time you wanted to use it... but, how can a code be measured in cc??? :wacko: that makes me think of a car engine :mellow:

yeah I allways thought they measured coding by the line

I think he's simply using it as a hypothetical measurment to see how involved/complex the engine should be. For instance 50cc might be just a few functions/structs that make things a little easier to do a certain task. 200cc might mean an engine the size of DirectX.

I'd agree with Consumed. Expect an engine of 200cc is more comparable to GameMaker, while 50cc is just OpenGL/SDL etc. and a few 'homebrew' functions to make drawing a pixel easier, for example.

Gamemaker < OGL.
Gamemaker sucks.

example of an engine ogre3d , crystal space , NeoEngine etc ...

I have a nice game made with Gamemaker and c++...

how can it be nice if it's made in GM :blink:

While GM is a learning tool, it CAN be used to make good games. I don't really use it anymore, but I don't see why people just bash it. I bet half of you have never even tried it. But I have to say that OpenGL, SDL etc. are more 125cc, I didn't realize there depth before.

I have tried it and it sucked
even the most trivial of games made in is slow and resource hungry
also the GML thing teaches *young coders* aweful habits
makes them beleave its so easy and that it's the best thing out there
and some never quit it
there are ofcourse a few rebilitated
but compare that number with the number of uber n00b's it creates

some noobns gets GM makes some cheep *game* starts thinking he can actualy
can make games

True... a guy I know is using GM to make... you guessed it, an MMORPG. and just because he has chat and people wlaking around, he thniks the easy bit is over. And he plans to store all info client side... And I tell him to try C++, and he says no, GM is... better. So I get what you mean, but it DOES have a purpose.

and i bet that MMORPG takes 2GHz+ with 256MB ram as minimal requiroments
and when 10 people connect it crashes

how come c++ is designed to be "better" than GM? How can you design something like that to be better?

C++ is a programming language, there doesnt have to be a compiler for it, because the language is more theoretical (thats how it first started)
GM is a program which has its own language (which is similar to c++ syntax wise) but GM interpretts it and the techniques it uses makes it go really slow.

c++ was invented in 1980's ( looooooooong before GM ) and standartised in 1997
( still no GM then ) . Its designed to be better then C (witch was invented in 1970's for
the purpose of making Unix ). GM just copied the syntax for it's own sripting purposes.
scripts are interpreted hence real slow and consumed more resources.

Also, GM is limited to the functions built-into it, which are still very primitive compared to todays vertex shaders and mutli-threading, etc.

That's true, GM was invented 1999. For those who's interested: Read this

Id imagine my engines getting too big when i start doing this just to access and x coordinate:

(started to appear after i had to change my engine from allocating related std::vector<> objects through pointers (as the memory location of the entire list ended up changing every time i 'push_back()'d), and had to replace the pointers with using the objects index in the list instead..)

I was immediately put off GM.
There were so little options to do anything solid, and everything was so inefficient.
The buffering was poor too. i get the same results setting up my own double buffer using gdi.

I honestly dont think gamemaker has a place. Simple languages such as BlitzBasic offer far better results with less effort, assumming the user is willing to learn what the 'effort' involves.eg:

fast Direct X results with perfectly smooth doublebuffering, syntax highlighting....and much more control also being able to use dll code made in eg:c++.

GM is frustrating to me: it takes longer to do anything involving the menus etc, instead of just typing a few words...

Seeing how quite a few people dislike gamemaker (including me), it made me smile when I read this email (Sent out to informatics staffs & student at the University of Edinburgh recently).

:D :rolleyes:

lol. I didn't quite get that, is there a competition, or do you learn :P my bad english fault

well i don't program games in c++ only dlls for games i program in an interpreted language. Anyways I like to make my engine core self explanitory so that if I wanted someone else to help me that would understand everything going on and I wouldn't have to explain it. I like to make my engine complex enough so that when I'm completed with my engine I can start making my game and never look back. When I program the core I don't really program it to be a perfect mold for my game. I program it so that it will do whatever that type of game needs to do.

So if I'm programming a turn based strategy I'll program the movement and attack system into the core. I won't enclude character attacks and stats into the core, I put those into an independent part of the engine. This way I could easily make another turn based strategy totally different from the first.

You know.. this topic was 4 months old.