Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

Pro and Cons to building a game engine

This topic is 2098 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

There seems to be a pro and a con to building a game engine having been on this forum for 10 months.

 

Pro: The code in engine can be reusable for other projects of many genres. Could be a good learning experience in building an engine.

 

Cons: Takes too long<---Just use an open source engine and build your game using that. Engine may or may not be limited to what you want your game to do.

 

This is the list of pros/cons after having read past post and now recalling them on top of my mind. Hopefully the list is accurate.

 

My question is: if building an engine takes too long, eventually when you need to use it, you can start popping out games using that engine when it is done because of the reusable code in the engine, no?

Edited by warnexus

Share this post


Link to post
Share on other sites
Advertisement
Yes. I think you are correct. You can even build on it making more features I believe.

I still recommend Unity to everyone if they don't need the advanced features or can afford the Pro version though, it is a great engine. If you are in college, you can get half off through a student discount.

But I realize there are other great engines too, though often harder to use. And hey, why not make your own engine?

Share this post


Link to post
Share on other sites

I agree with wintertime, I never developed a game (not even a simple one) but I still wanted to make an engine of my own (mostly for curiosity).

 

There were countless time I was lost like "what should I do next?". Even reading topics and books about it, there were plenty of things that I read and thought "do I really need this? What is this for?"

 

In the end, I decided to change the perspective and decided to code a prototype game instead, and then make the engine. I've read about how to manage states and such, and typed:

void InitialState::Initialize()
{
    //Image* myLogoImage
    myLogoImage = Resources.Load<Image>("LOGO");
    Scene.Add(myLogoImage);       
}
 
void InitialState::Update()
{
    counter++;
    if(counter > Time.Seconds(3))
    {
        Scene.Remove(myLogoImage);
        State.NextState(new MainMenuState());
    }   
}

I wanted a code that would show my logo for 3 seconds, then disappear, and go to the MainMenu state.

 

From there, I started to code what things had to be done so the code above would work the way I wanted. First how to load the image, manage the resource, then display it, sort it in the scene, etc

 

I think this makes it easier for you to figure what do you need exactly and what you want your engine to do.

Edited by Danicco

Share this post


Link to post
Share on other sites

Programming is just like any other skill- in the first few years, you'll be improving at a rapid pace, and routinely wanting to throw out your old stuff because it's so awful compared to what you can do now.

 

If you try to make a reusable engine early on, you'll just scrap it half way through and start over, then get it sort of done, try to make a game, find out the engine is totally inadequate, scrap it and start over, and so on. If you just want to make some tech demo stuff for learning experience, this is fine.

 

If your goal is to finish games, then just code exactly what you need and nothing more. No fancy engine features that "might come in handy someday". Design your game, make a list of necessary features, code them, try to actually make a level and discover all the stuff you didn't think of, code that, repeat until done. Next game, either start fresh and pick and choose any code bits from your old game as needed, or start from your old game and strip out everything you don't need. After a few iterations, you'll start to see what carries over and what doesn't, and how to redesign some of the stuff that doesn't so it does.

 

But even then you don't really need to isolate the engine. Engines are most useful when you have a decent size studio with several teams working on different games at the same time. Or when releasing on the net for other people to make games with it. Not much benefit for lone developers or a single small indie team.

Share this post


Link to post
Share on other sites
"Designing game engines" is for engineers. "Designing games" is for game designers. Game programmers are just a weird bunch who either have already decided they want to do both and call it "programming a game", or they can't decide which of the two things they want to do. :)

Share this post


Link to post
Share on other sites


hats why its probably better to just program a game and put single use code inside, but try to make the parts as decoupled as possible. Then when creating the second game just rip out whats useful from the first game, change it a bit that its useful for both, adapt the first game so it can use it still, and program the remaining bits with single use code. Then when making the third game you rip out the useful single use parts of the second game and continue using the libraries you made before, adapt it so all 3 games run on it and program the remaining bits with single use code. Then you rip out all useful parts again, clean them up a bit and call it your engine. That engine will most likely be more useful and cost less time and you will have 3 games already.

 

Ah I see. That is what I am doing too! I write the engine based on a general idea that all future games will share these basic features.

Share this post


Link to post
Share on other sites

I agree with wintertime, I never developed a game (not even a simple one) but I still wanted to make an engine of my own (mostly for curiosity).

 

There were countless time I was lost like "what should I do next?". Even reading topics and books about it, there were plenty of things that I read and thought "do I really need this? What is this for?"

 

In the end, I decided to change the perspective and decided to code a prototype game instead, and then make the engine. I've read about how to manage states and such, and typed:

void InitialState::Initialize()
{
    //Image* myLogoImage
    myLogoImage = Resources.Load<Image>("LOGO");
    Scene.Add(myLogoImage);       
}
 
void InitialState::Update()
{
    counter++;
    if(counter > Time.Seconds(3))
    {
        Scene.Remove(myLogoImage);
        State.NextState(new MainMenuState());
    }   
}

I wanted a code that would show my logo for 3 seconds, then disappear, and go to the MainMenu state.

 

From there, I started to code what things had to be done so the code above would work the way I wanted. First how to load the image, manage the resource, then display it, sort it in the scene, etc

 

I think this makes it easier for you to figure what do you need exactly and what you want your engine to do.

Well it sounds like you are in the process of making your game which is good. If you ever find yourself lost which seem to be in the game design area, you can look up youtube videos on earlier games and see what basic features they all share: main menu, game controls, etc.

 

Yeah, managing state can be a bit difficult in the beginning. it turns out to be super easy when you design it on paper in a logical and systematic way. code looks super trivial and obvious when you get it to work and understand it.

Share this post


Link to post
Share on other sites


If your goal is to finish games, then just code exactly what you need and nothing more. No fancy engine features that "might come in handy someday". Design your game, make a list of necessary features, code them, try to actually make a level and discover all the stuff you didn't think of, code that, repeat until done. Next game, either start fresh and pick and choose any code bits from your old game as needed, or start from your old game and strip out everything you don't need. After a few iterations, you'll start to see what carries over and what doesn't, and how to redesign some of the stuff that doesn't so it does.

 

yeah that is what I am doing now: picking out code from the past games and use that for the next game to speed development process.

Share this post


Link to post
Share on other sites

"Designing game engines" is for engineers. "Designing games" is for game designers. Game programmers are just a weird bunch who either have already decided they want to do both and call it "programming a game", or they can't decide which of the two things they want to do. smile.png

Well I liked the programming and design side of games. It is pretty impossible to just decide one and expect things done for me as I am doing both type of work in a setting.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!