CodeWalrus

Development => PC, Mac & Vintage Computers => Topic started by: Snektron on March 27, 2015, 05:23:17 PM

Title: Game engine structure
Post by: Snektron on March 27, 2015, 05:23:17 PM
I was starting on some simple program today, and when i wanted to draw something, i noticed OpenGL wouldn't really
draw my lines. Since i used Java with still LWJGL 2.9 i decided to update to LWJGL 3, but this newer version completely changes
things like displays and such, so i decided to make a new engine. Normally i just use the simple engine i made some time ago,
which only handles display creation, openGL initialization, and a game loop. And since i want to write a better engine, i'm wondering
how i would create a good engine. I don't want to create an enourmous thing like Unity or Unreal, but just something i can easily make
OpenGL programs with. Though the engine will mostly be used by me, i still want to write it like a proper library.
What things shall i initialize with the game code?
And what is a good general structure?
Things like object loading i can do myself, i'm more interested in a general game (engine) structure. :)
Also if you make games, how do you make your structure?
(as i said i use java, but this is more a general question)

thanks :)
Title: Re: Game engine structure
Post by: Duke "Tape" Eiyeron on March 27, 2015, 08:53:34 PM
I second this question, this can be very helpful to see insights from other people to extend the way we think about making games.
Title: Re: Game engine structure
Post by: Scipi on March 28, 2015, 05:34:22 AM
I've always went with a simple MVC setup for my "engine." Or at least my coding structure. I will generally have an input handler that would compare the states of all keys on a given frame and the previous to determine if the key has been pressed, help, released, or is idle. Then I would pass around a struct containing that info in an array to the code that needs it. I would have the core "game" logic split up into a finite state machine. Each state has an input, tick, and draw method. Then for drawing to the screen I would have objects whose entire purpose was to draw a single aspect of my game. For instance, I would have a mapRenderer that takes a map object and the window. It would create and use tileRenderers to draw the individual tiles and so on. I would also keep all my game resources inside a singleton object in global scope for easy access.

This isn't so much advice for an engine, though. More how to structure your games. You can reuse much of it, though and is easy to make so it has no dependencies.
Title: Re: Game engine structure
Post by: Dream of Omnimaga on March 28, 2015, 06:06:20 AM
I have much to learn about game engine structure and stuff. Although in the past my engines were not hard to port to new games (eg ROL2 uses a lot of code from ROL1 and Illusiat 6 through 12, with the exception of Illusiat 8, use the same map engine overall), a lot of stuff is still too much hard-coded for my tastes. One day I really want to make an RPG engine where all I have to do to create a new game is replace the data.

I do not have any experience with stuff such as 3D rendering engines like Unity and Unreal, though.
Title: Re: Game engine structure
Post by: Duke "Tape" Eiyeron on March 28, 2015, 06:59:20 AM
DJ, that is already what i want to do with HBE : pass a selected part of data and the engine would run totally independently.

Unfortunately, for this kind of engine, when you want to do scripted events, you will probably have to run a scripting language (like FF did).
Title: Re: Game engine structure
Post by: Snektron on March 28, 2015, 12:19:42 PM
@Scipi a general structure is helpful too :)

Quote from: Duke "Tape" Eiyeron on March 28, 2015, 06:59:20 AM
Unfortunately, for this kind of engine, when you want to do scripted events, you will probably have to run a scripting language (like FF did).
Brainc?:trollface:
Title: Re: Game engine structure
Post by: Dream of Omnimaga on March 28, 2015, 09:58:19 PM
Quote from: Duke "Tape" Eiyeron on March 28, 2015, 06:59:20 AM
DJ, that is already what i want to do with HBE : pass a selected part of data and the engine would run totally independently.

Unfortunately, for this kind of engine, when you want to do scripted events, you will probably have to run a scripting language (like FF did).
Do you mean for NPC convos and events where NPCs move in specific directions and where there is automated movement and teleporting to different rooms? I really need to try making this one day, to make it easier to make new RPGs.
Title: Re: Game engine structure
Post by: Duke "Tape" Eiyeron on March 29, 2015, 02:42:34 PM
HBE is still (hypothetical) battle engine. Imean the parts which  make a boss change racto to attacks, change its M.O. when evetns are met or thngs like conversation or things inside  battle.
Title: Re: Game engine structure
Post by: Dream of Omnimaga on March 31, 2015, 10:12:15 PM
What do racto and M.O mean? As for battle convos, I usually just split boss fights into multiple parts and had the entire battle program exit without clearing the screen in order to perform special tasks such as boss convo.
Title: Re : Game engine structure
Post by: Duke "Tape" Eiyeron on April 01, 2015, 08:12:24 AM
reactions* Modus Operandii* (the way it acts)
Title: Re : Game engine structure
Post by: Dream of Omnimaga on April 02, 2015, 06:30:27 AM
Ah ok thanks for clarifying >.<. I assume by reactions you mean for example when the boss reaches a certain amount of HP and counter-attacks to specific spells? In Mana Force for example Boss 6 will not use Poison spell until he gets under 8000 HP, but since that's the only boss in the game that does that I didn't bother making it part of the engine. If I was to make a game where such event is a common occurence it would definitively not be hardcoded. >.<
Title: Re : Game engine structure
Post by: Duke "Tape" Eiyeron on April 02, 2015, 07:34:23 AM
Yeah, that's absolutely what I want to do, but I want to make as flexible as I would (and boy, I need o do so much things)