• 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

Quote:
Original post by Promit
Quote:
Original post by Conner McCloud
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.

Mono doesn't support Managed DirectX, so it isn't suitable for games. End of story.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Mono doesn't support Managed DirectX, so it isn't suitable for games. End of story.


"PS3 doesn't support DirectX, so it isn't suitable for games. End of story."

Seriously though. Managed DirectX is not your only option. If you don't have your head buried in the sand you'd have heard of The Tao Framework and know it includes bindings to OpenGL, making Mono just as viable a platform for gaming as the PS3 - well, based on that assine metric of "viability" anyways.

Quote:
Mono is nowhere near being a credible solution.


If the chatter in #gamedev is any indicator, it is. Maybe not a credible solution for AAA titles, but I was under the impression that D as a whole was in this same situation. Where's the console support? At least C# has XNA (not that it makes it a "crediable solution", I'm too uninformed to make a statement to that regard - but it'd seem to be at least further along in this regard).

I'll certainly give you that Mono isn't a credible solution if you were planning on depending on the windows specific bits of C# (System.Windows, certain PInvokes, etc). Then again, nothing is, so it's hard to count that against C# as if it were unique in that regard.
0

Share this post


Link to post
Share on other sites
Tao isn't viable for comercial game developement as it doesn't support the XBox

Quote:

making Mono just as viable a platform for gaming as the PS3


Spending time and money porting to PS3 is commercially viable - the same can't be said for porting to Linux.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
Tao isn't viable for comercial game developement as it doesn't support the XBox



I don't like this circle ~_~. Subsitute "Tao" with "OpenGL" and you'll see you've used a false assumption premises - since, obviously, OpenGL is quite viable for comercial game development, what with being necessary to implement a game on the PS3 and all. Or did I not get a memo detailing the introduction of OpenGL support to the XBox?


To the degree that the Tao isn't well suited for comercial game development, it's due to having no console support whatsoever, leaving little it little advantage over Microsoft's .NET w/ Managed DirectX in terms of multi-platform support. Then again the same can be said of D's OpenGL bindings as well, which is about the entirety of my original point.


I'm not saying Tao + Mono = Prawnage (Because quite frankly the both C# and D fail miseribly when compared to C++ in terms of game platform support). I'm just saying, with MS's .NET, Tao, and Mono, C# arrives at about D's level of "portability". That is, D does not have an advantage here.


EDIT: with respect to game programming at least.
0

Share this post


Link to post
Share on other sites
Quote:

I'm not saying Tao + Mono = Prawnage (Because quite frankly the both C# and D fail miseribly when compared to C++ in terms of game platform support). I'm just saying, with MS's .NET, Tao, and Mono, C# arrives at about D's level of "portability". That is, D does not have an advantage here.


I'm not arguing with your conclusion, only your and Promit's opinion that Mono is a reasonable platform for game developement.

Quote:

I don't like this circle ~_~. Subsitute "Tao" with "OpenGL" and you'll see you've used a false assumption - since, obviously, OpenGL is quite viable for comercial game development, what with being necessary to implement a game on the PS3 and all. Or did I not get a memo detailing the introduction of OpenGL support to the XBox?


Ok then:
Tao isn't viable for comercial game development as it doesn't support the XBox, PS3 or Wii.

The only viable platform supported is Windows - so why not just use DirectX and make the XBox orders or magnitude easier?

Quote:

OpenGL is quite viable for comercial game development, what with being necessary to implement a game on the PS3 and all.


There's the thing. OpenGL is viable because the PS3 is a commerically viable gaming platform. Linux isn't a commerically viable gaming platform so Tao isn't viable.


0

Share this post


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

I'm not saying Tao + Mono = Prawnage (Because quite frankly the both C# and D fail miseribly when compared to C++ in terms of game platform support). I'm just saying, with MS's .NET, Tao, and Mono, C# arrives at about D's level of "portability". That is, D does not have an advantage here.


