Help, a question regarding Game Development..

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 ?

What's wrong with just calling it "a game"? Does it sound too simple if it doesn't have a tech-sounding name? Are developers afraid that they won't be taken seriously unless they are making "something bigger than that"?

These things are supposed to be reusable, right? I propose a limitation: you can't call your game code "an engine" until you use it to make more than one game. Until then, it is "just" a game. And there is nothing wrong in just making a game.

Let's say we have multiple game engines, and they are all open-source. If we have a common way to be able to plug features in and out and transfer them between engines, this provides for the most flexible environment. If somebody only needs 2D sprites, input and basic collision detection, like OP, let's collect all necessary code into 3 files:

• Sprites.cpp
• Input.cpp
• Physics.cpp

If somebody wants more, let them dive into and build from a codebase as complex as needed. I look forward to a day when it won't be a matter of choosing U-something versus framework versus bare C++, but only a matter of getting the right .cpp files into a directory (hopefully all licensed MIT or similar) and hitting play, as far as technical features go.

The game is scripts, models, textures and audio. Individual title publishers should retain all the copyright to that. At the end of the day, it's not a matter of what the engine is, but whether the game is out, what it looks and sounds like, how many players it has and what the rating is.

An interesting discussion, giving my two cents to that topic; I think a game engine is more than the game that is set on top of it. The game engine is at least at some point a genarlized framework that offers a feature set you make your game with. This feature set should include

• Basic platform handling and API abstraction (in C like languages)
• Provide some kind of memory management (in C like languages)
• Have a math library
• Have an input library
• Provide some kind of render engine

because such features is what you need in every game regardless if it is 2D/3D or a text adventure (yes folks, text is also rendered!). I don't think a game engine needs a lot of asset pipelines, a complex editor or online.store capabilities as a must have to call them game engine.You could even have your game engine read a lua file and create the level from it without a visual editing feature, have a Blender plugin that converts assets into a format that could be directly loaded into the game etc.

Unity, Unreal and Game Maker are designed as a whole in one solution what is absolutely ok but dosen't make them more a game engine as for example Urho 3D is a game engine. Today we are familiar with tools like a full blown level editor or even Intellisence when we code but I think convinience is ok for some point but convinience also makes us lazy.

In my case, I designed my code to be modular, small and flexible, write my own tools and try to do as much on my own as possible. First this was the reason when I started learning all these stuff but today I came to the conclusion that doing stuff on my own has brought me to where I'm and I would rather use my own Array implementation than using the STL one, even if it takes longer to come to see results, even if my results don't 'look' that fancy as those from a million $ busines company.

But back to topic, I also disagree with the statement of @1024 per se but just for the fact of the feature set that a game engine must have. For me a framework begins at the point of general code reuse, a game engine begins at the point when a framework reached certain feature set that is but not most entirely related to games (as described above) and anything beyond is a game creation suite.

This said, lets be nice to each other ?

Since many of us are working on our own C++ engines, let's come up with a standardized way to move features around. Goals would be:

• Everyone benefits from everyone else's work
• No one has to reinvent the bicycle, unless they want to
• The best implementations of everything are used
• All code is compatible, but can be easily decoupled (example: Water.cpp makes water, and can be used on its own in a simple Hello world game project, as well as inside any of our engines).
• Everything is so modular that there is no more distinction between engines or frameworks, but there are "features" that can be plugged in or out

This way, in a few years, we won't even need the U-engines. We'll have complete control and transparency over all the code. Cat's out of the bag. You can't make money with engine development anymore. So let's not try to. Make money with the games instead.

4 hours ago, VoxycDev said:

let's come up with a standardized way to move features around

That sounds suspiciously similar to this recent discussion. Interesting idea.

Welcome @incogni7o. From your list of libraries, I happen to like monogame. The content pipeline actually makes me happy. Most of the grunt work is done for you and the same executable can run on multiple platforms. (i.e. mono onMac but built from windows) SFML would be my second choice.

