Engine Dev or Game Dev...Which one goes first?

[Halsys]

Uh hi, new member here on the forums.
Been using SFML 2.0 for quite a bit sometime here, Working on a bunch of prototypes with it.
I just wanted to say hi, from the United States and wanted be part of a great library and its community.
I might ask a few questions here and there about some things.... I'm still pretty Avid with C++.
Your Forum header for General was "For everything that is not a help request"...
So if this is not supposed to be here... let me know, please?
I might show you guys a couple of my Prototypes I have been working on...
So, Ya... Sorry if this odd for anyone and there standards.
If I didn't say hi, it would have eaten away at me for not.

Oh and a quick question? Is it smart to build a engine or focus immediately on the game? or Both at the same time? Not all questions are stupid... not that its stupid at all... Okay maybe to me its stupid.
When I think of triple A games, I think engines and Vivid graphics. Ie:Source or Unreal or Frostbite
When I think Indie games, I imagine Very rushed primitive mock ups. Ie: The prototype of Worldofgoo or Braid
This is coming from somebody who over plans everything... and maybe over think too.
Which one is best any way aswell?

[eXpl0it3r]

So it's a help thread nevertheless...

There aren't many popular engines that were developed on their own. The way you should go is writing a game and at the end you'll hace some sort of an engine that could be polished a bit further. Never try to create a generic game engine, it just leads nowhere. Take for example, Quake, CryEngine, Cube-Engine...

That indie games often don't have the nicest codebase is more a finacial problem.

[Halsys]

Well that's what I have been doing any way but I keep on wanting to plan ahead.
If it wasn't for classes, I would be tearing my the hair out from my skull.
I have been using my mock up Actor class which will be the base inheritance for future Game items(Players, enemies, Doors, Weapons)... So I only need to issue drawing for one kind of class...
Whats a pain to think about is purely Graphics, I would use Window.Draw(X) but that appears to have fallen off the face of the earth so OpenGL is my only option, No biggie... Because its a 2D game it might actually help.

[eXpl0it3r]

I would use Window.Draw(X) but that appears to have fallen off the face of the earth

What??

Are you maybe looking for window.draw(x)?

[Halsys]

Ya, Doesn't appear to exist with my copy of Code::blocks.
I saw Sprite.draw, But I couldn't figure out how to use that either.
Its been bugging me for weeks. Maybe I just need to rebuild SFML 2.0... and see if that works.

[Laurent]

Auto-completion is a (usually buggy) feature of the IDE, NOT the official doc. Don't rely on it, go read the documentation and tutorials on the website instead.

[Halsys]

See I knew I was crazy... I never had auto correct fail on me till now.
Know any way to fix it?

[Nexus]

Is it smart to build a engine or focus immediately on the game? or Both at the same time?

There is an often-cited article Write Games, Not Engines.

Don't forget that a lot of functionality has already been implemented. For SFML, I once listed some additional libraries that might be interesting. Also take a look at other libraries like Boost, maybe you don't need to reinvent the wheel.

Know any way to fix it?

Use Visual Studio and Visual Assist X

No, maybe Code::Blocks also has a symbol database in a file which can be deleted/reset. But as Laurent said, it is probable that the auto-completion is not very mature and still buggy. You will find more about it on Google.

[MorleyDev]

I believe even I have written an article on this...

The tl;dr version is: The engine is the result of the game. Good code is inherently reusable, so the good parts of games will be reused (one reason I try and use strict TDD is to ensure reusability and modularity). This gets cobbled together into what is called an 'engine'.

The best engines tend to be driven by a game. Even if it's known this "engine" is going to be used in other projects, it's features are derived from the games it's being written for. The engine then evolves and grows from these requirements until it reaches maturity after a few projects.

This keeps developers focused and the features usable, instead of getting distracted by the various shiny things they can try but have no need for and will probably never actually get used enough to justify their existence.

Trying to make an engine before starting a game is very much "putting the cart before the horse", as one commenter on my article points out

[Halsys]

Well both of you strike a good argument(And articles), I never did want to reinvent the wheel.
The fact that I'm here, on a forum of a "Multimedia" library, proves that I speak just that.
Also i'm in the right place... considering what you guys told me.
And I knew making a engine would be a stupid endeavor, You guys proved it and now I know for sure.
If I wanted to make a engine all by my lonesome... there would be no "game".... or engine.
Not that I couldn't do it but because I would get bored... I like games not tech demos.
I was also right that it WAS a stupid question... Ha!

If this is all true(About the game not the engine), What would the workflow be to make it?
And I did see TDD, I like it, and I might try it. but I want this to be answered.
So far my workflow has been very hectic and irrational most of the time.
And what I usually get is either incompatible code from the last thing I implemented.
Or I strike gold and get something I want, Which is 4/5's of the time.

I watched Notch write a game for a Ludum Dare, on I think twitch?
He had this workflow about it where he kept pounding at it and didn't care to much for the structure of it.
So it looked crude and inefficient(Structure not speed), Granted this was Java and he can see his changes as he set them. But it wasn't enough for me to stand up and say "Forget this, its Java now".

