• 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
stephenfx

What do you think of the D language?

93 posts in this topic

In VS2005 at least, you can collapse C# code to definitions so it looks exactly like a c++ header, only without the compilation annoyances and logistical hooplah.
0

Share this post


Link to post
Share on other sites
OK I concede the point. Documentation is more important and I have been annoyed in the past by having to maintain comments and such between headers and code files.

But if there's no documentation then the first place I look is in the header file, and go from there.
0

Share this post


Link to post
Share on other sites
If you're still not convinced, here's a simple thing you can do. Open the std::map header (that's <map>) and read it to figure out its interface. (Yes, I recognize this is a C++ flaw rather than an inherent problem with headers.)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradigm Shifter
Headers allow you to see interface rather than implementation...

No, they give you both. What do you think private class members are? Besides, any decent IDE these days lets you collapse a source file to definitions, which would give you the same interface information even without separated header files.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
My entire point was that if you are looking for a Game library to use with C# you have 2 choices:

Tao, which supports only one commercially viable platform.
Managed Direct X, which supports two.

So - Mono, which only supports Tao, is unsuitable for commercial game programming.

How can I be clearer?


It's not about being clear. It's about being correct.

You're stuck in this loop where you equate "not the best" with "not usable at all". And I'm getting sick of that falicious reasoning. And yet you keep trying to use it!

Quote:
Original post by Promit
I never even implied C# was suitable for professional game development. No languages other than C or C++ are ...


The developers of Arena Wars would disagree with you there.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
In VS2005 at least, you can collapse C# code to definitions so it looks exactly like a c++ header, only without the compilation annoyances and logistical hooplah.
In D programming, you can either use headers or not. Most projects would probably not bother with headers, just import the (complete) module directly. For a library, strip out the module implementation leaving just the declarations. The D compiler can do this, generating a header module directly from a regular module.

There's a program to automatically translate a C .h header file to a D import. It'd be cool if there was one for C++ headers, too, but alas.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
Original post by Promit
I never even implied C# was suitable for professional game development. No languages other than C or C++ are ...


The developers of Arena Wars would disagree with you there.
Arena Wars is good and all, but it still stands basically as an indie title, rather than a professional one. (Yes the distinction is tenuous.)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
Quote:
Original post by Telastyn
In VS2005 at least, you can collapse C# code to definitions so it looks exactly like a c++ header, only without the compilation annoyances and logistical hooplah.
In D programming, you can either use headers or not. Most projects would probably not bother with headers, just import the (complete) module directly. For a library, strip out the module implementation leaving just the declarations. The D compiler can do this, generating a header module directly from a regular module.

There's a program to automatically translate a C .h header file to a D import. It'd be cool if there was one for C++ headers, too, but alas.


I was responding directly to Paradigm Shifter's comments; and I should have quoted. And now, I should leave, as I've not used nor any interest in using D.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by MaulingMonkey
Quote:
Original post by Promit
I never even implied C# was suitable for professional game development. No languages other than C or C++ are ...


The developers of Arena Wars would disagree with you there.
Arena Wars is good and all, but it still stands basically as an indie title, rather than a professional one. (Yes the distinction is tenuous.)


Tenuous at best. I'd much rather distinguish between the developers of professional AAA titles and indies. In which case I'll agree with you :P.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
Original post by Nitage
My entire point was that if you are looking for a Game library to use with C# you have 2 choices:

Tao, which supports only one commercially viable platform.
Managed Direct X, which supports two.

So - Mono, which only supports Tao, is unsuitable for commercial game programming.

How can I be clearer?


It's not about being clear. It's about being correct.

You're stuck in this loop where you equate "not the best" with "not usable at all". And I'm getting sick of that falicious reasoning. And yet you keep trying to use it!


No.

I'm claiming that Mono is "not suitable for commerical game programming".
I am not claiming that Mono is ""not usable at all".


You and Promit claimed that Mono was suitable for game developement.

[Edited by - Nitage on October 5, 2006 5:05:19 AM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
No.

I'm claiming that Mono is "not suitable for commerical game programming".
I am not claiming that Mono is ""not usable at all".

You and Promit claimed that Mono was suitable for game developement.


1) Promit didn't claim much of anything, as he himself points out.

2) Usable is a synonym of viable (reference) so when you did claim it to be unviable, you did claim it to not be usable at all within the context of commercial* game programming (which is the obvious subject).

