Software Tool Selection Process - Improvements please

Started by
37 comments, last by frob 8 years, 5 months ago

Here is my new process for choosing software tools. Any suggestions or thoughts are welcome.

*edit* - The "Do I need this?" box is the starting choice. I'll add a start bubble later.

CTiURqgUkAAvCx5.png

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

Advertisement

do i need this? yes.

is there one out there for free? (don't re-invent the wheel when there are free ones available). if yes, use that tool.

is there one out there for cheap? (don't re-invent the wheel when there are ones available for chump change). if yes, use that tool.

is there one out there i can afford? (don't re-invent the wheel when you can afford to buy one). if yes, use that tool.

else make it yourself.

once i had to write a complete software renderer and a 3d modeling tool to go with it. i was about to license the reality lab poly engine for $1000, when microsoft bought rendermorphics, pulled the product, and released it as directx 1.0 a year or two later. so in the meantime, i had to roll my own.

off the shelf is always preferred if available and affordable.

custom tools are a means to an end, not an end in and of themselves. every line of code spent on a tool is one less line of code for the game (in a given amount of development time). but they can be the best - and sometimes the only practical way - to do things.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

It needs a start arrow.

Since you're "choosing software tools" I would assume you have a list to pick from. Shouldn't there be some form of iteration in it?

I wouldn't consider "can I make it myself" when choosing from a list. At least not until I have run out of the somewhat viable options.

"need" also includes the question "am I happy with what I have now". If not fully, I often do an exploratory test to see if the new tool improves the situation.

It needs a start arrow.

Since you're "choosing software tools" I would assume you have a list to pick from. Shouldn't there be some form of iteration in it?

I wouldn't consider "can I make it myself" when choosing from a list. At least not until I have run out of the somewhat viable options.

"need" also includes the question "am I happy with what I have now". If not fully, I often do an exploratory test to see if the new tool improves the situation.

Yes, I need a start arrow.

Recent twitter conversation

Me: "The more game development tools I try, the more I understand why you write your own. I swear, nothing works."

Casey Muratori: "And they _definitely_ won't work anymore after a few years. And that shelf life seems to be ever-decreasing..."

I am currently in favor of not using any tools I don't need. I would much rather figure out a simpler way to accomplish the task or write the tool myself.

Choosing a tool like Game Maker, Unity, Ureal, Blender, SDL, or anything like that should not be the default. It is a different way of thinking.

I've been asking these questions for a few weeks now. Most the people doing what I think is "meaningful" game development are all either using custom tools or wish they were.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

It's perhaps the idea that your own software doesn't have 'weird quircks'. It is a false idea though, you are just replacing them with your own weird quircks, but you don't recognize them as such.

In addition, you add a maintenance burden, so in the end your own software is slowing you down more than when you get something else.

I like the direction you are going, but I think you may end up in the difficult position of having to estimate opportunity costs which are not readily apparent.

For example, I can build 3d rendering + physics + game logic from the ground up in a few weeks. Many people here can. But to build that, plus the artist-friendly asset toolchain and robust multi-platform support which Unity provides out of the box... That's a mammoth task, and my artist can't get started until I complete large portions of it.

(not that I wouldn't give my eye teeth to be working in a custom engine rather than Unity, from a personal programmer perspective)

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

It's perhaps the idea that your own software doesn't have 'weird quircks'. It is a false idea though, you are just replacing them with your own weird quircks, but you don't recognize them as such.

In addition, you add a maintenance burden, so in the end your own software is slowing you down more than when you get something else.

If I actually knew how to do this, I would write it down and give it to the world. So far, I only know that this feels like the right direction.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

I like the direction you are going, but I think you may end up in the difficult position of having to estimate opportunity costs which are not readily apparent.

For example, I can build 3d rendering + physics + game logic from the ground up in a few weeks. Many people here can. But to build that, plus the artist-friendly asset toolchain and robust multi-platform support which Unity provides out of the box... That's a mammoth task, and my artist can't get started until I complete large portions of it.

(not that I wouldn't give my eye teeth to be working in a custom engine rather than Unity, from a personal programmer perspective)

That was part of the "will it take too long" step, which I'm sure isn't named correctly. Maybe, "will this delay the game too long", or something else?

and yes, trying to work with many different people doing many different things, you can't just make everything yourself. But what about all the studios out there before these tools? Didn't they all use custom tools? It took a long time to develop them, but those tools became the foundation of the tools we use today. The best ones became software sold to others.

When I see Handmade Hero, The Witness, Thimbleweed Park, and many other small studios using custom stuff, I can't help but wonder why.

Add to that, every day, I see complaints about the current tools, and tweets about new versions breaking old code, and I see something doomed for failure.

I know writing everything yourself is silly. I don't plan on creating a computer from sand and metal, and I don't think writing my own language is a good idea (but J. Blow does), but at some point, there is a place where adding more tools will only increase the complexity of the software.

Finding it is proving difficult.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

This is _awful_ advice.

Tools are literally the most important part of game development. Making your own means the _exact_ same things you are complaining about: no support available, constantly breaking and bitrotting, quirky and lacking in docs, etc.

Custom tools _also_ mean less developer time, lacking features that nobody could possibly implement on their own, a non-standard API or interface that no new hire will possibly have experience with, and so on.

Junior engineers get it into their head to rewrite perfectly good existing solutions. Experienced developers know better.

Like, seriously, this is one of the metrics we use to determine promotions.

Sean Middleditch – Game Systems Engineer – Join my team!

This is _awful_ advice.

Tools are literally the most important part of game development. Making your own means the _exact_ same things you are complaining about: no support available, constantly breaking and bitrotting, quirky and lacking in docs, etc.

Custom tools _also_ mean less developer time, lacking features that nobody could possibly implement on their own, a non-standard API or interface that no new hire will possibly have experience with, and so on.

Junior engineers get it into their head to rewrite perfectly good existing solutions. Experienced developers know better.

Like, seriously, this is one of the metrics we use to determine promotions.

Before I even read this I knew what you were going to say. It's not awful, just different. But I do understand where you're coming from, and opinions from both sides are wonderful.

Besides, if Jonathan Blow, Casey Muratori, and Ron Gilbert are all awful, then count me in.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

This topic is closed to new replies.

Advertisement