Sign in to follow this  

What framework do you use?

This topic is 3870 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been trying to deciede what framework to use to write games. If you use C# it seems you can only use the .net framework which will slow things down due to converting code to Itermediate language which can work on most plateforms. In C++ you can make a Native Win32 application that doesn't use the .net Framework at all and it runs faster so that seem the way to go. I guess a third option would be Microsoft Foundation Classes. I don't believe that would be much better then .net though I don't know a whole lot about it. C# has the easiest syntax to handle because it's based solely on the .net framework and doesn't need differnt syntax. C++ requires differnt syntax due to being part of the ANSI C++, Win32 C++, MFC C++, and .NET C++. C# also uses managed directx which is easier to browse via the object browser and you don't have to worry about include/lib directories/files. Which do you guys think is the best language and framework for building games in? Thanks

Share this post


Link to post
Share on other sites
I'd say C# is a good choice. Sure, C++ can be faster if you are very careful and care to spend a lot of time making sure you're writing optimized code. The question is, what do you need the extra speed for, and are you ready to sacrifice a lot of your own time for say, a 20% increase in frames per second?

If you're an indie game developer or a hobbyist it's unlikely that you'll gain anything much by using C++, while a managed language like C# will allow you to be more productive.

I myself would use Java, since I'm comfortable with it, it's multi platform (C# won't be if you use XNA) and I can run small games in the browser etc.

On a side note, the .net bytecode will be compiled to native code before it's run via a JIT compiler. Java does something similar. The runtime overhead stems from other sources.

Share this post


Link to post
Share on other sites
Quote:
Which do you guys think is the best language and framework for building games in?


Flash.

Count the number of games written in ActionScript, and compare that to all other games. Numbers speak for themselves. It is de-facto best game making language, surpassing probably all other languages, platforms or frameworks ever made.


Quote:
C++ requires differnt syntax due to being part of the ANSI C++, Win32 C++, MFC C++, and .NET C++.


This is very wrong. There is no Win32 C++, MFC C++ or .Net C++. All of that is C++ mostly (especially since MVS2005) standard compliant C++.

All the rest is Windows Platform API. .Net includes additional libraries for higher level functionality. Syntax for all is exactly the same - C++ compliant.

The only "framework" that C++ provides is Standard C++ library.

Quote:
which will slow things down due to converting code to Itermediate language


Pointless. There's too many threads here about why this simply isn't true.

Share this post


Link to post
Share on other sites
Quote:
Original post by Chris27
I've been trying to deciede what framework to use to write games. If you use C# it seems you can only use the .net framework which will slow things down due to converting code to Itermediate language which can work on most plateforms.


actually in C# you can use binding to various Software framework written in c/c++ like directx(microsoft supported .net bindings) tao(opengl bindings) and ogre(rendering engine) that make any difference in execution speed between c# and machine code languages insignificant

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Quote:
Which do you guys think is the best language and framework for building games in?


Flash.

*snip*


Flash is slow and ActionScript is dynamically typed. That's why you mainly see small and amateurish games in it.

It's a fine animation framework, but a lousy game framework mainly useful for rapid prototyping.

In conclusion, quantity is irrelevant. Quality matters.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ahnfelt
Quote:
Original post by Antheus
Quote:
Which do you guys think is the best language and framework for building games in?


Flash.

*snip*


Flash is slow and ActionScript is dynamically typed. That's why you mainly see small and amateurish games in it.

It's a fine animation framework, but a lousy game framework mainly useful for rapid prototyping.

In conclusion, quantity is irrelevant. Quality matters.


Really?

Quote:
Which do you guys think is the best language and framework for building games in?


ActionScript is, without doubt, the best language to for building games.

It is however sub-optimal for developing cutting edge 3D games. The quality doesn't matter. Because only games that sell are those that make money. And there it doesn't matter if the game (or any product) is much inferior in quality. As long as it meets target market's demands.

I'd also like to point out that some of the biggest MMOs and virtual worlds (5+ million users) use Flash front-end.

In addition, ActionScript is a tool that anyone with no programming experience, or only limited high-level language experience (Java, C#) can pick up, and instantly produce a playable game, that is painlesly published on the internet.

As for quality - history has proven beyond a doubt, that quality does not matter. All superior products (techonology or "quality"-wise) have failed and have been superceeded by "inferior" products. Starting with operating systems, down to every single application we use today. Nobody remembers "quality" products, since those were too expensive.

The only quality that does matter is user's enjoyment. And with a very high-level framework, your developers and artists spend 98% of the time working on content, rather than 80% of the time coding, bug-fixing and platform-testing.

Get the job done

That's what matters. And getting job done means delivering the product to your customers, complete, tested and enjoyable.

Not one customer cares what the game is written in, if it's fun and accessible.

Share this post


Link to post
Share on other sites
Thanks for the input. I'm still new so sorry for being a little off regarding some things. There is a lot to learn. I think perhaps systax was the wrong word to use.

For instance in this book it says there are many differnt keywords for string in C++ and they are ugly to look at. char*, LPTSTR, string, CString, CString(WTL Version), wchar_t*, OLECHAR. This happens because of the additions to C++ over time addapting it to work with the new Additions to the language. This makes the keywords look confusing.

On the otherhand C# apparently doesn't have such difficult to look at keywords because it's new and made to work with the .net framework.

Anyway I'm going to go with C# like most of you suggest. C++ is a bit more in depth then what I'm interested in and it seems the performance gain isn't very big.

Thanks

Share this post


Link to post
Share on other sites
Your book is wrong: the majority of those are Microsoft string classes, and not synonyms for 'string' in C++.

If your book is so glaringly wrong so early, you should pitch it in the skip and buy a proper C++ book. Thinking in C++ is free and highly recommended.

Incidentally, I'd love to know which book it is, so I can add it to my giant list of terrible C++ books.

Share this post


Link to post
Share on other sites
Quote:
Original post by Chris27
For instance in this book it says there are many differnt keywords for string in C++ and they are ugly to look at. char*, LPTSTR, string, CString, CString(WTL Version), wchar_t*, OLECHAR. This happens because of the additions to C++ over time addapting it to work with the new Additions to the language. This makes the keywords look confusing.


First: Choose the language you'll be learning.
Second: Start slowly with Hello World style applications, and examples which demonstrate functions, methods, classes, and everything else.


Keyword (reserved word in some languages) is part of language. for, while are examples of keywords.

char is a primitive (basic, integral, built-in) type. Along with int, bool, long, ....

CString, (std::)string are classes. That a completely different construct altogether.

LPTSTR and wchar_t are type definitions, or aliases (I think, not sure right now).

Many of those you mentioned are Microsoft specific implementations, which are problematic for completely other reasons.

As you can see, there's a lot of completely difference concepts. With regard to those, C++ is hard. But do not go into C# thinking those are irrelevant. Each of these is like apples to oranges to anything else.

Understanding these differences belongs to syntax of the language. Make sure you learn the language first, and are clear about these concepts.

The book you're using right now is way above your level. Start small, choose *any* language you want, but choose *one* only. Do not go with C++, C, C# and something else for good measure.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Quote:
C++ requires differnt syntax due to being part of the ANSI C++, Win32 C++, MFC C++, and .NET C++.


This is very wrong. There is no Win32 C++, MFC C++ or .Net C++. All of that is C++ mostly (especially since MVS2005) standard compliant C++.


I agree with most everything else you said, but there are EXACTLY 2 C++ languages. standard C++, which nearly all CURRENT compilers get nearly correct. and C++/CLI the microsoft modified version of C++ made to support all of the .NET framework idioms. The reason you cannot call C++/CLI "standard" C++ is that it adds completely new keywords, and therefore a small but notable amount of valid C++ programs will not work in C++/CLI. Other compiler extensions are built in standards compliant ways (and if you use MSVC 2003 or 2005 in non-.Net projects there are standar C++ too).

C++ and C++/CLI are different in the same way that C# 1.1 and C# 2.0 or Java 1.2 and Java 5.0 are different ... they have additional language constructs and minor changes.

Share this post


Link to post
Share on other sites
I think your right that I'm trying to understand concepts that are above my head right now. I think I'll just go with C# and start from the begging. I actually know a lot of the basic ANSI C++. It's when I get to the Windows programming portion C++ that it gets confusing. I can see these were all additions by Microsoft, but how can you program a Windows application if you don't use the tools provided by Microsoft? Most examples of directx use some form of framework weather it be a Windows form or objects defined in the Windows.h file.

The book is Proffesional C# 3rd edition. This paragraph is in the very begging.

C++, on the other hand, has it's roots in the ANSI C++ language definition. IT isn't completely ANSI-compliant for the simple reason that Microsoft first wrote it's C++ compiler before the ANSI definition had become official, but it comes close. Unfortunatly, this has led to two problems. First, ANSI C++ has it's roots in a decade-old state of technology, and this shows up in a lack of support for modern concepts (such as Unicode strings and generation XML documentation), and in some archaic syntax structures desined for compilers of yesteryear(such as the sparation of declaration from the definition of member functions). Second, Microsoft has been simultaneously trying to evolve C++ into a language that is designed for high performance tasks on Windows, and in order to acheive that they've been forced add a huge number of Microsoft specific keywords as well as various libraries to the language. The result is that on Windows, the language has become a complete mess. Just ask C+++ developers how many definitions for a string they can think of: char*, LPTSTR, string, CString,(MFC version), CString(WTL version), wchar_t*, OLECHAR*, and so on.

There it is.

Perhaps you guys can explain how you would make a Windows application. C# uses Windows Forms. C++ can use Windows Forms, MFC, and also the Windows.h file for a native win32 application. I'm a little fuzzy on these issues. Perhaps you can explain what each is and how you would go about making a window for a game application. Most examples I see use the windows.h file and the objects contained within it.

Share this post


Link to post
Share on other sites
I'm originally a C++ developer, and still love it to this day. But my day-job is not game programming, and it uses C# - which is also great. For hobby programming and game stuff I used to do all C++ and ruby, but now I do C#, C++ and ruby ... in that order. They all rock and they all suck (all current languages and enviroments suck when you dig into the dark corners - either they lack easy support for something, they make you repeat yourself too much, they hide logic in the syntax, they are too verbose, or they want things to be done the one-true way ...).

But don't hesitate to use C++, C#, Java, Python, Ruby, Flash, Dark Basic, Blitz Basic, or whatever. They are all great. These choices above are time and community tested to be completely capably of doing really good programs, and great games too (on the hobbyist scale). Many other choices have come and gone, but today, these are your best bets (maybe if your really academic, you could use LISP too).

Personally I wish ruby would get its act together and get the VM and libraries caught up to Python. I also wish Java would close the gap back to C# / .Net. But until that happens I feel Python is the best dynamic gamming platform of newbies. C# the best old-school/new-school balance, and C++ the best big-iron for those critical sections that just need human mind control (getting more and more rare, but probably never to be completely eradicated).

Share this post


Link to post
Share on other sites
Quote:
Just ask C+++ developers how many definitions for a string they can think of: char*, LPTSTR, string, CString,(MFC version), CString(WTL version), wchar_t*, OLECHAR*, and so on.


Wrong. You'll use two at most - it just depends on the needs of the application. And unless you're working with a really horrible team, the use of special ones will be limited and well contained withing separate API that will bridge between the API differences.

Quote:

Perhaps you guys can explain how you would make a Windows application. C# uses Windows Forms. C++ can use Windows Forms, MFC, and also the Windows.h file for a native win32 application. I'm a little fuzzy on these issues. Perhaps you can explain what each is and how you would go about making a window for a game application. Most examples I see use the windows.h file and the objects contained within it.


Really, you need to step back, and go with the simplest possible aproach.

You said C#. Create an application that will show a window.

Then add a button that, when clicked, will display a message box saying Hello World.

and so on...

Right now you are making a huge mess of random topics which are irrelevant for your particular case. Windows.h is the header that includes windows specific defines. It contains no objects, since Windows API isn't object oriented, and APIs do not instantiate classes.

http://www.softsteel.co.uk/tutorials/cSharp/cIndex.html
This is a tutorial which will explain all the fundamentals of the language. Once you're comfortable with those, then start thinking about moving on.

In order to create a single window, you need to understand everything before, including classes, instances, methods, function calls, headers, etc.

Share this post


Link to post
Share on other sites
I've been able to get a basic directx application working in C++ with unmagaged code and I also was able to get one working with managed code in C#. I was able to add the paths to the SDKs needed as well as the Refferences needed in C#.

Here is the basic Window for a Win32 application that I followed through a tutorial.

//////////////////////////////////////////////////////
// BasicWindowsApp.cpp
//////////////////////////////////////////////////////

#include <windows.h> //Required for Win32 applications

// Function prototypes.
LRESULT WINAPI WndProc(HWND hWnd, UINT msg,
WPARAM wParam, LPARAM lParam);
void RegisterWindowClass(HINSTANCE hInstance);
void CreateAppWindow(HINSTANCE hInstance);
WPARAM StartMessageLoop();

// Global variables.
HWND g_hWnd;


//////////////////////////////////////////////////////
// WinMain()
//////////////////////////////////////////////////////
INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, INT)
{
RegisterWindowClass(hInstance);
CreateAppWindow(hInstance);
ShowWindow(g_hWnd, SW_SHOWDEFAULT);
UpdateWindow(g_hWnd);
INT result = StartMessageLoop();
return result;
}

//////////////////////////////////////////////////////
// WndProc()
//////////////////////////////////////////////////////
LRESULT WINAPI WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return 0;

case WM_DESTROY:
PostQuitMessage( 0 );
return 0;

case WM_PAINT:
ValidateRect(g_hWnd, NULL);
return 0;
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}