I'm not arguing with your conclusion, only your and Promit's opinion that Mono is a reasonable platform for game developement.


It's quite a reasonable platform for prototypes, game concept demos, and non-AAA titles, I believe. In all of these scenarios, lack of console support is hardly fatal. The best solution? Maybe. I'm not familiar with DirectX at all, for example, so using Tao gives me the small benifit of not being forced to get up to speed on another API just yet.

Certainly, if you're unfamiliar with OpenGL or familiar with DirectX, sticking to Microsoft's stuff is probably going to work out better, and the console support is an added bonus (at least in the "to be a commercial title" area) that outweighs those of Tao.

Quote:
Ok then:
Tao isn't viable for comercial game development as it doesn't support the XBox, PS3 or Wii.


Circle circle circle... s/Tao/Winsock2/ => Counterexample.

By the time you hack that statement to include Winsock by naming the major relevant platform it's used on (Windows), the Tao is supported on that list of platform alternatives, even if it isn't the the optimal solution (in most cases) due to there being a generally better alternative.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeadXorAlive
Especially the people that I think know what they are talking about, such as Sneftel, Promit and snk_kid.


Don't listen to me i'm just crazy [grin], seriously though I'm not that crazy about C# as some maybe. Man some of you guys just don't know what your missing with some of the non mass-majority languages out there, the more languages you try the more painful (and annoying) using mass-majority languages gets.

