Jump to content

  • Log In with Google      Sign In   
  • Create Account


Writing Game Engine!


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 zigzak   Members   -  Reputation: 109

Like
0Likes
Like

Posted 12 June 2013 - 03:47 PM

Friends I want to write C + + using the game engine. Already writing games using c + +. I believe that an adequate level. I command the C + + language. How long it takes to write the game engine? How to write C + + suitable?



Sponsor:

#2 Khatharr   Crossbones+   -  Reputation: 2817

Like
6Likes
Like

Posted 12 June 2013 - 09:30 PM

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#3 Aldacron   GDNet+   -  Reputation: 3054

Like
0Likes
Like

Posted 12 June 2013 - 10:58 PM

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.



#4 SuperVGA   Members   -  Reputation: 1118

Like
0Likes
Like

Posted 13 June 2013 - 12:33 AM

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

Yet I'm convinced if zigzak had written games before, he would know where to start, or have an idea as to where to start.

It looks like he's got nothing.

 

@zigzag, you may want to think in subsystems. Whan have you written so far? (as in lifetime experience)

Do you know how to get rendering to work using C++, and what graphics api do you prefer?

Also, by being adequate in C++ you are by no means commanding the language.

I've been programming for 18 years, C++ for 5 years, and I often feel like I'm still just exploring it.


Edited by SuperVGA, 13 June 2013 - 02:25 AM.


#5 SimonForsman   Crossbones+   -  Reputation: 5752

Like
0Likes
Like

Posted 13 June 2013 - 12:41 AM

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

 

If the motivation is to just make an engine and you need to ask how to go about it then that advice still applies, engine design without experience is a recipe for a bloated unusable mess that won't actually be usable for making real games.

 

The only difference i would say is, if the goal is to get an engine rather than a game, keep that goal in mind as you make the games.


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#6 Khatharr   Crossbones+   -  Reputation: 2817

Like
0Likes
Like

Posted 13 June 2013 - 02:08 AM

 

The advice I've seen from people who have made engines (myself included) is as follows:

 

Don't make engines.

 

Instead, make a game. After that make another game, and use some of the parts from the first game. Continue this way until you have a big collection of commonly used parts. That's your engine.

 

That's great advice for someone who thinks they need to make an engine before they make a game. When the motivation to make an engine is just to make an engine, not so much.

 

 

My goal was to make an engine. I should have just made games and derived an engine.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#7 Nyssa   Members   -  Reputation: 426

Like
0Likes
Like

Posted 13 June 2013 - 07:05 AM

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.


Edited by Nyssa, 13 June 2013 - 07:11 AM.


#8 SimonForsman   Crossbones+   -  Reputation: 5752

Like
2Likes
Like

Posted 13 June 2013 - 10:41 AM

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.


Edited by SimonForsman, 13 June 2013 - 10:41 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#9 SuperVGA   Members   -  Reputation: 1118

Like
0Likes
Like

Posted 13 June 2013 - 12:38 PM

 

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.

 

 

Partly because I'm interested in your perspective, partly because I think OP could benefit from hearing more, would you, SimonForsman compile an article (or point to one)

about how to evade the pitfalls you mentioned? I've rewritten my engine several times over, but something makes it so I can never really take pleasure in working on an actual game.

I like my project, and from making smaller games earlier on, I do believe I know what I'm doing.

 

But what you just wrote sparks that fear, that although I do my best to create a diverse, powerful engine, it will come short once I want to apply some more abstract game to it.

I guess iterating is always good, stopping up going "Aha. GUI and Messaging system is now complete. Let's create a form-based game." Next, random landscape generator using the forms from before etc.

 

But I don't know for sure. I've never finished one engine. Games. But not engines. And although I'm convinced I know how the things I write now should be used,

perhaps it's not actually a good way to go about it.


Edited by SuperVGA, 13 June 2013 - 12:53 PM.


#10 Nyssa   Members   -  Reputation: 426

Like
0Likes
Like

Posted 13 June 2013 - 02:48 PM

 

 

I should have just made games and derived an engine.

 

The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.

 

To answer OP's question, I started writing an engine 5 years ago and I haven't finished yet. If you want to write a game then I'd suggest pick an already complete engine that suits you and focus only on creating a game. If you want to write an engine then go for it! It's fun, you learn lots, but just be aware it can take a long time.

 

 

If you've worked 5 years on an engine without making any games with it you might have a big problem though, you got 5 years worth of work that hasn't been properly tested. Making complete games using an engine is the only sane way to test its design, performance, stability and workflow(a big problem with many hobbyist engines is that they are virtually unusable for large projects, despite shiny tech demos) issues tend to pop up quite quickly when you try to use pretty much any engine(even good engines have issues, allthough they tend to be less severe) for a real game and you want to catch the major issues as early as possible.

 

 

This is true, and it's true about any product that is created, not just software. However if you have a background in what it is you are creating, set out with some clear design goals, and use an iterative design through regular testing then problems will more likely be caught early too.

 

