What are your overall goals for the engine? Something fully featured like like Unreal, or smaller but with a lot of core functionality like Ogre, or something minimal that just does exactly what it needs to do and nothing more? I find it's easy to get carried away with ideas of making giant engines with tones of functionality, my advice would definitely be start small with core functionality that you 100% need before you get carried away optimizing and making features that are cool but not overly needed.
Originally our goals were for something simple, and not to compete with a larger, more established engine like Unreal or Unity- after all, that would be madness.
Instead we were aiming for something in-between a big game engine and and stuff like XNA - basically a C# version of LibGDX.
Now we're not aiming to release the engine with the game it makes life a lot easier. We only need to support exactly what we require - and must-haves like documentation and API flexibility (which take up a lot of time) are no longer necessary.
I too am in the "Don't prematurely optimize" camp.
I'm building a Game Engine / Framework myself. When I work on it, I think to myself, "Maybe I should invite some people to try this out, get some different opinions". Then, I remember my inefficient code and my pride gets the better of me.
So, the project remains a secret between me and my therapist.
If I can suggest anything, it's to show people (or make blog posts detailing your failures, haha ;)). You'll learn about yourself as you write about yourself, and perhaps more importantly, opening yourself up to criticisms is the best way to learn (as long as you can stomach the harsher stuff).
I was mostly joking about keeping it a secret. The truth of the matter is, it's too early to do much of any use with it and I'd rather wait until I can at least make a pong tutorial before I can expect other people to get excited about it.
You can take a look if you like. I'm actually OK with productive criticism.
The general idea behind it is, if you like the idea of Rails or Django for fast web development, you'll like the idea behind this framework for game development. I admit, purists will hate it, but that's OK. This isn't for purists.
Good post, but my golden rule is: extremely applying some guidance never bring any good. YAGNI is one. If you develop something without at least researching and developing some of useful-simple features then you will be faced with refactor-intensive code or WET (write everything twice) code out there.
That said, if you have enough manpower and resource to develop the engine, you can always develop with documentation-driven-development first then followed by test-driven-development. To be honest, I am always regret myself for developing a framework without documentation-driven-development due to lack of manpower.
If you don't have manpower and resource, focus to develop some simpler useful utilities features first. Example if you use stong-typed language as Java or C#, non-throwing data conversion tools will be useful (from string especially). For weak-typed language as javascript, data-type detection tools or explicit data-type conversion tools will be useful. Priority on tools that: 1. do primarily close to one job only (non-complex), 2. have close to none configuration, 3. certainly will be used.
And you get it wrong on flexibility. Flexibility can be achieved by many things, clean or ugly. Reflection flexibility is imho ugly, unless you know what you are doing with it (dynamic code compiler is one thing that can be helped with reflection). Reflection also slow for large data operation (AutoMapper suffer from this). Dependency injection is cleaner, but still the implementation is debatable whether it is clean or not.
After all, only experience can determine whether you can develop a good flexible usable features or resort to refactor-intensive code. However overall, good post.
Good post, but my golden rule is: extremely applying some guidance never bring any good. YAGNI is one. If you develop something without at least researching and developing some of useful-simple features then you will be faced with refactor-intensive code or WET (write everything twice) code out there.
I agree of course - taking any advice to its extreme is pretty much always harmful. I wasn't saying you shouldn't think hard about your code before you implement things; more that you should be careful not to 'value-add' along the way.
And you get it wrong on flexibility. Flexibility can be achieved by many things, clean or ugly. Reflection flexibility is imho ugly, unless you know what you are doing with it (dynamic code compiler is one thing that can be helped with reflection). Reflection also slow for large data operation (AutoMapper suffer from this).
Flexibility isn't impossible, but makes everything harder. I do believe that in a lot of cases it is also unnecessary, but if you are writing an API that will be consumed by the public I understand (and agree) that you must consider it. Though I will point out that the particular type of reflection I was referring to wasn't C# reflection but HLSL Reflection in this case.
I think perhaps by saying that I think people should strive to make their APIs less flexible I might be accused of trying to give one-size-fits-all advice, and I understand your concern there. I do stand by my assertion that in general that is a good rule, though. Also as a side-note, I hate DI :) And DI really is just a form of reflection-based flexibility, also.
Thanks for the comments! And glad you enjoyed the post.
Looks like I misunderstand your writing. Do you write the article to discuss about the internal design of your game engine or API that will be exposed outside? I read it as the former and looks like you are referring to the latter one.
If the case is to develop API which will be used, then implicit flexibility (the condition is unknown to the user) is indeed, more harmful than good. Explicit flexibility (different parameter type for example) is arguable though. Having API with close to one operation and close to none configuration is better than the opposite (exceptions still apply though).
For the internal process, flexibility to certain degree is indeed required, otherwise it'll lead to major refactoring here and there. And no, DI with constructor injection is different than reflection-based flexibility. But it's another discussion about DI.
Moreover, documentation-driven-development will be more useful for API development.
12 comments
2 u/pm_me_firearms 28 Jul 2015 02:53
I'm still learning this the hard way. Good luck with your game.
1 u/Xenoprimate [OP] 28 Jul 2015 03:08
Thank you!
2 u/CatInTheHat 28 Jul 2015 05:29
What are your overall goals for the engine? Something fully featured like like Unreal, or smaller but with a lot of core functionality like Ogre, or something minimal that just does exactly what it needs to do and nothing more? I find it's easy to get carried away with ideas of making giant engines with tones of functionality, my advice would definitely be start small with core functionality that you 100% need before you get carried away optimizing and making features that are cool but not overly needed.
1 u/Xenoprimate [OP] 29 Jul 2015 02:51
Originally our goals were for something simple, and not to compete with a larger, more established engine like Unreal or Unity- after all, that would be madness. Instead we were aiming for something in-between a big game engine and and stuff like XNA - basically a C# version of LibGDX.
Now we're not aiming to release the engine with the game it makes life a lot easier. We only need to support exactly what we require - and must-haves like documentation and API flexibility (which take up a lot of time) are no longer necessary.
1 u/Master_Foo 28 Jul 2015 09:35
I too am in the "Don't prematurely optimize" camp.
I'm building a Game Engine / Framework myself. When I work on it, I think to myself, "Maybe I should invite some people to try this out, get some different opinions". Then, I remember my inefficient code and my pride gets the better of me.
So, the project remains a secret between me and my therapist.
0 u/Xenoprimate [OP] 29 Jul 2015 02:54
If I can suggest anything, it's to show people (or make blog posts detailing your failures, haha ;)). You'll learn about yourself as you write about yourself, and perhaps more importantly, opening yourself up to criticisms is the best way to learn (as long as you can stomach the harsher stuff).
1 u/Master_Foo 29 Jul 2015 15:55
I was mostly joking about keeping it a secret. The truth of the matter is, it's too early to do much of any use with it and I'd rather wait until I can at least make a pong tutorial before I can expect other people to get excited about it.
You can take a look if you like. I'm actually OK with productive criticism.
The general idea behind it is, if you like the idea of Rails or Django for fast web development, you'll like the idea behind this framework for game development. I admit, purists will hate it, but that's OK. This isn't for purists.
1 u/leixiaotie 28 Jul 2015 09:52
Good post, but my golden rule is: extremely applying some guidance never bring any good. YAGNI is one. If you develop something without at least researching and developing some of useful-simple features then you will be faced with refactor-intensive code or WET (write everything twice) code out there.
That said, if you have enough manpower and resource to develop the engine, you can always develop with documentation-driven-development first then followed by test-driven-development. To be honest, I am always regret myself for developing a framework without documentation-driven-development due to lack of manpower.
If you don't have manpower and resource, focus to develop some simpler useful utilities features first. Example if you use stong-typed language as Java or C#, non-throwing data conversion tools will be useful (from string especially). For weak-typed language as javascript, data-type detection tools or explicit data-type conversion tools will be useful. Priority on tools that: 1. do primarily close to one job only (non-complex), 2. have close to none configuration, 3. certainly will be used.
And you get it wrong on flexibility. Flexibility can be achieved by many things, clean or ugly. Reflection flexibility is imho ugly, unless you know what you are doing with it (dynamic code compiler is one thing that can be helped with reflection). Reflection also slow for large data operation (AutoMapper suffer from this). Dependency injection is cleaner, but still the implementation is debatable whether it is clean or not.
After all, only experience can determine whether you can develop a good flexible usable features or resort to refactor-intensive code. However overall, good post.
0 u/Xenoprimate [OP] 29 Jul 2015 03:01
I agree of course - taking any advice to its extreme is pretty much always harmful. I wasn't saying you shouldn't think hard about your code before you implement things; more that you should be careful not to 'value-add' along the way.
Flexibility isn't impossible, but makes everything harder. I do believe that in a lot of cases it is also unnecessary, but if you are writing an API that will be consumed by the public I understand (and agree) that you must consider it. Though I will point out that the particular type of reflection I was referring to wasn't C# reflection but HLSL Reflection in this case.
I think perhaps by saying that I think people should strive to make their APIs less flexible I might be accused of trying to give one-size-fits-all advice, and I understand your concern there. I do stand by my assertion that in general that is a good rule, though. Also as a side-note, I hate DI :) And DI really is just a form of reflection-based flexibility, also.
Thanks for the comments! And glad you enjoyed the post.
0 u/leixiaotie 29 Jul 2015 04:08
Looks like I misunderstand your writing. Do you write the article to discuss about the internal design of your game engine or API that will be exposed outside? I read it as the former and looks like you are referring to the latter one.
If the case is to develop API which will be used, then implicit flexibility (the condition is unknown to the user) is indeed, more harmful than good. Explicit flexibility (different parameter type for example) is arguable though. Having API with close to one operation and close to none configuration is better than the opposite (exceptions still apply though).
For the internal process, flexibility to certain degree is indeed required, otherwise it'll lead to major refactoring here and there. And no, DI with constructor injection is different than reflection-based flexibility. But it's another discussion about DI.
Moreover, documentation-driven-development will be more useful for API development.