//////////////////////////////////////////////////////
// RegisterWindowClass()
//////////////////////////////////////////////////////
void RegisterWindowClass(HINSTANCE hInstance)
{
WNDCLASSEX wc;
wc.cbSize = sizeof(WNDCLASSEX);
wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = (HCURSOR)LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName = "WinApp";
wc.hIconSm = NULL;

RegisterClassEx(&wc);
}

//////////////////////////////////////////////////////
// CreateAppWindow()
//////////////////////////////////////////////////////
void CreateAppWindow(HINSTANCE hInstance)
{
g_hWnd = CreateWindowEx(
NULL,
"WinApp",
"Basic Windows Application",
WS_OVERLAPPEDWINDOW,
100,
100,
648,
514,
GetDesktopWindow(),
NULL,
hInstance,
NULL);
}

//////////////////////////////////////////////////////
// StartMessageLoop()
//////////////////////////////////////////////////////
WPARAM StartMessageLoop()
{
MSG msg;
while(1)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
// Use idle time here.
}
}
return msg.wParam;
}

I've also used Windows Forms to make a Managed DirectX Device with a blue backround.

I don't understand all the concepts and terminology, but I know enough to get some things up and running to and extent. I was just curious what is the best way to do it. There are so many ways to make a Window. I will go back and read up more on the subjects you mentioned.