3) I've already posted a direct example that could lead to the Tao framework being better suited for a given indie project than MDX. Without addressing this in the slightest, you continue to write off Mono as unsuitable - or more obviously worded, not usable at all in a project with a sane leader/manager within the context of commercial game programming.

4) It's also worth noting that if this is any indicator, Arena Wars originally used OpenGL.

Quote:
W3bbo [Feb 14 2006]: "I'll add that Arena Wars was developed in C#, but the 3D power is OpenGL, not Managed DirectX."

Minh [Feb 14 2006]: "Arena Wars was recently converted to use Managed DirectX. It has an amazing world editor, BTW, if you're interested in that kind of stuff."

(note the timestamps are over a year older than the original release)

I'd wager their reasons had something to do with the same exact situation as I described earlier - API familiarity.


* Where I'm taking "commercial" to mean "In the interests of making money" rather than any "AAA Title/Top of the crop/Big business" definition.
0

Share this post


Link to post
Share on other sites
Quote:

2) Usable is a synonym of viable (href="http://dictionary.reference.com/browse/viable">reference) so when you did claim it to be unviable, you did claim it to not be usable at all within the context of commercial* game programming (which is the obvious subject).


Synonyms are different words with identical or similar meanings.

The link you gave listed the following synonyms for viable: practical, feasible, usable, adaptable.

I've used bold to indicate the meanings that you deliberatley chose to ignore in an attempt to make me look foolish.

Quote:

Quote:

You and Promit claimed that Mono was suitable for game developement.

1) Promit didn't claim much of anything, as he himself points out.


In reply to a post suggesting that Mono is nowhere near being a credible solution. Promit said "This is just the part where I leave the thread, because the person I'm talking to is an idiot."

This clearly shows he strongly disagrees with that assessment.


Quote:

3) I've already posted a direct example that could lead to the Tao framework being better suited for a given indie project than MDX. Without addressing this in the slightest, you continue to write off Mono as unsuitable - or more obviously worded, not usable at all in a project with a sane leader/manager within the context of commercial game programming.


Given the big differences between Indie and commercial developement - not limited to the fact that Indie developers almost never target consoles - demonstrating that Tao is viable for Indie developement does not demonstrate that Tao is viable for commercial development. I didn't address your point because it wasn't relevant.

It is worth noting though that even though OpenGL was originally used for Arena Wars (presumably porting to the XBox was never a issue for them), the developers then went to the trouble of porting in to Managed DirectX.

So your example shows that the developers of Arena Wars considered the benefits using Managed DirectX outweighed the cost of porting to it. Hardly a glowing recomendation for OpenGL with .Net.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
Quote:

2) Usable is a synonym of viable (href="http://dictionary.reference.com/browse/viable">reference) so when you did claim it to be unviable, you did claim it to not be usable at all within the context of commercial* game programming (which is the obvious subject).


Synonyms are different words with identical or similar meanings.

The link you gave listed the following synonyms for viable: practical, feasible, usable, adaptable.

I've used bold to indicate the meanings that you deliberatley chose to ignore in an attempt to make me look foolish.


That's what I'm doing, is it?

I'll give you the benifit of the doubt that you've only ommited #4 which would seem to indicate it to be practical and feasible as well because you hit reply before I edited it in... even though you've done similar to numerous posts of mine ignoring their content which were in fact in the original versions.

Quote:
In reply to a post reply to a post that was itself a reply to a post which among many other things suggested that Mono is nowhere near being a credible solution. Promit said "This is just the part where I leave the thread, because the person I'm talking to is an idiot."


Fixed. It clearly shows jack shit, given that Promit explicitly contradicts the conclusion you've arrived at later:

Quote:
Original post by Promit
I never even implied C# was suitable for professional game development. No languages other than C or C++ are ...


Quote:
Quote:
3) I've already posted a direct example that could lead to the Tao framework being better suited for a given indie project than MDX. Without addressing this in the slightest, you continue to write off Mono as unsuitable - or more obviously worded, not usable at all in a project with a sane leader/manager within the context of commercial game programming.


