/agdg/ - Amateur Game Development General

I'll start.

I've been working on my engine for about a year or so I think. I've had to take several breaks due to life etc. But it's getting there.

I'm relying on SDL2 for window and context creation. Freetype to handle font files. The only other external code I'm relying on is a tiny png loading library named LodePNG (but I'm looking to remove it to be replaced by a custom image format). Oh and GLEW to load up OpenGL

Graphics is currently handled in OpenGL4 but I'm looking to make this configurable due to how many people ive found who can only handle OpenGL3. I might move to Vulcan, but I'm not sure yet.

I'm looking to create a space strategy game so my engine reflects that. Input is handled only through SDL, no DirectInput or anything. I also want to make sure 100% of the code base is cross platform and cross compiler, so no DirectInput. I haven't begun to work on sound yet.

As for architecture I've designed it so that the engine provides three things. The "engine", a "game" class and an inputhandler. You create your own game class that inherits from the one provided. There, you need to provide your draw routines and a game logic loop. You then create an instance of "engine" and hook your game object into it.

The engine internally spawns some threads, one for inputhandling, one for game loop and the main thread for rendering.

Because it's designed for space I'm also creating a "universe factory" to create planets + suns etc. This is independent of the engine. Work on the factory is very interesting. The movement of celestial bodies etc is handled here.

I've also developed a data format and parser for it all. It's basically json but with a tiny change to syntax and some new types.

I've done a lot of work in my noise library to produce random textures etc for planets and suns etc.

Finally, im currently working on a very extensive ui library. This is coupled to the engine. It's needed because strategy games, or at least what im working on, is a lot of ui, so I want it to be top notch.

I'm doing one right now in Qt (w/ OpenGL & C++)). I used to use XNA/Monogame/C#, but XNA itself really frustrated me. I've had to build a lot of things myself (e.g. Sprites), but I think it's been a lot of fun and interesting. I like C# as a lnaguage more than C++ at times, but Monogame is so god awful. Qt also has a lot of nice extra things.

>>22876

I sort of thought that Qt was too much for what I needed. But then I started on tool development and wished I had something. So I started into wxWidgets, it's pretty good, especially with the Code::Blocks plugin.

>>22872

You might want to consider switching from GLEW to glloadgen, if you can:

https://bitbucket.org/alfonse/glloadgen/wiki/Home

glloadgen is cleaner, lighter, and faster than GLEW, but more importantly, you can use it to target just specifically the version spec of OpenGL you want (so you can use it targeting version 3.3, for example, and not generate any bindings to any deprecated functions or defines), whereas GLEW greedily tries to grab every single function and define it possibly can find.

And it's "Vulkan". It's not the Star Trek race, it's the German word for Volcano.

Also, if you aren't using much of SDL and want something lighter, GLFW is fantastic. It focuses on cross-platform window and context creation and input handling, and gives you an OpenGL context without any extra fuss. SDL is great, but it's very heavy if you're just using it for windowing and input. GLFW doesn't have sound handling, though, so that may be a deal-breaker.

You're not making a Planetary Annihilation clone, are you? If you are, don't make the mistake the PA guys did (ie. don't make it shittier than an RTS released in 1997).

Sounds pretty cool. Have you posted any samples in the progress thread?

>>22886

Man, I've been looking for an alternative to GLEW because it doesn't even bind some things properly if you've got the wrong version. I'll look into glloadgen.

I initially chose SDL2 because I wasn't sure what features I'd actually need. Also, it's what Valve uses, which seemed to me like a done deal.

But now looking back, the SDL2 .dll is 4x the size of any other .dll. It's like 9x larger than my game .exe. I might look into GLFW and using OpenAL when I need to.

It might be a bit of a trek though, SDL_event for input is intertwined in a fair bit of code, especially the inputhandler.

The game I was thinking of making was a Grand Strategy game set in space. This was a little over a year ago. And now Paradox has announced their own Grand Strategy in space, so I sort of think I need to rethink what I'm doing.

Which shouldn't be hard. I'm not really at the "game" stage yet.

I didn't realise there was a progress thread, I might jump in there now.

>>22887

As far as glloadgen goes, here's a bit of the developer talking about advantages and motivation for the project: https://stackoverflow.com/questions/15739005/performance-advantages-using-opengl-loader-generator-over-glew

You also don't keep or link glloadgen in your project anywhere. You use it to generate a loader which then becomes part of your project's source tree. (just a single header and source file).

OpenAL is alright, but remember that the official library has been proprietary for the past decade (the name doesn't mean it's open, but that the API is similar to OpenGL. There are a few FOSS implementations like OpenAL Soft). I use PortAudio for cross-platform sound playback. You also might just be better off sticking with SDL and using its audio facilities, if the bloat isn't incredibly offensive.

>>22871

What's an "engine" for something in programming?

I mean, let's say I make a game in java from scratch (I have the init(), the run() and paint() and all that) is that then an "engine" and a game?

>>22892

It's largely up to interpretation, but it's usually everything short of data.

So, for a platformer, you'd have save game management, physics, script execution, audio handling, menu managament, game loop, etc. That would be the engine.

Scripts, user models, maps, assets, audio, menu data, etc would be game data.

The line between what is engine and what is data is very often blurred (if you have a hardcoded menu, is the menu text data or engine? What about localization and translations), and occasionally all the data is hardcoded into the engine, occasionally you have an engine that loads and runs an interpreter that completes the engine and then uses data, in which case you have a grey area. If you have scripts, to what degree are they engine and data? If your data is separate, but your engine is hardcoded to expect only specific data that you feed it (ie, a model that has a specific number of vertices, specific texture sizes, etc), is that data part of the engine?

This is where you have things like Corona, GameMaker, Unity, Unreal, Blender Game Engine, and Godot as standalone game engines (when you make your own, it's usually much more specialized), though those ones are in a gray area, being SDKs as well, and given that with most of them, you implement the rest of your game engine in them.

Essentially, the game engine is the core of the game that handles and works with data that you feed it in order to act as the game. It's a convenience more than anything else, and usually the more you segregate engine from data, the better of a time you will have down the line, and the easier it will be to prevent and squash bugs.

Rule of thumb with compiled languages is that if you have to recompile to change it, it's part of the engine. If you can change it without recompiling, it's part of the data.

You generally don't do your own engine because you love games and you want to get your game made (unless you are already very experienced and skilled), you do your own engine because you love the programming and problem solving involved for its own sake, or as an educational endeavor (or you have a development team and you're the engine guy). If you have a vision and just want to pump a game out as a one-man team, you're almost always better off using a game engine instead of making your own.

>>22894

>You generally don't do your own engine because you love games and you want to get your game made (unless you are already very experienced and skilled), you do your own engine because you love the programming and problem solving involved for its own sake, or as an educational endeavor (or you have a development team and you're the engine guy).

This pretty much sums up enginedevving. It's fun if you're a programmer. Discovering how to write a model loader or implementing occlusion culling or even draw batching are all pretty challenging stuff and there are so many ways to tackle those problems.

Myself I'm working on a multi-platform API-independent engine. Been working on it since March this year, but I took a break for 4 months in April because I had to do a major rewrite and I was lazy as fuck. It'll be a general all-purpose engine but I'm going to be using it to make an adventure game later on, so I'm eventually adding things like seamless asset loading, terrain LOD and that sort of stuff, but I'm working more on the general aspect of it first.

Since it's multiplatform and API-independent, anything that relies on hardware specifics is abstracted away using a plugin system. Basically I have functions like GPUAssembleRenderingInfo or OSLoadFile which are set up as function pointers to nullptr. There's an external header that gets included into whatever game I'm making and loads up the appropriate DLLs/.so/.prx libraries depending on the target platform and APIs. So there's also plugin files that get compiled to shared libraries and export these functions, this way I can easily add on new platform plugins and API plugins when needed. (the main engine sort of works as a plugin system too but it just uses namespace versioning, so I can pull in different versions of different parts and it's setup so that each part is completely independent of the others)

There's multi-threading support using a thread pool/task manager implementation I wrote up. It runs pretty fast and scales well so I'm proud of it. There's IO support for loading files and stuff/reading input, there's audio manipulation stuff, HUDs, physics, pretty much the norm.

For modeling, I just export from blender or Maya as usual but since Models in the engine aren't represented exactly as they are in the .obj/.fbx or whatever, I had to make a model loader. Mine was shit so I ended up writing a program that uses Assimp to load it, then I take that info and compress it and put in a format where I can just memcpy it into the game memory instead of all the Assimp overhead.

Shaders of course need to be abstract too but instead of going overkill I just have a simple parser that loads in a single format of file, and this file contains info about all the different versions of that shader (GLSL or HLSL, which API it uses etc), so I just load this file and extract the appropriate shader depending on which API I'm using.

As for the engine, any game I write up just gets compiled using clang. Clang allows you to modify the precompiler but it was alot easier to just write up a regex replacer on my own since I didn't want to do anything fancy. You just include the engine header, override a GameState object's start() and stop() functions, and the library gets built into the game and out comes a DLL or an executable if it's a release build

For scripting, there's a good blog run by Molecular Musings, can't remember the guy's name but he has a pretty nice engine, and he had a technique that allowed him to use regular old C++ for scripting rather than using Lua and adding bindings and managing libraries and shit. Basically, you make a dll like usual with a Script class that overrides some virtual methods (or in my case, using an unordered map to store function names and pointers to them), use placement new to create the script object, and by being careful and not using functionality that your engine library doesn't have (like pulling in standard library functions you never use in your engine), you end up with Scripts that are a fraction of the size of the .cpp file that made them and compile super fast. I use that scripting setup and it works wonders.

Right now, all I'm working on is fancying up all the HUD code, getting a good particle system setup, and improving the rendering pipeline a bit. I honestly thought it would be alot more daunting originally because I never made an engine like this before but it's easier than I thought.

I dunno, I wanted to make a 2D fighting game and mugen is trash, same as 2D fighter maker.

So my only solution was to code my own fighter in libgdx.

Am I an enginedev?

>>22912

I think you are only an enginedev if you disconnect the engine from your fighter.

But in general I'd say you are an engine dev.

As an engine dev looking to add a networking module to my engine.

Fuck asio as a cross-platform C++ networking lib. http://stackoverflow.com/questions/32970935/segfault-with-asio-standalone-when-classes-in-separate-files explains it well. Just fuck it.

I think I'm going as nodev suggested and ditch SDL2 in favour of GLFW + SFML Audio and Network.

SDL = internet explorer

GLFW = webkit

SFML = firefox

Port Audio = wrench

OpenAL = bolt gun

ogg and wav for sounds, always pre-load effects

png and dxt for images

OpenGL ES 2.0 for simple graphics or OpenGL 3.2 for fancy. Do not use 1 or 4.

>>22966

I'm struggling to figure out whether webkit is better than firefox. Or do I want a wrench or a bolt gun?

>>22966

What a mysterious post

Obviosly SDL is popular and feature lacking for casuals

GLFW totally lost me

SFML is for people who love extensibility and memory leaks?

The last 2 are tools so the bolt gun is more advanced and thus overkill for simple projects?

>>22969

>>22974

I get what he's saying.

SDL in its current inception is slower and heavier than the rest, and it's fucking huge. It's also the most popular, especially for starters.

Webkit isn't a browser, just a simple layout and rendering engine. It needs a lot of other parts to be functional. In the same way, GLFW includes no bells and whistles, just giving you cross-platform context creation, and input and window management.

SFML is faster than SDL, offering much of the same capability, but much more flexibility. (I haven't had a memory leak in Firefox in years. Extensions can have leaks, though, and that might be what you're seeing).

I don't know enough about PortAudio and OpenAL to directly compare them, but I do know that the official OpenAL implementation is proprietary (there are open implementations, though).

>>23018

About OpenAL etc.

The open implementations of OpenAL like OpenALSoft use DirectSound or PortAudio internally.

It's really hard to decide how to do cross platform sound.

>>23018

>SDL in its current inception is slower and heavier than the rest, and it's fucking huge.

I've never used SFML, would be nice to read a source on that. I've been sticking to SDL because it seemed to be more stable/reliable due to it's age and widespread.

>>23031

I've used SFML previously. Release 2.0. It was pretty rock solid, the only problem I ever had with it was around text rendering. They were reading glyphs slightly incorrectly, but I found the problem in the source and fixed it for them.

But all in all, it was rock solid, easy to use, well documented. Building it from source was a walk in the park, it came with all the external libraries pre-compiled.

>>22879

>>22876

How is Qt? I've seen it used in SFM and it looks pretty slick, but how is it to work with?

>>23031

 % ls -lh /usr/lib/libSDL2.a 
-rw-r--r-- 1 root root 1.7M Aug 11 11:59 /usr/lib/libSDL2.a

 % ls -lh /usr/lib/libsfml-*.a
-rw-r--r-- 1 root root 196K Aug 11 12:01 /usr/lib/libsfml-audio-s.a
-rw-r--r-- 1 root root 699K Aug 11 12:01 /usr/lib/libsfml-graphics-s.a
-rw-r--r-- 1 root root 176K Aug 11 12:01 /usr/lib/libsfml-network-s.a
-rw-r--r-- 1 root root  48K Aug 11 12:01 /usr/lib/libsfml-system-s.a
-rw-r--r-- 1 root root 119K Aug 11 12:01 /usr/lib/libsfml-window-s.a

(about 1.2 M altogether)

SDL is monolithic and inseperable, whereas with sfml, you only have to use what you need. SDL is also slower, rendering without hardware acceleration by default, where SFML always is hardware accelerated when possible.

You're right about reliability, though. SDL is way stable and reliable.

Why not write plugins for existing engines to use for your specific game(s)? Talking about dialogue system if needed, or something else you feel is missing? Who here uses an engine but writes/extends it with his own or other's plugins?

>>23248

I wouldn't call that engine dev. Engine dev would be building the ability to have custom coded plugins in the architecture.

>>23208

Qt is some ways is a bit more bare fucking bones than something like XNA, but it has a lot of advantages.

1. C++, that's some raw speed right there, only things that suck about this language are the compile times (but that's minor). Pointers may seem nasty but their nice (and Qt has some stuff to make managing them easier).

2. Cross platform Widgets/GUI. It's really nice, they have a lot of widgets for you already available. They can either be native or you can change how they are drawn (to your liking)

3. Other things like Threading, Timers, Networking, Geometry, are built in (and cross platform).

4. If you want 2D and 2D only, look no further than the GraphicsView Framework. It may seem very abstract at first but it's really nice.

5. If you want 3D, get ready for some (near) low level OpenGL shit.

I think it's a really good option for video games engines that gets looked over a lot. They even have cross compilation support for mobile devices too!

I suggest it highly if all you know is C++.

>>23255

I've been working with GLFW and I was planning on writing my own UI from the ground up, but that definitely looks like a decent option. I'll look into it.

>>23301

Best thing I can recommend is to go through all of the OpenGL examples on the official website. Use Qt 5.x. Avoid any tutorials that use the old fixed function pipeline. QOpenGLFunctions contains all of the functions that are part of the OpenGL ES 2.0 standard; I recommend using that for all of you GL functions call.

I've been dabbling.

c++ & modern opengl

entity / component model

fun times fixing random shit in graphics related parts of the code

not too sure what to do for gui elements, maybe chromium embedded framework.

I'm working on an engine using the windows API. I'm trying to figure out how to distinguish inputs from two different keyboards

>>23368

I looked into embedding chromium and instead went with doing the gui myself.

The reason is because I'm an idiot. It's a lot of work to code a fully functioning UI system with some type of data driven design and layout.

>>23371

http://gamedev.stackexchange.com/questions/56361/how-do-i-read-input-from-multiple-keyboards-mice-on-one-computer

>>22939

>>22912

There's no reason to require a layered separation between game and engine, at least for definition. Especially given that there's no programming need for that. It's just generally easier to do so, and you'd primarily stray away for the sake of optimizing out the glue (optimizing for either man or machine, time/effort).

anyways, the entire enginedev concept is a stupid distinction to have in the first place, if it's solely about "where" the programming lies on the architectural scale. It implies that there's a fundamental role difference between two different parties, when really the engine and it's output is intermixed, and can even act in feedback loops.

It'd be much more useful to have a distinction similar to frontend/backend as in webdev, where front is the WHAT happens, and the back is the HOW it manages to do those things. "design" versus "architecture" of the total system.

Only in special situations (typically large businesses) do you have the kind of head count that necessitates a division of labor such that you have a group whose specific domain is the "engine" and another whose specific domain is the "game"..

Enginefag here. I write engines but not games.

I really need to write up an overview on engine stuff sometime for people.

Currently using:

DirectX for graphics (I have a graphicsfag working with me, doing pbr)

C++ core for Component-based and systems

SWIG/Some meta-shit for C# scripting

WPF for editor

As for architecture, if you want to follow the general high-level approach that commercial engines use: you divide your engine into these levels (from high abstraction to low):

GAME LOGIC BITS

1. Runtime Scripting - game logic that loads game data

2. Scripting interface - this is the binds that hold the runtime scripting to your actual engine

ENGINE BITS

3. Components (data only, no logic. Merely data bundles to be passed to systems (e.g. RenderComponent goes to GraphicsSystem, PhysicsComponents to Physics, etc. )

4. Systems (Your actual game update loop e.g. Renderer, Physics, Game State Manager, Audio, Input, Scripting Updates, and FramerateController)

5. Main loop update all systems

6. Fancy optional stuff for underlying core (Meta reflection, job system, etc.)

Each level should only interact with things directly above or below it (except for #6, that can be used anywhere in engine bits)

Notice there's no mention of an Entity or GameObject. In a proper full engine design this concept is indistinguishable from a mere list of components. While it exists, it becomes functionally a part of the Game State Manager and not of the engine as a whole. Component distribution to systems during update can be done almost entirely without touching w/e component container objects.

>>22940

i'm thinking about using ASIO for a simple http server. I hope I haven't fucked up.

>>23429

Oh yeah, as a follow up. If anyone is interested in runtime scripting but doesn't want to dive into the shithole that is binding C# but is too hipster to bind LUA, I highly recommend checking out AngelScript. It's easy as fuck to bind and looks like C++ syntactically.

>>23472

>its way better and simpler than any other game engine ive encountered. It canbe infinitely scaled and its completely modular. The only problem is I have no clue how to sell it

What's the percentage of your code coverage? Do you somehow cover rendering code?

>>23472

>its way better and simpler than any other game engine ive encountered. It canbe infinitely scaled and its completely modular. The only problem is I have no clue how to sell it

What's the percentage of your code coverage? Do you somehow cover rendering code?

>>23473

This. There's no way you made a modular game engine in 500 lines unless you're building on top of existing libs.

>>23540

heh oops looking at the screenshot made me aware of the memory leaks of the game and core classes (although technically the OS would free them anyway).

>>23540

Mine is a little but more verbose (I'm OP).

int main(int argc, char* argv[])
{
#ifdef NDEBUG
    std::ofstream errorLog("SpaceEngineErrorLog.txt");
    std::cout.rdbuf(errorLog.rdbuf());
#endif
    try
    {
        spaceengine::SpaceEngine spaceEngine(glm::ivec2(SCREENWIDTH,SCREENHEIGHT));
        SpecificGame game(&spaceEngine);
        spaceEngine.HookGame(&game);
        spaceEngine.Start(new spaceengine::PostProcessingEffectChain(glm::vec2(SCREENWIDTH,SCREENHEIGHT),"../../Assets/postprocesschain.json"));
    }
    catch(const std::exception& e)
    {
        std::cout << "ERROR:\t" << e.what() << std::endl;
    }
    catch(...)
    {
        std::cout << "ERROR, nothing" << std::endl;
    }
#ifdef NDEBUG
    errorLog.close();
#endif
    exit(EXIT_SUCCESS);
}

>>23593

>spaceengine::SpaceEngine spaceEngine

Just fuck my shit up.

>>23644

Shit, I didn't even see that I did this.

This is only semi-on topic, but: someone made an engine with haskell:

http://helm-engine.org/

Thoughts on functional engines?

>>23684

ehh it doesn't surprise me someone actually did this, probably as a proof of concept thing, but I bet it's useless as actual game-engine and only functional programming language purists would (want to) use it.

It just seems extremely inconvenient for games..

>not developing with vulken

>>23932

How could you?

I wonder if posting my progress would speed up my progress

I don't have much yet though, latest progress is a logging system

INFO : Log file opened - Sun Nov 22 23:10:34 2015
INFO : Core: Creating window..
INFO : Core: Creating renderer..
INFO : SpriteRenderer: Loading shaders..
INFO : Core: Creating server..
INFO : Core: Creating client..
DEBUG : Window: GLFW says the window is closing..
DEBUG : Core: Game loop ended..
INFO : Core: Shutting down..
INFO : Core: Terminating game..
INFO : Core: Terminating renderer..
INFO : Core: Terminating window..
INFO : Window: Terminating GLFW..
INFO : Application has ended succesfully, closing logfile..

So I found that I need to allow for GUI scripting now that my GUI widgets drawing + layout files are complete.

Then I thought, I should probably allow the scripting to do more than just gui.

Then I thought I may as well abstract as much game logic as I can into scripts. So like the engine basically loads everything from scripts with some set functions that will be called.

Then I downloaded a copy of the dragon book.

I've just completed my lexer. Now I need to make a parser etc. Making a scripting language is hard.

>>24042

I accidentially made a crude one when trying to shamelessly rip off the source engine's config system. It was at that point I decided that I'd try to use lua for everything and restrict configuration files from calling functions.

>>24087

I'm attempting to do everything, like everything, on my own, short of my graphics API.

I've now completed a parser that can parse expressions and build a Syntax Tree using a Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm.

https://en.wikipedia.org/wiki/Shunting-yard_algorithm

https://en.wikipedia.org/wiki/Recursive_descent_parser

My scripting language is going to basically be "C with classes and no pointers"

>>24217

> Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm

??? WHY ?!?!?!

>>24293

Because it's super easy to make a recursive descent parser and the shunting algorithm is the only way I know to parse an expression.

>>24217

So your scripting language is going to be angel script?

>>24389

>Because it's super easy to make a recursive descent parser

Which is exactly why you should use it to parse expressions. If you code it right, you can evaluate the expression from the resulting parse tree. Google "recursive descent parser for arithmetic expressions"

See:

http://www.engr.mun.ca/~theo/Misc/exp_parsing.htm#classic

http://blog.roboblob.com/2014/12/16/recursive-descent-parser-for-arithmetic-expressions-with-real-numbers/

>>24217

>I've now completed a parser that can parse expressions and build a Syntax Tree using a Recursive Descent Parser until it finds an expression, at which point it changes into the Shunting-Yard Algorithm.

Mixing multiple parsing algorithms is a recipe for disaster. When shit goes wrong be prepared for many sleepless nights.

off topic sage

>>24429

Oh well, I got it working my way. Which is also the way gcc does it, I think for speed.

>>23371

>distinguish inputs from two different keyboards

Okay you can't just say your game uses two keyboards and not say what it's for

So after a year in Java, then ditching it to rewrite in C++ another 4 months, my engine is finally coming together.

2d voxel game. All entities are voxels. Basically 2d Starmade.

Space partitioning:

unordered_map<uint64, Bucket*>

key = ix+iy<<32

People always say you need rectrees, but I find this works really damn well.

Trees without researcher-tier allocation are cache hostile as fuck.

This only has 2 dereferences/fetch. My impl is like ~30 lines.

Collision:

Continuous so works at ultra high speed, but currently faster speeds need too much bucket gettings

Kinematics:

Fuck torque calculations, All levers are of length 1 lol.

Netcode:

uuuhh.... "80% deterministic"

Basically fuck networking for now, I can't figure out an easy way to test this, and I do very continuous builds

>>27843

> 2d voxel

Those are called pixels.

>>27843

>I can't figure out an easy way to test this

Since you're on based C++ now, then I'd recommend either POCO, Casablance, or ASIO. Since the standards committee will choose a variant of ASIO in C++20, that may be the best choice tbh.

>>24217

so C#?

Why not use mono then?

The thing that's fucking me up hard is cross-cutting concerns. I.E., your program will ALWAYS be a tree if you use OOP, so when you have things on one branch that are needed by another branch you have to connect the two somehow.