Share this post


Link to post
Share on other sites
that's not the most beautiful win32 hello world app i've ever seen, but i guess it will do. for a dx app, you really don't need a white background brush, nor the CS_HREDRAW | CS_VREDRAW | CS_OWNDC styles, and what happens if RegisterClass fails? there is a lack of error checking in your code. if something can go wrong, it usually will go wrong he he he. i also prefer to use PM_NOREMOVE and then use GetMessage to get the message if PeekMessage indicates there is one.

as for frameworks, i use Win32/64, MFC, and C#/FCL. still wondering if i should start using Qt or not though... there are a lot of jobs out there for Qt now (a job recently passed me by because i didn't know Qt).

Share this post


Link to post
Share on other sites
I don't really know a whole lot about Windows programming. As I said I just went through some tutorials on making DirectX applications and this is one of the ones that showed a basic Windows Application for use with DirectX. I have yet to see a book that goes into detail on this concept of creating a Window or how it works. I guess it communicates directly with the Windows API to create a Window. I am assuming Windows Forms works the same way, but is more complex as it writes most of the code for you and therefore takes longer to compile? Windows Forms seems the easiest way to do things by far and it's the only way I've seen to write a Windows application with C#. It's very difficult to find information regarding regarding the premade code for Windows and how to use it to. At least thats been my exprience so far.

