I'm not sure how to phrase this and where I should post this, I need some feedback. I get no input being stuck in my head for too long and I don't wish to waste my time on a mere thought. I had an idea and thought that it would make sense expressing it in the form of a game. I am not really a beginner but new to game development..

I do know C++, Python, C# and C but I never made a game before other than the simple tutorial games everyone has to make. I figured my idea was too complex at this point in time and decided to carefully craft out another project that would slowly force me to progress in skill, alongside the development process. I tend to do all my development on Notepad++/gVim and MinGW. Visual studio is great just a little too complicated for me. I'll be taking computer science in Uni so I expect Ill have to get comfortable with it soon.

The current game i have in mind is a 2d top down pixel game. No procedural generation, no complex inventory management, no complex fighting mechanics.

Now I personally don't want to use a game engine for i find it to be unnecessary with regards to the nature of the game and its simplicity, also game engines tend to be rather bloated with featured I do not currently require. I would prefer using the most optimal tool even if it means forgoing speed. Don't get me wrong, I don't have ideological views toward game engines or operating systems etc Its just a tool to me and I would very much prefer using a hammer to knock in the nails, the tool most suited for the job. I don't like waste or excess. As such for a simple 2d game such as mine, I've been looking at frameworks instead of game engines. SDL(Not really a game framework), SFML(which seems a little more up my alley), raylib(I'm a little doubtful about in the long run), Allegro (could not find many tutorials) and monogame/fna(limits me to Windows mainly, which isn't really an issue as of yet).. However I noticed that for most game developers who tend to use these frameworks, the general pattern seems to point towards them building an inhouse engine for their game, then building their game when they think it's ready.

Unity makes it easy, but Its not.. Its just not the right tool and I'll end up being dependent on the engine rather than the code.

I don't know enough to make an engine, and I personally am much more interested in building my game than the engine. I do find engine development interesting, but It would take up a lot of time, and this is where my question lies.. Would it be possible to make a full blown 2d rpg-ish game with a game framework, without building a game engine and just focusing on game code?

.. By that, I'm assuming a game engine is a separate piece of software/framework. I would really like some advice and feedback/thoughts on what I said and my question..

3 hours ago, incogni7o said:

Would it be possible to make a full blown 2d rpg-ish game with a game framework, without building a game engine and just focusing on game code?

Anything is possible, given enough time and money. The real question is (or should be): would this be easier for you than using an engine? I can't answer that; maybe someone else can.

The thing is, if you don't use a game engine, you kind of end up building a game engine anyway.  I'm doing the same thing, however in my case I'd actually love to use a preexisting game engine if I could find one that would do what I needed. I've been kind of forced to write my own since there is nothing really available that I've found that suits my needs.

In any case if you write a game from scratch, say using DX11 of OpenGL, IMO you will end up (or should if you are doing things right) with something approaching a game engine of shorts.  It may be highly limited in scope, but you should have some sort of framework just to keep your sanity.

For a 2D top-down pixel game, all you need is sprites. Using a game engine may actually be overkill. All you need is to draw textured quads, and you can learn that in a day. I'd stick to C++ in your situation.

9 hours ago, VoxycDev said:

all you need is sprites

And a render framework that displays them to the screen and a texture manager that keeps track of the sprites uploaded and an asset manager that locates those on disk and a scene manager that keeps track of the objects placed in the scene its background its foreground and an input manager that carries the buttons to actions into your gamelogic and a math library to draw things at the right position, rotate and scale and I have missed anything else ?

So in the end you need a framework anyways as @Gnollrunner already mentioned or it will appear in your development process. I do make games for a long time now and have worked with frameworks/libraries only but also full-featured engines and the one point I got from all that is that you need anything and anything dosent fit well into what your personal requirements are to the feature set. I often thought "I would have implemented that feature in another way" or "I could do that better" and this will never end; is a sign of deep knowledge just away from the "normal user" and it is ok.

If you have to do something quickly, you learn to get arround limitations or end up having a library full of utility code for the engine you develop your game on top or you go and write your own one; its all up to you. I do both of these, at my all-day-job work with the environment my employer orders me to work with and in my spare time write my own stuff since 6 years now; fully from scratch.

Maybe as a point to get started, you can use the legacy OpenGL tutorials up to Lesson 10 so you have anything learned from simple graphics to input handling and texture loading to build your 2D game from scratch. Unfortunately, the example code seems to have been moved or removed meanwhile.

YOu could either start using C++ managing the platform stuff by your own or even use (plain) C# and OpenTK as OpenGL wrapper similar to GLFW for C++ if you want to platform independent.

For a simple game this will work but beleave me, at some point you'll start writing your framework

15 hours ago, incogni7o said:

However I noticed that for most game developers who tend to use these frameworks, the general pattern seems to point towards them building an inhouse engine for their game, then building their game when they think it's ready.

Or it could be that they just call what they built "a game engine"

10 hours ago, Gnollrunner said:

The thing is, if you don't use a game engine, you kind of end up building a game engine anyway.

I strongly disagree with this. Given the kind of game engines we have today, I think that "code that runs your game loop" should not be called "a game engine". And yet, for anyone making a game without using an existing game engine the favorite thing to say is "hey, so I'm making my own little game engine..." when in fact what they are making is "a game". Game engines today come with asset pipelines and visual editors and middleware support and a whole other bunch of stuff that I can't remember  Putting them in the same basket with single-game specific boilerplate code feels wrong.

I believe there should be a distinction between the two, so that we can properly use the age-old "write games, not engines" advice. For an experienced programmer who wants to make a game, there is nothing wrong with doing that by mashing together libraries and frameworks, and writing code that will be suitable to run their (one) game. The "don't" part comes when they try to make a generic all-purpose game engine without ever making a game using it (or worse, instead of ever making a game with it), all that without having any requirements or real-world experience in mind. 

So yeah, if you are a programmer and want to make a game without using a game engine, go ahead and do so. Just don't call it a game engine, ever  That will just attract unwanted attention. 

For a better than mine look at the same subject, read Write games, not engines. It is/was the most commonly quoted advice for beginners. But because it was referred to so many times, people stopped reading the article and just try to deduce the meaning from the title alone. Make sure to read the whole thing, not just the title

14 minutes ago, 1024 said:

 

I strongly disagree with this. Given the kind of game engines we have today, I think that "code that runs your game loop" should not be called "a game engine".

Well that's one definition, but then as Wikipedia says "A game engine is a software-development environment designed for people to build video games".  If you ask me that can be a lot of different things.  I personally would not limit it to some specific model. But I don't want to get into some big discussion on the exact meaning of a couple of words. 

I've had people telling me I'm not using voxels because mine are prisms not cubes and I'm using an octree not a matrix.  On the other hand I'm using something almost identical to marching cubes and plan to add extended marching cubes (or extended marching prisms rather) functionality.   These are classic voxel routines.  But if someone want's to insist I'm not using voxels, I don't really care.  It runs just the same.

So in short... Call it what you want. Game engine, framework. API, what have you. For me, if someone calls their set of libraries a game engine, I don't have a problem with it. Your mileage may vary.

54 minutes ago, 1024 said:

I strongly disagree with this. Given the kind of game engines we have today, I think that "code that runs your game loop" should not be called "a game engine". And yet, for anyone making a game without using an existing game engine the favorite thing to say is "hey, so I'm making my own little game engine..." when in fact what they are making is "a game". Game engines today come with asset pipelines and visual editors and middleware support and a whole other bunch of stuff that I can't remember  Putting them in the same basket with single-game specific boilerplate code feels wrong.

 

I disagree with this. ?

A game engine is in my point of view a separate piece of software / API that provides all the necessary submodules that are necessary to run an arbitrary game. This includes rendering, networking, input, memory management, CPU load management, asset management, etc. Assets and your game logic are not part of the engine. That is what makes your game. Content creation tools and editors are written FOR an engine and are not strictly part of the engine. You don't need them to run the engine. I would call the thing you are talking about more like a game development kit, but that is just an opinion. However, I think you are right that people who write their games without an existing engine can't claim that they have written their own engine most of the times. The separation of engine specific tasks and game logic is often not given so that you can't use the "engine part" for other games. But again... opinion. ?

16 hours ago, incogni7o said:

Would it be possible to make a full blown 2d rpg-ish game with a game framework, without building a game engine and just focusing on game code?

If you don't use an engine, you will sooner or later have to write "engine specific" code. But I think it won't get too much in a 2d game. A lot of stuff like collision detection, physics and graphics are (extremely) simple in 2d.

I never used SFML, I just read about it a long time ago, but I think that might be the thing that suits your needs most. If you use OpenGL, as some people suggested, you will have to do a lot of stuff that has nothing to do with your game ---> create and compile shader programs, load your images, cull objects before drawing them, etc. In a 2d game, this is not really complicated, but it takes time to do it right if you have never done it before.

Greetings

How about calling the home brew to support the flow of a game a "framework" instead of "engine" ? With "framework" being api specific, game specific, maybe some platform independence built in, resource management, that stuff, while an (lowers voice in awe) "engine" (back to normal) contains much more middleware than that, more editors, more abstraction layers, more independence, more bugs ? ?

That's a rectification for writing an own framework and leave the tedium of an "engine" ...

Ok, that wasn't 100% serious. But hey, if it is a simple thing, why not write an own "framework" ?

We could compromise and call it a frame-gine ?