Obligatory disclaimer - Yes this is for academic purposes, not for making actual games.
I've been employed as a Software Engineer for 2 years but still feel like a beginner when it comes to writing a game engine (and much of coding in general). What little experience I have with writing 3D software from scratch is from super rough university projects (which we called "engine" but that's definitely debatable). Meanwhile, my current job doesn't really take me down this line of learning.
This thread is to ask for advice; mainly pointers to good guides, or comments on what structural approaches are considered to be good ones. I'm looking for something that teaches me about how to structure a game engine so that:
it's good for learning about writing an engine it's not completely devoid of modern techniques it will be usable for later feature learning; networking, AI, unit testing, etc. (I imagine this criterion is typically a given anyway.)
Some things I'm aware of so far (you may want to comment on any of these):
https://www.gamasutra.com/blogs/MichaelKissner/20151027/257369/Writing_a_Game_Engine_from_Scratch__Part_1_Messaging.php I also have the book Kissner recommends: Game Engine Architecture by Jason Gregory. From what little I've read of it, it appears more advice than structural guide. ECS was a buzzword back when I was at uni, but the more I google it the more it appears to have become a dirty word. Unreal Engine's source
Regarding ECS: For all the flak it appears to generate nowadays, it is at least a structure. If ECS isn't recommended I'm interested in what other general structural approaches there are.
Regarding Unreal: I'd love to jump in and learn how Unreal Engine's structure works, but it might be biting off more than I can chew.
Language of choice is C++.
Hi guy , i wanna really quickly introduce myself , So i'm a 18 year old Highschool student that have been for a while really pationate about video game (i have been doing Esport , Streaming all that really fun stuff) but lately i had to made a choice about what i wanna do in life and i'm pretty sure its going to be in the video game industry. Last year i started learning to use UE4 , pretty much only for fun trying to recreate cool stuff i was seing in the game i was playing at that time. But now , i wanted to trie creating something of my own so i wanna show you what a got in the head. Also , I'm french so sorry if my spelling is quite right..
So in Short , i was playing lately alot of FPS (Quake champion , Law Breaker and bunch of other cool game). I was talkinh with my friend and its pretty much their that a got the global idea of what this game is going to be. I wanted to take little simple game mecanics from every game and put them i one unique game. For exemple , Player could Strafe Jump like in quake , while other Start randomly Wall running like in Titanfall 2. After i came up with what would be the game objective , because player won't start playing a game for no reason . I didn't played CTF game for a long time so , i decided why not make this a CTF game , But ctf is kinda mainstream and really linear in term of game play,
This is when my friend had this idea of <<Why not let the player decide if the want to play it ''Run it down to the flag'' or ''let's just #*@! the other team'' (sorry for the bad words) >>. at this time i had a clear idea of what would exactly be the Core ''gameplay'' (if we can call this gameplay). To win you have two option :
1- Capture the flag and bring it back to your's. If you managed to do so , the game instantly stop and you win.
2- Kill all the enemy team.
Now you most be thinking , <<Well how? they will just respawn right?>> well no , because i came up with the idea of limiting the number of time player can respawn using some kind of respawn point system.
i'll came up with more details later (i have to go to my next class) , but let me know what you think about my idea? what should i add or ajust?
Hello! I'm new to the scene of video game developing and was wondering if anyone here has any experience developing 2D fighters and are up for making a little test demo to see if the idea would catch on to the public? I have no way of paying but I want to put the demo onto Kickstarter and I will pay a good amount if I get a good amount. Please, if you want to contact me for more info, add me on my Discord or Twitter. Thank you, and see you later!
Hi, I started implementing 2D board game. I have concept of how to write rules, controlls etc, but i dont want to write another all-in-app. So i decided to do it "right". I divided my code into reuseable modules - ResourceManager, Renderer, Core, Math (for now). All modules use SDL2.
ResourceManager(RM) - loads textures, audio etc without duplicating them in memory. Resources are gathered in TextureResource, AudioResource (...) objects, handled by std::shared_ptr. For textures I have prepared Texture class that wraps SDL_Texture and I RM serves this Texture objs for Core module.
Core - The main game module, contains game loop, gameobject / component implementation and event handling. Core requests for data from RM and sends them to right components.
Renderer - Creates window and knows about render range (in core represented by camera). Takes info about texture, position, rotation and scale to render images (just this for now).
Its time for my questions:
is this architecture good? After I end this board game I want to extend renderer module for example for rendering 3D objects. Loading resources while ingame is good idea? I mean single textures, models, sounds etc. As I said, for handling resources I am using shared_ptr, is it good cleaning cache every (for example) 3 minutes? By cleaning i mean removing not used resources (counter =1). And the hardest thing for me right now - take a look at this flow: Core create a T1 token Component Renderer2D is connected to T1. Core requests a texture /textures/T1.png from RM. RM checks if /textures/T1.png is in map, if not, loads it. RM returns a std::shared_ptr<Texture> to Core. Core assign texture to T1 Renderer2D component.
Now i want to pass this object to renderer. But I wont pass all gameObjects and checks which have renderer2D component (i also cant, because only Core know what is gameObject and component). So i had an idea: I can create Renderable interface (in Renderer module) and inherit from it in the renderer2D component. Renderable will contain only pointers to position data. Now i am able to pass renderer2D component pointer to Renderer and register it.
Is this good way to handle this? Or im overcomplicating things? If point above is right I had last question - registering object in Renderer module. I dont want to iterate over all objects and check if I can render them (if they are in render range). I wanted to place them in "buckets" of - for example - screen size. Now calculating collisions should be faster - i would do this only for objects in adjacent buckets. But for 2D game i have to render objects in correct order using Z index. Objects have to be placed in correct bucket first, then sorted by Z in range of bucket. But now i have problem with unregistering objects from Renderer module.
I think I got lost somewhere in this place... Maybe You can help me? Of course it this is correct way to handle this problem. I would love to read your comments and tips about what can I do better or how can i solve my problems.
If i didnt mention something but You see something in my approach, write boldly, I will gladly read all Your tips :).