Share this post


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

Really?

Quote:
Which do you guys think is the best language and framework for building games in?


ActionScript is, without doubt, the best language to for building games.

*snip*

The only quality that does matter is user's enjoyment. And with a very high-level framework, your developers and artists spend 98% of the time working on content, rather than 80% of the time coding, bug-fixing and platform-testing.

Get the job done

That's what matters. And getting job done means delivering the product to your customers, complete, tested and enjoyable.

Not one customer cares what the game is written in, if it's fun and accessible.


You're right that technology isn't that important. In my mind a quality game is a highly enjoyable game. After all, the purpose of games is to entertain.

In any case, since there are MMORPG with 5M+ users, would you care to give an example? (remember, Shockwave is not Flash, and even if it was, that probably wouldn't be 5M paying users)

I'll give you an example of a high quality game (in terms of polishing, entertainment and replayability, not in terms of technology or innovation) that has more than 8M paying customers. World of Warcraft.

While talking about Blizzard, they have made numerous games with a high degree of polishing - quality games. And I dare say that they make a lot more money than any studio using Flash for their games.

I happen to think that ActionScript will make you spend a lot more time coding for non-trivial games, since it's got so little static support. You'll produce a lot of bugs in such a language, and they'll be harder to find.

I agree with you on one point though: use whatever gets the job done. If you want to make small online games or animations, Flash is usable. If you want to make anything else, it'll probably just in your way.

Share this post


Link to post
Share on other sites
Sign in to follow this