But yes, the best way to test any product is to use it in a real life situation.



#11 phantom   Moderators   -  Reputation: 6785

Like
3Likes
Like

Posted 13 June 2013 - 02:53 PM

But I don't know for sure. I've never finished one engine. Games. But not engines. And although I'm convinced I know how the things I write now should be used,
perhaps it's not actually a good way to go about it.


That's because you never finish an engine - they are always changing and evolving as you learn and find weaknesses while using it.

Which is kind of the problem with trying to develop one on it's own; unless you are constantly using it you'll never know how much works and how much is flawed.

Even at work, where we have a small team developing an engine, it is being driven by customer game requirements and ideas.

#12 SuperVGA   Members   -  Reputation: 1118

Like
0Likes
Like

Posted 14 June 2013 - 12:59 AM

 


That's because you never finish an engine - they are always changing and evolving as you learn and find weaknesses while using it.

Which is kind of the problem with trying to develop one on it's own; unless you are constantly using it you'll never know how much works and how much is flawed.

Even at work, where we have a small team developing an engine, it is being driven by customer game requirements and ideas.

 

So would you encourage me to first create small games with the different subsystems like I described, and then create new, different projects on it over and over when all subsystems are finished, to mature it?

(Sort of a rhetorical question, I guess, but maybe you have a better idea...)


Edited by SuperVGA, 14 June 2013 - 02:00 AM.


#13 Hodgman   Moderators   -  Reputation: 27478

Like
3Likes
Like

Posted 14 June 2013 - 01:28 AM

A generic engine is too nebulous a concept, it can be so many things, that in isolation, it will never be done. There's always more things it could be doing, or better ways in which it could be doing the things it already does.

 

IMHO, an engine needs to be driven by a customer. ID Tech is always driven by a new Quake/Doom/etc, Unreal Tech is always driven by a new Unreal/Gears/etc, CryEngine is driven by a new FarCry/Crysis, an so on.

Gamebryo failed because they never ate their own dog food (they made/sold a crappy engine, without ever making their own games on it).

The "dog food test" should always be applied to an engine, so I'd avoid others like BigWorld, etc, as they failed to make a game on their own tech...

You have to eat your own dog food.

 

Pick a game you want to make, figure out what feature that game needs from an engine, and then develop your engine to support those features!

Also, the only way that you can test whether you've done a good job is to actually make the game! So, you should always make the game in parallel with the engine. Don't finish the engine first and then make the game, because that just wont work. You will find problems with the engine once you try to use it, and you will have to re-do engine work while making the game, so make them side-by-side, so that they can both influence each other.

 

Then if you want to keep making the engine, make another game using the same process!

 

 


The two are mutually exclusive in my opinion. You either write what you need to make a specific game work or you write an engine that allows you to make several games once that engine is complete. Otherwise you'll quickly loose focus and never finish what you started.
I started writing an engine 5 years ago and I haven't finished yet.

I think you just disproved your own point. You're making an engine that has no specific finish line, no goal, no hard list of requirements to fulfil, and no way of evaluating/testing it's merit... so you've not finished wink.png

Having an explicit purpose for the engine (it must support the needs of this game) gives it a solid focus, and a framework for evaluation.


Edited by Hodgman, 14 June 2013 - 01:32 AM.


#14 Nyssa   Members   -  Reputation: 426

Like
0Likes
Like

Posted 14 June 2013 - 09:50 PM


I think you just disproved your own point. You're making an engine that has no specific finish line, no goal, no hard list of requirements to fulfil, and no way of evaluating/testing it's merit... so you've not finished 
Having an explicit purpose for the engine (it must support the needs of this game) gives it a solid focus, and a framework for evaluation.

 

Maybe I was far to broad in my statement. When I started, I had specific design goals from previous experiences, an end goal, and time frames. Of course I didn't always meet deadlines but I did my best to meet them. I set sprints on work and goals to achieve and that kept my motivation high. I did achieve what I originally set out to achieve and I am happy with with my efforts. By not finished I meant things like bug fixes, optimisations, and "nice to have" features. I had purpose when creating it, and it was being designed side by side a game, a number of games over time actually. 

 

What I found difficult being the only coder was the artists needed to see the game coming together to keep motivated (which is totally reasonable and I understand that). If I didn't stay on top of the game then it would hinder their workflow of iterating over the artwork and animation to improve on it. The issue there with me was the game was dependent on me getting some feature in the engine working, not necessarily finished, just working. So it became a situation of constant context shifts for me as to not slow the artists down too much.

 

In my current position we have an engine team, and product teams. The product teams can focus on making the products that are customer driven, without worrying too much on how the underlying tech works. While the engine team can of course just focus on the core tech. If the customers want some new tech then that obviously falls on the engine guys. In this separation it is rare for a team to slow another down. 

 

So the point I was originally making was it can be hard as a lone coder to create a game and reusable engine side by side.

 

I agree with everything that has been said about game engines failing because they have not passed the "dog food test". I've used gamebryo and it was a horrible mess.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS