I started doing this. I kinda gave up after I started making entire separate dlls for every tiny little thing.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
So basicacally it's good to draw the line somewhere. The reailty is, it won't be all that much different to patch one dll or to just patch the entire 3-6MB executable that is your game. It might seem a lot cleaner but it takes a lot more effort and thought without very much benefit to split up an engine into different dlls.
In the end I decided to just have my engine be a giant statically linked library. If I'm making a tool for the engine that uses the renderer, the tool uses the renderer and no other part of the engine. The person making the tool still has access to the ENTIRE engine library which might seem a bit unclean but really it's no different than having access to the entire C standard library when all you want to do is make a "Hello World" application or something.
The important thing is results. Did you deliver the tool maker the necessary library functionality so he can make use of your renderer? Or are you spending months constantly rewriting your engine to have better encapsulation between the components while the person needing your renderer is left waiting?
Now imagine instead that that's a game you could have potentially released and gotten praise for from random gamers who couldn't care what so ever how you made that game.
(LOL in the end this rant became more something aimed at one of my friends...)
Show differencesHistory of post edits
#3ill
Posted 31 January 2012 - 07:21 PM
I started doing this. I kinda gave up after I started making entire separate dlls for every tiny little thing.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
So basicacally it's good to draw the line somewhere. The reailty is, it won't be all that much different to patch one dll or to just patch the entire 3-6MB executable that is your game. It might seem a lot cleaner but it takes a lot more effort and thought without very much benefit to split up an engine into different dlls.
In the end I decided to just have my engine be a giant statically linked library. If I'm making a tool for the engine that uses the renderer, the tool uses the renderer and no other part of the engine. The person making the tool still has access to the ENTIRE engine library which might seem a bit unclean but really it's no different than having access to the entire C standard library when all you want to do is make a "Hello World" application or something.
The important thing is results. Did you deliver the tool maker the necessary library functionality so he can make use of your renderer? Or are you spending months constantly rewriting your engine to have better encapsulation between the components while the person needing your renderer is left waiting?
Now imagine instead that that's a game you could have potentially released and gotten praise for from random gamers who couldn't care what so ever how you made that game.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
So basicacally it's good to draw the line somewhere. The reailty is, it won't be all that much different to patch one dll or to just patch the entire 3-6MB executable that is your game. It might seem a lot cleaner but it takes a lot more effort and thought without very much benefit to split up an engine into different dlls.
In the end I decided to just have my engine be a giant statically linked library. If I'm making a tool for the engine that uses the renderer, the tool uses the renderer and no other part of the engine. The person making the tool still has access to the ENTIRE engine library which might seem a bit unclean but really it's no different than having access to the entire C standard library when all you want to do is make a "Hello World" application or something.
The important thing is results. Did you deliver the tool maker the necessary library functionality so he can make use of your renderer? Or are you spending months constantly rewriting your engine to have better encapsulation between the components while the person needing your renderer is left waiting?
Now imagine instead that that's a game you could have potentially released and gotten praise for from random gamers who couldn't care what so ever how you made that game.
#2ill
Posted 31 January 2012 - 07:17 PM
I started doing this. I kinda gave up after I started making entire separate dlls for every tiny little thing.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
So basicacally it's good to draw the line somewhere. The reailty is, it won't be all that much different to patch one dll or to just patch the entire 3-6MB executable that is your game. It might seem a lot cleaner but it takes a lot more effort and thought without very much benefit to split up an engine into different dlls.
In the end I decided to just have my engine be a giant statically linked library. If I'm making a tool for the engine that uses the renderer, the tool uses the renderer and no other part of the engine. The person making the tool still has access to the ENTIRE engine library which might seem a bit unclean but really it's no different than having access to the entire C standard library when all you want to do is make a "Hello World" application or something.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
So basicacally it's good to draw the line somewhere. The reailty is, it won't be all that much different to patch one dll or to just patch the entire 3-6MB executable that is your game. It might seem a lot cleaner but it takes a lot more effort and thought without very much benefit to split up an engine into different dlls.
In the end I decided to just have my engine be a giant statically linked library. If I'm making a tool for the engine that uses the renderer, the tool uses the renderer and no other part of the engine. The person making the tool still has access to the ENTIRE engine library which might seem a bit unclean but really it's no different than having access to the entire C standard library when all you want to do is make a "Hello World" application or something.
#1ill
Posted 31 January 2012 - 07:09 PM
I started doing this. I kinda gave up after I started making entire separate dlls for every tiny little thing.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.
Instead I'm just going to have one giant library for the engine itself.
I was looking in the Crysis folders and saw they had a lot of separate dlls called things like CryThread.dll, CryFont.dll, so they managed to split up the different parts pretty nicely.
I also found that in theory a lot of systems can easily be separate, but there are still many dependancies between everything. It's definitely good to try to decouple systems as much as you can but it doesn't work out quite that well in theory.
For example the developer console is it's own system.
The graphics depend on the developer console for all the variables and console commands to do with the graphics system.
The developer console depends on the graphics to display itself.
Basically you start needing to make things extremely generic which takes a lot of effort. While before I could hook two systems up in five minutes, I now need to take an hour or so to think about how to create complex generic interfaces between them and then implement it. This would be fine if I wanted to release, let's say, a Developer Console library for the community to use in their games. I have no interest in that though, all I want to do is make a game rather than spending hours of my day making everything with extremely good design. So I do good design but not perfect design.
In the end I have faster results. An average person playing my game isn't going to think, "OH MY GOD, WHAT AMAZING DESIGN AND DECOUPLING THEY HAVE BETWEEN ALL THE COMPONENTS!!!!" They'll see an awesome game that I was able to make quickly.
On the other hand if you worry about absolutely perfect design at all times, you'll be stuck rewriting your engine constantly for years with no results.
It took me about 6 years of making games before I learned this, and I'm still trying to transition into that line of thinking. It's just hard because I care about good design a little too much sometimes.