What an interesting webcast this is: Jamie Fristrom & Bill Dugan (from
Torpex Games) are commenting on their whole experience to bring Schizoid to the XBox Live! Arcade.
I do agree to what they have said about C#:
- the C# vs. C++ discussion for game development is like "C++ vs. Assembly" many years ago. With C# you forget about pointers, and that alone says a lot. Plus, performance, speed, etc. is becoming less and less an issue as many games, demos and samples demonstrates, and
- you don't need to use external languages for scripting (of course, you can do it if you want to), since you can use c# itself as a scripting language (as I said on this blog and on others' blogs).
In short, C# will rule (read my first posts).
What I don't agree -at least, partially: and I know Benny is also gonna hate me for this, is that Test-Driven Development is great for creating "proof-of-concepts" and prototypes -so as to bring your ideas close to the "real" thing quickly (and get some nasty bugs on the initial stages), but from a design viewpoint, relying only on tests to write the "final" implementation/output from scratch could be messy for the final stages and as a base for future projects (one could deem it as a "too aggressive" way of programming, again, only the final product, not the proptotypes).
I mean, you may find yourself in the need of changing many places to get the final product as well as to create future products (like "this class should be responsible for rendering this and that" -instead of the original class- and things like that) . And that could worsen, the bigger the game project, IMHO, of course.
With this I'm not saying "this approach is better than those", "don't use a rapid approach" or things like that. Instead, I'm saying "balance" is the key to a well-designed software. One should find its own approach -mostly if you're going solo, ... the one that you are most comfortable with, but it doesn't mean you have to use one and only one approach. In fact, your way of designing and programming games could be a mixture of methodologies derived from the type of project, available resources (including staff), time/stage/deadlines, and budget (estimated and current costs and ditto for funding).
Why "balance"? Because as these guys' just said (non-textual quote) "if you plan and discuss too much you face the risk that your project gets cancelled ..." (it doesn't matter whether you were implementing it or not), to what I must add, "... but if you plan too little you face the risk of having to redesign a lot of code at later stages."; both extremes could complicate things up in the end. So get the balance, optimus, equilibrium ("sounds" like a yoga class).
Now, I want to listen the round of questions, so bye ... for now!
