• Announcements

Archived

This topic is now archived and is closed to further replies.

Recommended Posts

Most programs and nearly all professional games are written in C++, now. But I was thinking about something... Why would you write the _tools_ for making that game or program in C++? Why? It would take longer than necessary and bugs would be abundant because of the rush to get it finished, right? C++ is a very good language, but wouldn't you agree that it's not the language of choice for quick, necessary production tools, like level editors? Who writes their tools in other languages to get them working, and get them working correctly? What language do you use? Edited by - Some Guy on January 31, 2002 11:00:54 PM

Share on other sites
You wouldn't necsessarily. For example, previous versions of UnrealEd were written in VB. Personally, I think VB is great for that sort of thing. When I need to write a tool, I normally use Java, VB, or C++.

Edit: Grammar ...

Edited by - Martee on January 31, 2002 11:05:21 PM

Share on other sites
Most of my tools are command line anyway (really easy in C/C++). The power of piping is nice . To turn a TGA into a bitmapped font with my tools:
gtwtarga < image.tga | gtwfont > font.gbf

That way my font tool only has to support one format (GIM) and the image tools can take care of convert things to that one format. For more complex and highlevel things like map editors (which aren''t written yet for this engine since the map format isn''t finalized) I''ve written a very nice OO GUI system to simplify using C++ for tools. And since I wrote the GUI it''s that much easier to use it myself .

Share on other sites
My uncle uses VB for his job. Says it''s very good, but I''ve never used it. The only BASIC I every used was DarkBASIC. Long time ago.

C# could be used as well, I think. I was also considering scripting languages like Python or Ruby. There''s also Delphi and Pascal.

--Some Guy

Ireland. Iceland. Ireland. Iceland.

Greenland. Scotland. Greenland. Scotland.

Germany... huh

Share on other sites
Well, for someone who programs "fluently" in C++, why not use C++. Personally, I prefer VB for everything, so I write both my tools and my games in it. But, the UnrealED was VB while the game was C++. I think that they would have been better off to just use C++ for UnrealED just because from what I heard it was more trouble than it was worth (the programmers didn''t have much experience in VB and thought it would just be a simple matter to learn the language as they coded, which would have stuffed up performance I bet). If however they had a person who was skilled in VB, then they might be able to make a fully functional program much quicker with less bugs than a C++ version which would have been beneficial (note I said "might", I bet there are heaps more highly skilled C++ists than there are highly skilled VBists.. So the moral is, use what is comfortable, and don''t change just for the sake of changing.

Trying is the first step towards failure.

Share on other sites
Well I wouldn''t want to write a complex GUI with straight WIN32 code, MFC isn''t that bad. It''s fast, and if you get proficient, it''s not time consuming either.

Visual Basic? I''m not really experienced with it, but I do like it. Unfortunately most of my tools end up being supported by C++ base code, so the bother of adding the C++ into a DLL and interfacing to it through VB isn''t worth it. Other then that, I sometimes find Basic restrictive in the OO sense.

Java. A promise that well... never made it in my mind. (Although I think Applets are great. Almost under used in some ways.) Of course I only have experience with 1.2 of the SDK and from what I''ve heard version 1.4 (1.4 right?) is supposed to have turned up the heat.

Of course, all opinions expressed here are open to support and criticism :-)

If all that matters is what you get in the end, why go through life?
~Michael Sikora

Share on other sites
quote:

Visual Basic? I'm not really experienced with it, but I do like it. Unfortunately most of my tools end up being supported by C++ base code, so the bother of adding the C++ into a DLL and interfacing to it through VB isn't worth it.

That's the rub. Ideally, you want your editor using as much of the same codebase as your game, that way when a file format changes (for instance), it happens in the game and in the tools. It really blows to have a file loading function written in two different languages that has to be maintained. And the wrapping code that you have to do to make VB use your C++ is a pain.
Now, if you're shooting for a Win32 only game, I could see the game engine being developed as a series of stand-alone COM libraries or something, which VB would handle better.

One of the things that I'm exploring now is using .Net for tool development. You could write the editing tools in C# (or VB) with all the nice GUI stuff, and include your C++ as unmanaged code. Seems like the best of both worlds, if it works right.

Take care,
Bill

Edited by - Siebharinn on February 1, 2002 9:28:05 AM

Share on other sites
At the moment i''m making a game in Delphi, and the main map editor for it is written using Delphi aswell, because i''m reusing the engine code, i was going to put the entire engine in a DLL and code the editor using Visual Basic, but thought it to be more trouble than it be worth. Although, saying that, the other editors for the game are written using VB, such as the game data files. I''ve been programming in VB for about 3 years, and Delphi for 2, so i''ve got a firm grasp on both. It makes sense to make the editors as small and as unfancy(real word? ), as possible, but still adding error checking and multiple undo levels etcetc, as it''ll make your job much easier. As for command line tools, they are the bomb!, as for converting file formats just slap the commands in a batch file and hey presto!

DarkStar

Share on other sites
quote:
Original post by Some Guy
Most programs and nearly all professional games are written in C++, now. But I was thinking about something...

Why would you write the _tools_ for making that game or program in C++? Why? It would take longer than necessary and bugs would be abundant because of the rush to get it finished, right?

Because most of the time, game companies have 1 or 2 TOOL coders and yes, most of the tools for professionnal games are made in C/C++... Now, with that said, I also don''t use C/C++ for tools, I use Delphi 6.0...

"And that''s the bottom line cause I said so!"