Given the big differences between Indie and commercial developement - not limited to the fact that Indie developers almost never target consoles - demonstrating that Tao is viable for Indie developement does not demonstrate that Tao is viable for commercial development.


There are commercial indie projects ~_~. While there are various definitions of "commercial" which can exclude them entirely - the British Informal usage to refer to a traveling salesperson for example - none of them apply to game develop that can't be applied to, say, Arena Wars as well.
0

Share this post


Link to post
Share on other sites
Quote:
In reply to a post reply to a post that was itself a reply to a post which among many other things suggested that Mono is nowhere near being a credible solution. Promit said "This is just the part where I leave the thread, because the person I'm talking to is an idiot."


No. Not amongst many other things:
Quote:
The entire contents of the post I'm referring to
Quote:
[i]Original post by Conner McCloud[i]
Quote:
Original post by Stachel
Mono is nowhere near being a credible solution.

Oh man, now you've really gone and pissed Promit off.

It happens. This is just the part where I leave the thread, because the person I'm talking to is an idiot.



Quote:

That's what I'm doing, is it?

Seeing as you're American, I assumed that English was your first language, so you were deliberatley misunderstanding me. If that isn't the case, I apologise.

Quote:

I'll give you the benifit of the doubt that you've only ommited #4

That's kind seeing as I'd have to have violated the laws of physics to take your 4th point into account.

Quote:
I've already posted a direct example that could lead to the Tao framework being better suited for a given indie project than MDX.


The Arena Wars team switched to MDX - so they thought MDX had enough advantages over OpenGL to outweigh the cost of the switch. Hardly a recommendation - in fact I'd say it indicates the opposite of what you're trying to argue.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradigm Shifter
OK I concede the point. Documentation is more important and I have been annoyed in the past by having to maintain comments and such between headers and code files.

But if there's no documentation then the first place I look is in the header file, and go from there.


The D compiler has automatic documentation generation from comments built into it. Instead of looking at headers, just compile the documentation (based on your comments), and there you go.

http://www.digitalmars.com/d/ddoc.html

[Edited by - clayasaurus on October 5, 2006 8:16:38 AM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
Quote:
In reply to a post reply to a post that was itself a reply to a post which among many other things suggested that Mono is nowhere near being a credible solution. Promit said "This is just the part where I leave the thread, because the person I'm talking to is an idiot."


No. Not amongst many other things:


Yes, amongst many other. The quoted material was cropped for berevity of that. The quoted material was but one sentance out of 5 seperate paragraphs of the original post to which the intermediate reply was to. Which Promit dosn't even make a single comment directly on.

The entire contents of the post that was being replied to by the post that Promit replied to (linked because the whole thing is a bit much to post here, what with it's own quotations of paragraphs of material and all).

Quote:
Quote:

That's what I'm doing, is it?

Seeing as you're American, I assumed that English was your first language, so you were deliberatley misunderstanding me. If that isn't the case, I apologise.


You're right on my native tounge, but I've only heard "(un/non-)viable" used in absolutes in contexts where "(un/non-)doable" is equivilant, or magnitudes more difficult than what's considered "acceptable" in situations where "acceptable" has been relatively well defined (that is, totally out the window of being a possible comprimise), or in violation of some uncomprimiseable mandate.

Quote:
Quote:

I'll give you the benifit of the doubt that you've only ommited #4

That's kind seeing as I'd have to have violated the laws of physics to take your 4th point into account.

I'll have to take your word for it.

Quote:
Quote:
I've already posted a direct example that could lead to the Tao framework being better suited for a given indie project than MDX.


The Arena Wars team switched to MDX - so they thought MDX had enough advantages over OpenGL to outweigh the cost of the switch. Hardly a recommendation - in fact I'd say it indicates the opposite of what you're trying to argue.


Hardly a recommendation indeed, but definately a solid indicator of viability. Given that I could easily see myself doing the same thing in their place soley for the sake of learning another API makes it seem a shakey argument at best against it. Certainly an indicator to try and do a little further research if I was leaning towards using the Tao in my next project to find out if MDX had more advantages, or the Tao more disadvantages, than I'd been aware of, but little more to me.
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