Then I watched one of the Amnesia Dev's, No different, He had low level code for the complicated and High level scripts for the simple, and yet again... he got it out fast, even faster than notch did.
So basically I believe at that point, that a good workflow and style is key.

So you can tell, I am not all sorts of confused. I'm actually hoping you guys might have a tip that might help me. Maybe a library that has a usable interface to Python like the amnesia Dev? Or is that something I might need to make?

But so far, I got a lot to chew on now, Thanks!
-

As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent )

[panithadrum]

As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent )

I use QtCreator and I'm pretty happy with it. It's available in Windows, Linux and Mac.

[ichineko]

Well both of you strike a good argument(And articles), I never did want to reinvent the wheel.
The fact that I'm here, on a forum of a "Multimedia" library, proves that I speak just that.
Also i'm in the right place... considering what you guys told me.
And I knew making a engine would be a stupid endeavor, You guys proved it and now I know for sure.
If I wanted to make a engine all by my lonesome... there would be no "game".... or engine.
Not that I couldn't do it but because I would get bored... I like games not tech demos.
I was also right that it WAS a stupid question... Ha!

If this is all true(About the game not the engine), What would the workflow be to make it?
And I did see TDD, I like it, and I might try it. but I want this to be answered.
So far my workflow has been very hectic and irrational most of the time.
And what I usually get is either incompatible code from the last thing I implemented.
Or I strike gold and get something I want, Which is 4/5's of the time.

I watched Notch write a game for a Ludum Dare, on I think twitch?
He had this workflow about it where he kept pounding at it and didn't care to much for the structure of it.
So it looked crude and inefficient(Structure not speed), Granted this was Java and he can see his changes as he set them. But it wasn't enough for me to stand up and say "Forget this, its Java now".

Then I watched one of the Amnesia Dev's, No different, He had low level code for the complicated and High level scripts for the simple, and yet again... he got it out fast, even faster than notch did.
So basically I believe at that point, that a good workflow and style is key.

So you can tell, I am not all sorts of confused. I'm actually hoping you guys might have a tip that might help me. Maybe a library that has a usable interface to Python like the amnesia Dev? Or is that something I might need to make?

But so far, I got a lot to chew on now, Thanks!
-

As for the Auto correction... I would just go get Visual Studio, but I like my IDE to be on Linux too.
OR I might just not worry about it and keep reading the documentation.
(Taking your advice Laurent )

I'm late to this, but just wanted to add my opinion.


shitty working code is better than non-shitty, will work one day code.  GNU Hurd is an unfair example, but still an example.

Throw your code out there and make it work.  Don't worry about style, structure, or anything else.  Once that's done, refactor mercilessly.

The problem with writing an engine before a game is that it requires experience.  You don't know what problems need to be solved, you know what problems you *think* need to be solved.  So you write sloppy code, get it working, then later on, use your practical experience to refactor it.  By then, you have a much better idea of the problems you need to solve, and you may even know a bad way to solve them (Because you did just that).

If Carmack wanted to write an engine before the game, let him.  He knows what the hell he's doing.  You most likely don't, write the game, let the engine be emergent.

[MorleyDev]

Of course the "write shitty working code then refactor" approach has the slight downside that shitty code tends to be difficult to refactor by nature whilst good code is inherently easily refactored and re-used. You can easily code yourself into a spiderweb of a corner if you don't keep that in mind xD

Hence why I do the whole TDD thing, breaks things down into such small parts they tend to be easy to refactor and manage. Also it emphasises refactoring as one of the most important steps when coding, which is nice because...well, it is.

[ichineko]

Of course the "write shitty working code then refactor" approach has the slight downside that shitty code tends to be difficult to refactor by nature whilst good code is inherently easily refactored and re-used. You can easily code yourself into a spiderweb of a corner if you don't keep that in mind xD

That's a statement that you cannot prove or disprove, you can only assume.

Your other assumption is that worrying over the design is somehow going to get you to the spot you want to be when you're inexperienced.

The truth, the thing people don't like to say, is that both approaches are just as likely to 'fail', meaning, you end up with a design that's not good for the task at hand, and it's directly as a result of the experience of the developer (or lack thereof).  That experience factor outweighs any amount of planning you do.

You'll find you save time by not making decisions.  "I don't know what is best here, so I'm going to do the simplest thing that works and see how the usage shakes out" is often times a superior approach, especially when you're developing software you've never developed before.

At least when you're doing that, you're not wasting time building abstractions and architectures that are ultimately harmful (or at the very least go away because they weren't really useful).  In both cases you'll find yourself having to refactor, in one of those cases, you spent a lot more up front work, and throwing TDD into the mix just amplifies it even more.

[Nexus]

That's a statement that you cannot prove or disprove, you can only assume.

That applies to the most other answers here, including yours. Beginning a sentence with "The truth" doesn't change that

Throw your code out there and make it work.  Don't worry about style, structure, or anything else.  Once that's done, refactor mercilessly.

That's too extreme. While you are right that a long and detailed planning phase is pointless when the developer has no experience, he should not spend no thoughts at all, either. Imagination of code structure before writing it is an important part of experience. When you plan already the first time, you have later the possibility to see how much could be realized 1:1 in the code and where assumptions were wrong. This way, you can learn much more than when you have nothing to compare with.