Technical Design Document

About the actual programming of the game.

Re: Technical Design Document

Postby adam » Tue Sep 17, 2013 9:58 pm

mrout wrote:adam: Just a couple of things:

  • Thirdly, the vast majority game mechanics haven't even been decided on yet. It's useless to start discussing the implementation of things we haven't even decided on implementing yet, if you know what I mean.

I don't want to start and flame wars or arguments, but as it stands right now the WE in that statement refers to you. The rest of the WE have made it very clear what systems we want via the Trello. This is a community project and as such the community will have its say in the direction of the design. I am not saying democracy, but I am saying a let the voice of the people guide our hands.

I personally find you have no known qualifications that allow you to justify your claim that we don't need a technical design document. I am more than willing to show what I have done and my experience with iterating over 3 game engines I have made myself. If you have some equal qualifications please let them be known or quit belittle others opinions and knowledge.
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Technical Design Document

Postby Pseudonym » Thu Sep 19, 2013 12:57 am

mrout wrote:Firstly, I don't need to convince you or anyone else that we are using a custom engine. Project Trillek is using a custom engine. That was decided very early on for a wide variety of reasons (including that we're making a very unique game, that the game must be able to be developed on and the game must run on Linux, along with a lots of other factors), and this is not up for discussion.

The engine part was put in partly at my suggestion.

The reason is that one of the key assumptions why we went with this approach may be no longer true. According to those who know about this sort of thing, there is a new version of Torque 3D coming in a couple of weeks, which allegedly supports Windows, Linux and OS X as development platforms (it already supported them all as runtime platforms).

This means it would tick most of the boxes: runs everywhere, can develop everywhere, good quality, and the right licence. I am in favour of evaluating it when it's released to see what we could do with it. We might build a layer on top of it, or customise it heavily, or scavenge bits of it, or decide it's just not worth it. It won't be perfect, but nothing will be.

This is an agile project (even if it isn't big-A Agile). We shouldn't get distracted with every little suggestion that comes along, but we should also not be afraid to change our minds, especially if it could save a year of work with very little downside. As always, the bigger the change, the more deliberate it has to be.

Of course, until such time as it's actually released, we should keep doing what we're doing right now. We should never rely on unreleased/unavailable code.
Posts: 129
Joined: Tue Aug 13, 2013 3:54 am


Return to Code

Who is online

Users browsing this forum: No registered users and 1 guest