• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nicholas Kong

How do you know if you are not reinventing the wheel in your language

11 posts in this topic

It may sound like a straightforward answer like "Research until you are absolutely sure it has not been done".

But it does not seem to be an easy answer to me. Games are complicated piece of software. From experience, it would seem I need to build my own systems just so I can have total control of how the game looks(ie: GUI) how the game feel like (ie: animation system). I made 5 games. Finished a small scale rpg last month and every project I did always had its trials and tribulations.

Any thoughts if I am reinventing the wheel by building the above mentioned systems or is there something just like it?
0

Share this post


Link to post
Share on other sites

It depends...

 

I re-invent the wheel all of the time (sometimes through ignorance). But, I do like having complete say on what my code does (and complete understanding on how it does it). Makes it a lot easier to bug find I think.

 

You have to account for your time too. If something will take you a year to code and you can have it right away by using another API, you need to weigh up that too.

2

Share this post


Link to post
Share on other sites

There are many styles of wheels though, and different types of wheels are more efficient than other types for specific tasks. Who invented the wheel really? Then ask who invented the car wheel, and the bicycle wheel and monster truck wheels. 

 

I want my system done my way for my purposes, especially if a library doesn't work the way my mind works, or is hard to use. 

 

I agree 100%.

 

I often find when I set my mind to it to sort out a problem, most of the time my wheels 'spin faster' in the end (compared to alternative solutions).

 

What is written by people can usually be improved upon by people.

0

Share this post


Link to post
Share on other sites

In the end it is a matter of taste. I see nothing wrong with reinventing the wheel especially when you like the act of coding itself, and it gives you more control.

 

As an example when I was looking to implement A* and other path-finding solutions, I could have taken any of the libraries that already exist, instead I made my own. It's not the fastest or most elegant implementation ever, but it works. And more importantly I do understand how the A* algorithm work, I can reuse it in all my games and specifically customize it to handle game specific cases. Things that would have been much harder to do with a 3rd party library. I would never do my own GUI system, though tongue.png.

 

That's also why I am kinda annoyed by the "unity love parade" I see each time a beginner is asking where to start. Suggesting heavy high level engines to someone who barely know anything about programming or game logic systems is doing him a big disservice imho.

2

Share this post


Link to post
Share on other sites

If you reinvented the wheel by accident then there is nothing to worry abbout.  If you reinvented the wheel because you evaluated the other possible solutions and they didn't quite fit then this is fine.
When reinventing the wheel does become a problem is when you insist on writing everything yourself just because you don't trusst anybody elses code.  I have worked on one XBOX 360 title that failed because the new lead programmer insisted on scrapping the third party engine that had been used for the last 3 successful games  and writing the new one in house he even insisted on writing things like XML parsers and zip libraries in house because he didn't trust third party libraries.  Naturally the game missed its deadline the publisher pulled out and a once successful studio laid off nearly all its staff and now consists of just two guys doing edutainment mobile apps.

1

Share this post


Link to post
Share on other sites

Reinventing the wheels tends to save frustrations and money.

 

Think of it like this: you make an egg omelette from scratch. And any time you need to tweak the ingredients, you know exactly how to make it. Using pre-existing tools is like trying to tweak an egg omelette someone else made.

0

Share this post


Link to post
Share on other sites

Reinventing the wheels tends to save frustrations and money.

 

Think of it like this: you make an egg omelette from scratch. And any time you need to tweak the ingredients, you know exactly how to make it. Using pre-existing tools is like trying to tweak an egg omelette someone else made.

 

I know how to make an omelette in fact I know how to make dozens of different variety of omlettes ( I worked as a chef).  However nothing beats the satisfaction of paying somebody else to do it for me simply because my time is too valuable.

 

Its the same thing with games you may think it will save you frustration and money but most games have deadlines (even indies can only last for so long before they need to ship).  Also there it is a known condition that most developers will see a piece of software and say "I can write that better and it will only take me X amount of time" and they nearly always either take much longer than they initially figured or they produce a much worse version but won't admit to themselves that it is worse.

One of the most detrimental problems in any software house is Not Invented Here Syndrome (NIHS).

0

Share this post


Link to post
Share on other sites

Also, some wheels are quicker to just make yourself, instead of trying to find a ready-made that fits your requirements.

 

3rd party code does not mean "no work", and not even necessarily "less work".

 

And its easier to evaluate the wheel-options if you have some experience in actually making wheels

Edited by Olof Hedman
1

Share this post


Link to post
Share on other sites

My wheel has an extra degree of freedom and is more of a ball joint really, and also has fittings for when I later want to attach a jet engine.  Don't judge; it seemed like a good idea at the time :)

 

Seriously though, there can be good reasons for reinventing the wheel.  It can be a learning experience, or you may need some feature that doesn't exist and makes it faster to reimplement from scratch than add to an existing library. If you're writing code as a hobby, then write what interests you. If you're doing a job for money, then other considerations become more important.

1

Share this post


Link to post
Share on other sites


If you reinvented the wheel by accident then there is nothing to worry abbout. If you reinvented the wheel because you evaluated the other possible solutions and they didn't quite fit then this is fine.
When reinventing the wheel does become a problem is when you insist on writing everything yourself just because you don't trusst anybody elses code. I have worked on one XBOX 360 title that failed because the new lead programmer insisted on scrapping the third party engine that had been used for the last 3 successful games and writing the new one in house he even insisted on writing things like XML parsers and zip libraries in house because he didn't trust third party libraries. Naturally the game missed its deadline the publisher pulled out and a once successful studio laid off nearly all its staff and now consists of just two guys doing edutainment mobile apps.

 

Totally agree.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0