[Edited by - snk_kid on October 4, 2006 10:20:44 AM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it?
That's legitimate. [...] Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.
You'd think people would at least read the things I write. But no, instead I'm assigned the opinions people think I'm supposed to have. I never even implied C# was suitable for professional game development. No languages other than C or C++ are, and there's no indication that their momentum will run out any time soon. (What I did imply is that as far as performance goes, C# is comfortably fast enough for professional game development.)

Oh, and Nitage -- everything you've said so far is completely illogical. By your reasoning, if I use DirectX I'm screwed when I need to ship for PS3, which is obviously bogus. C# goes nowhere on the consoles, but it has nothing to do with Tao and everything to do with the lack of a runtime.
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
What 2 platforms does Managed DirectX support? PC and XBOX? By that logic,
Tao can support 2 then: PS3 and PC.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by daerid
What 2 platforms does Managed DirectX support? PC and XBOX? By that logic,
Tao can support 2 then: PS3 and PC.
+MAC. I'd suppose it's becoming a commercially viable platform as well.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by Promit
Quote:
As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it?
That's legitimate. [...] Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.
You'd think people would at least read the things I write. But no, instead I'm assigned the opinions people think I'm supposed to have. I never even implied C# was suitable for professional game development. No languages other than C or C++ are, and there's no indication that their momentum will run out any time soon. (What I did imply is that as far as performance goes, C# is comfortably fast enough for professional game development.)

D does have an advantage, because (as I wrote) it is reasonably feasible to get it to work on any platform that gcc supports, which is much wider than mono's. If a manufacturer has C support, it is more than likely going to be gcc, so a code generator is available for D. It is not credible for a developer to write their own JIT for mono.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Stachel
D does have an advantage, because (as I wrote) it is reasonably feasible to get it to work on any platform that gcc supports, which is much wider than mono's. If a manufacturer has C support, it is more than likely going to be gcc, so a code generator is available for D. It is not credible for a developer to write their own JIT for mono.
It isn't feasible, reasonable, or smart for a developer to port D to their target platform (or Mono, or JVM, or anything else). You're seriously underestimating the amount of work required.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by Stachel
D does have an advantage, because (as I wrote) it is reasonably feasible to get it to work on any platform that gcc supports, which is much wider than mono's. If a manufacturer has C support, it is more than likely going to be gcc, so a code generator is available for D. It is not credible for a developer to write their own JIT for mono.
It isn't feasible, reasonable, or smart for a developer to port D to their target platform (or Mono, or JVM, or anything else). You're seriously underestimating the amount of work required.


Since GDC works with the gcc toolkit, getting D to a new platform that gcc already supports is a matter of recompiling it. As I said, I'm sure there'll probably be a few tweaks and glitches in the process to take care of, but that's nothing like needing the time and expertise to write a JIT. If it isn't feasible or reasonable, then existing GDC multiplatform support would never have happened. If you want to see such in action, there's a D.gnu newsgroup on the digital mars site where the developers discuss it. As posted there, porting to 64 bit linux required a few pages of patches.

It's not that big a deal to do a port. If you still think it's on the level of complexity of porting JVM or mono, please explain why.
0

Share this post


Link to post
Share on other sites
I ported a bunch of stuff(compiler+vm) from C++ to D just for kicks. The code got a lot shorter and easier to understand. No need for header files. Templates are simpler(static if). Smart pointers are gone because of GC. Built-in variable length arrays are very convenient to use. The dmd compiler is lightning fast because there's no preprocessing and compiling of huge headers. For me D is definitely a keeper.
0

Share this post


Link to post
Share on other sites
I'd give a nut to get rid of headers in c++. They are the single biggest waste of time.
0

Share this post


Link to post
Share on other sites
personally i like headers in c++ it makes me think about what im doing before i write the code.
0

Share this post


Link to post
Share on other sites
I like headers too because they serve to separate implementation from the interface.

Look at FILE* in C, no-one knows or cares about the structure or implementation of them. One of the best examples of object orientated thinking in C.
0

Share this post


Link to post
Share on other sites
You can have them. A decent IDE could easily extract interface information out in a much cleaner format than headers provide, like C#. As I understand it though headers are required more because of how things are compiled into seperate object files before linking.
0

Share this post


Link to post
Share on other sites
Yep, I must check out C# after I have taught myself some lisp. One of my co-workers who is totally anti-MS swears by it as a good language to develop in (for tools code etc.). I had a brief look when it first came out and was interested but I've always had too much on to look deeper. It does depend on the quality of the IDE though.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradigm Shifter
Look at FILE* in C, no-one knows or cares about the structure or implementation of them. One of the best examples of object orientated thinking in C.
That has nothing to do with headers. Headers allow you to see interface but not implementation. People don't generally break open stdio.h when they are trying to remember how to use fopen.
0

Share this post


Link to post
Share on other sites
Yeah, that's my point. Headers allow you to see interface rather than implementation... I find languages like C#/Java where everything in a class is in the source more confusing than the FILE* example. No-one ever looks at stdio.h, that's a good thing (TM).

[EDIT: But they do look at the documentation... which is more important than the header files of course. But FILE* is an excellent example of object oriented stuff in C anyway... terminal i/o... files... sockets... memory mapped files... etc. all through same interface]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradigm Shifter
Yeah, that's my point. Headers allow you to see interface rather than implementation... I find languages like C#/Java where everything in a class is in the source more confusing than the FILE* example. No-one ever looks at stdio.h, that's a good thing (TM).
I still don't see how that has anything to do with headers. What you're saying only makes sense if people frequently look at stdio.h but not stdio.c (ie the compiler vendor provided backing implementation).
0

Share this post


Link to post
Share on other sites
Yep I realise my argument is flawed (I have the drunkenness!). But I'd still rather glance at a header to see the core interface and then look at the docs than wade through mountain of implementation details as in a C#/Java class file say. I like the separation between the two, personally.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradigm Shifter
Yep I realise my argument is flawed (I have the drunkenness!). But I'd still rather glance at a header to see the core interface and then look at the docs than wade through mountain of implementation details as in a C#/Java class file say. I like the separation between the two, personally.

But why would you start with looking at the header for the core interface? Why isn't that provided directly in the docs?

Even with my own code, I rely on the Code Browswer to tell me how it all works. It could be written across fifteen different files on eight different PCs and it wouldn't matter to me.

Considering the enormous problems the reliance on header files causes with C++, using them as a form of documentation is a pretty poor excuse for keeping them around longer than needed.

CM
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