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?

The problem is if you start programming an engine without having a immediate use, you wont know what you actually need later and you wont know if the things you create are actually in a useful form.

Thats 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.

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.

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.

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.

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.

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.

"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.

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.