"Unity makes it easy, but it isn't" <-- that's golden. But it does. See you around.

In my mind, code in an engine can be separated into two categories:

1. Custom code closely related to the game: the editor, level loading, saving, scene graph. People will keep re-writing these parts to make them fit their particular project, maybe forever. And let them do it.

2. General code that could easily be the same in every game: rendering, skeletal animation, lighting, physics, input, audio, model/texture loading.

So what I propose is this: make things modular in such a way that everyone can have their own custom code (1), but have an easily plug-able code base of general code (2) to pick and choose from. What do y'all think?

If all of our engines were put into a single repo, the merging process would look something like this: all code is custom code (1) at first, then we identify pieces that are compatible or interchangeable and slowly migrate them into general code (2). I'm willing to start the sorting process, I just need everyone's Github repos.

@VoxycDev and everyone else reading this; as this is already going a little offtopic, I try to keep this short: A universal engine might be a good point, it won't ever be standardized unless everybody is willing to follow certain standard. Take a look at the C++ "standard", in real there is no standard! Anything that the standard says is how is code compiled and what is inside the STL, it doesn't point to coding style (that is horrible and royally 90's in my opinion) and even dosen't offer platform independent OS features like .NET does for example. Code is written re-written every day (as I mentioned in this topic, humans (including me) tend to think they can make stuff better) so there will always be someone getting to that standard engine and try to customize it to his/her current needs or start writing an own one.

Don't get me wrong, I really like the idea of an open, clean and modular game engine and this is the reason because I started to make my own one (and already partially published some parts of it on GitHub). What I did was thinking in packages, for code, for tools, for everything and getting to a highly modular code base (after 6 iterations), so it might already count as flexible/ reusable as you described above but with the exception that Water.cpp is a Water Package/ Module. The problem is that it isn't reusable as long as the API it is build on top isn't standardized in naming and functionality; you'll otherwise end up using #ifdef's not just for platforms but also for different APIs. I got to at least 6 but 8 basic packages that are necessary to build a game/ an engine from

• Common; C++ platform abstraction and common used classes like Memory, basic Types, Delegate, Stream and some more
• Math; general math abstraction like Random but also 3D math, hashing and crypto math
• Storage; general file I/O and file system operations
• Threading; since 2005 we have access to multiple cores so why not use them, synchronization structs, threads and a task/job system
• Input; for not being pinned to OS messages, this abstracts the HID drivers on PC and Mobile/ standard input features on Console platforms
• Graphics; might be something GL, Vulkan or DirectX but I prefer GL/Vulkan, covers API functions and utilities like Window/ Surface creation/ management
• Text; working with strings and text assets should be optional so this goes here
• Network; not every game is a network game but this covers TCP/UDP capabilities and IOCP for PC and Mobile platforms

The package solution also requires some kind of custom building/ package management tool to setup a project correctly so this has to be standarddized too.

TL;DR it is very difficult to establish such a standard because everyone expects something different from those standards and depending on experience, has a different priority and implementation culture for it.

Feel free to send a PM or Discord message if anyone wants to talk further at this topic

This is the reason why I went beyond the concept of trying to make reusable modules for compiling into projects. These end up being rewritten for individual projects. Then they start breaking other projects and become incompatible. Then you have again tons of different "version" of the same game engine and you end up with no gain at all.

What I did is examine various game components and identifying what "building units" they actually use. These units are large enough to be optimized by modules and small enough to build game concepts. As I see it most game concepts can be broken down into these units. What I have then are independent larger modules (like graphics, physics, input to name a few) which anybody outside the game engine can create himself.

These larger modules are compatible and interchangeable even at runtime. You can pause the game engine, switch to a different graphic module for example, and continue where you left off. I am convinced this is the kind of future proof game engine concept many are looking for. It goes beyond your concept though.

I have old code you can use if it something that simple. It sorta like a demo. Anyways it could be what you need for your game. Don't expect anything glowing. It just organized and built enough to get the job done. I recommend you use an engine or something popular right after you put together you extremely small game.