I think it can be useful to start with a 'blank canvas' and roll your own solutions (reinventing the wheel instead of using stock solutions). I've been doing it on my Unity project because I converted a project from a totally different programming language and paradigm into c# and unity (it was actually written in a programming language for the Amiga originally). This left me with no choice but to add in certain things which I had to build from scratch. Now that I've done this, I've got my own UI building, tracking and events code which I know thoroughly inside out and makes building menus within the game (it's an RPG I'm building, a scifi one) really easy to do. Knowing the code so well also makes it easier to debug. There are some things that it cannot yet do, such as handle easing transitions, but it can do other things, such as numbers counting upwards from x to y automatically, which is great for text and graph displays on character screens. I'm pretty sure I'll get around to adding the rest as and when I need it. So yes, I think there can be an argument for this type of approach and benefits too.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Reinventing the wheel
6 hours ago, francoisdiy said:Who cares it's a "waste of time".
Your employer/backer/significant other who would like you to stop f#$king around and finish the goddamn game so we can pay the rent?
None of which matters on a hobby project, of course.
4 minutes ago, ChaosEngine said:Your employer/backer/significant other who would like you to stop f#$king around and finish the goddamn game so we can pay the rent?
None of which matters on a hobby project, of course.
Rent sucks, wasting time is what life is about! My employer can suck eggs for all I care!
Since a few years i privatly start question everything. I dont take anything just as it is, because most of the time its not exactly what i want at all. So i end up writing a lot myself when i see myself fighting a lot against other api´s. But when i find good libraries i use it of course - which btw is really rare...
When i can i will surely make things from scratch, so i see how something works in very detail and build up from there. Understanding all the low level parts is really good and you get a much broader view about the thing you are doing.
At work i do the total opposite, i just use propertiery thirdparty stuff everywhere where i can - it does not matter if it is good/fast or got a bad api. Just because time is key and there are no time and money for reventing wheels. This will mostly result in lousy and slow code, because nobody have any clue what happens in the background of all of the hundred of libraries at all. It barely works, but the customer dont care. What counts is that the unit-tests was all successful and the UI is fancy like hell.
To give an final conclussion which i totally agree with:
My 2 cents; what is your goal? Do you want to learn tech programming because eventually you want to be part of a team/ studio as a engine/ tech developer?
Or is learning in general the goal, then you should do and try things you want to learn more about.
If your goal is to finish a full game within the shortest time with minimal resources, then using an existing engine and/or framework could work.
In short; I'd always start with some goal 
11 hours ago, Finalspace said:To give an final conclussion which i totally agree with:
I also agree with this video. I know "reinvent the wheel" is just an idiom, but to say Unity is a wheel is an oversimplification of the product. I tend to see Unity or Unreal as more like products than wheels. Wheels in the programming sense would be rewriting quicksort, or rewriting std::vector. These are code that have been thoroughly tested that you can reuse immediately since these things are simple enough and can be reused in all of your projects just like real literal wheels can be used for all kinds of contraptions you can imagine.
Unity/Unreal are more like products that you use make games. Creating a game engine is not exactly equivalent to reinventing the wheel. You can do so if you have either of the following in mind:
1. To compete directly with Unity/Unreal. If you somehow see an angle that you can compete with these two giants with multi-million dollars and hundreds of developers behind them, then by all means do it.
2. Just to learn the process about making game engines, but not necessarily try to compete with Unity/Unreal.
If you just want to make a game, then there's nothing wrong with using Unity/Unreal, but be informed that your skills are dependent on using their products. There's also nothing wrong with sending vertices yourself to the OpenGL buffers, just that it of course would be more time consuming.
9 hours ago, alnite said:Wheels in the programming sense would be rewriting quicksort, or rewriting std::vector. These are code that have been thoroughly tested that you can reuse immediately since these things are simple enough and can be reused in all of your projects just like real literal wheels can be used for all kinds of contraptions you can imagine.
Neither quicksort or std::vector is a wheel - not even close. Quicksort is okay right know, but in the future i expect we have sorting algorythms which are 1000 times faster. Vector are based on a good idea (dynamic growing array), but it has a bad api, bad control of memory and the implementation is a nightmare of macros and templates, impossible to debug or to find errors which are related. Other languages does this much much better, but even those are still not a wheel. Each one have weaknesses and flaws, some have a great api but bad technical implementation and vice versa - the "wheel" has nothing of that sort, its near perfect.
Sure its the best we have right know, but like casey sayd - nothing in the past 30 years of game development is a wheel. I would go even further and state that nothing in the past 30 years of any software development is a wheel, especially the web which is the clunkiest square wheel ever made.
So we need people which question things and try to make the next wheel. If nobody tries that, we never get a wheel. Its as simple as that.
I fully agree with ApochPiQ; his position most closely aligns with mine. I would add a few extra notes though:
1) If you are reinventing the wheel, think very carefully and prudently about why you are doing so and what your objectives are. The best reason to reinvent the wheel is for practice and skill development. If you move through the motions of implementing something that already exists, you can use the original to check your work -- its like doing a math problem and checking your answers. The goal is not to get the math problem correct, but to understand the broader process necessary for arriving at correct answers. Reinventing the wheel can be a good way to develop your research and development skills. When you hit the current boundary of tech / state of the art and you need better, you are capable of pushing the boundary forward.
2) If you are working commercially or professionally, reinventing the wheel is a waste of time. Time is money, so you are wasting money as well. If you are a professional and find yourself reinventing the wheel, spend some time thinking long and hard about why you are doing this and what the business case / justification for it is. Talk to your boss / manager / client for sign off before moving forward.
21 hours ago, Finalspace said:To give an final conclussion which i totally agree with:
Hecking great response. Put in words what I never could 
29 minutes ago, slayemin said:2) If you are working commercially or professionally, reinventing the wheel is a waste of time. Time is money, so you are wasting money as well. If you are a professional and find yourself reinventing the wheel, spend some time thinking long and hard about why you are doing this and what the business case / justification for it is. Talk to your boss / manager / client for sign off before moving forward.
I agree with this. In my post, I was more towards to the developer that works for themselves (or the hobbyist). I would never ever, reinvent the wheel if I was working for someone else, unless specified. First, the project manager certainly have a plan and your wheel reinvention isn't in it. Second, it's not your project. Reinventing the wheel is something original, and you would be giving away something original to someone else with no reason. Unless your reason is to show yourself for the boss and up the chances of a promotion (which to be honest, there are better ways to do so, instead of giving away your original creation).