Cyberdrek

Resist Windows XP''s Invasive Production Activation Technology!

"gitty up" -- Kramer
/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com
Hash Bang Slash bin Slash Bash -- #!/bin/bash

Share on other sites
quote:
Original post by Some Guy
C++ is a very good language, but wouldn''t you agree that it''s not the language of choice for quick, necessary production tools, like level editors?

Let''s assume most level editors are windowed programs (e.g. not full-screen, look like your standard windows apps). I guarantee that an editor written using Win32 took longer to develop than one using MFC (Microsofts C++ wrappers for Win32).

For me, C++ is the easiest language for programming, almost regardless of the circumstance. When forced to use C (which I sometimes am), I find myself fighting against the limitations of the language. The only time I''ve ever "fallen back" on C is when I was under the gun to do some very tricky file manipulation, and chose to use the fopen/fread/fwrite/fseek commands instead of the stream library; I should note that even then, I wrapped all of these functions in inline calls that would throw exceptions on error conditions rather than having to check their return values each call.

Share on other sites
quote:
--------------------------------------------------------------------------------

Visual Basic? I''m not really experienced with it, but I do like it. Unfortunately most of my tools end up being supported by C++ base code, so the bother of adding the C++ into a DLL and interfacing to it through VB isn''t worth it.

--------------------------------------------------------------------------------

I agree. For example, I did my last internship in that big imaging software cie, where everything was done in C++. I was doing tools in MFC for the expert math. developpers. Clients really liked one of my tool''s feature, so they asked me to port it in the to-be-released product. Took me like 5 minutes to convert it from MFC to pure Win32.

Share on other sites
VB lacks pointers. I don''t know how to code without them!!

Share on other sites
I''ve written tools for my own work and for commercial products, and I have to say using C++ with MFC has been the fastest. When possible, I always share code base between the tool and the target application that will use whatever the tool is generating.

Be it command line or windowed, C++ is always my choice. I''ve worked with VB, but have always had a hard time once the tool gets just that little bit more sophisticated than VB can easily handle.

MFC tools might be hard to start up, but they never reach a point (in my mind) where you are asking yourself "How the heck am I going to do this?". VB tools are easier to start working on, but I''ve always got to a point where I say "I better make a C++ DLL I can call to handle all this tough stuff".

Share on other sites
I''ve written a 3d Leveleditor using C++ / MFC / OpenGL.. I''m rewriting it completley from scratch and again I use C++.

1.) It''s the language I know best
2.) It''s performance is a dream (I''ll do some raytracing inside the Leveleditor for lighting calculations. no, I don''t wanna miss out on Assembler optimisations :o)
3.) MFC is written in C++ and I think it''d be kinda complicated to do exactly the thing you want to do. (I can''t really tell, cause I''ve never really used VB)
4.) I want to avoid missing runtime libaries for VB. (ok, I need the MFC42.dll, but that should be standard nowadays, whereas I don''t think I''ve got the newest VB runtime dlls on my system.

Ok, guess that''s it :o)
cya,
Phil

Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states )

Share on other sites
Borland C++ Builder for 90% of my tools. Gives me most of the benefits of Visual Basic without most of the drawbacks.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share on other sites
MFC and COM do not work on Linux and other platforms besides Windows. Are there wrappers or something for *nix system development?

--Some Guy

Share on other sites
quote:
Original post by Anonymous Poster
MFC and COM do not work on Linux and other platforms besides Windows. Are there wrappers or something for *nix system development?

Wrappers of MFC and COM? Not really (the only things that do exist are nothing like wrappers). Wrappers of their functionality? Yes. Look at wxWindows, Qt, VGUI, et cetera.

Share on other sites
I disagree. If you can use C/C++ efficiently, then it won''t take ver long at all to write any tool.

It depends on the programmer, not the programming language.

Besides, Borland C++ Builder is similar in a way to VB, and it is much more flexible, and since you have more control over the program it is quicker for data manipulation/programming - ie what most game tools are.

Beer - the love catalyst
good ol'' homepage

Share on other sites
quote:
VB lacks pointers. I don''t know how to code without them!!
AH! no, you can''t not have pointers, I would die!

Share on other sites
I use C++ Builder as well. I tried MFC, but I just couldn''t get into it. When I''m making an editor or something I just want things as simple as possible.

Share on other sites
It is possible to aquire pointers in VB with a few functions from Win32 API. Its not near as easy as getting pointers in C++ though.

Share on other sites
Getting the pointers isn''t the problem. Using them is.

quote:

Why would you write the _tools_ for making that game or program in C++? Why? It would take longer than necessary and bugs would be abundant because of the rush to get it finished, right?

That depends on your architecture, which is limited by the implementation language.

Share on other sites
quote:
Original post by Null and Void
Wrappers of MFC and COM? Not really (the only things that do exist are nothing like wrappers). Wrappers of their functionality? Yes. Look at wxWindows, Qt, VGUI, et cetera.

That''s what I meant. I didn''t mean wrappers of MFC and COM (don''t see the point in it ). But there is a C++ HOWTO on "beautifying" C++ and making it look more like Java. Came w/ my copy of Mandrake Linux.

And I now agree. It depends on the design and architecture, and that should depend on the skill/weakness of the programmer. C++ is very flexible, and there''s seemingly always a way to cheat and cut corners.

• Partner Spotlight

• Forum Statistics

• Total Topics
627662
• Total Posts
2978519

• 10
• 10
• 12
• 22
• 13