Thread: RE: [GD-General] dev environments
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Brian H. <bri...@py...> - 2001-12-20 19:05:19
|
> 1) what are specific examples of great dev environment > features (could be great features in otherwise ordinary environments)? I haven't found a great dev environment yet, but I can point out specific features that pull things together. 1. InterfaceBuilder/Cocoa/Obj-C The way these three components work together is amazing. It makes AppWizard and MFC look like a grade schoolers attempt at building the Space Shuttle. You see the shape and the intent, but it's obviously not going to work. This is how good Obj-C/Cocoa are for building tools -- if I was starting a game company (that had funding, heh), I would give all the developers a PowerMac, simply because it would be more cost effective developing tools on OS X than it would be trying to leverage existing PCs and forcing reluctant toolsmiths to use MFC/Win32/C++. Yes, it's THAT good. I can't really explain too much about how this works, a tutorial would be better. I highly recommend the free tutorials and PDFs at developer.apple.com that deal with Cocoa. The whole NextStep architecture was just way, way ahead of its time when it came to custom apps. In fact, the existence proofs -- the fact that so many high quality vertical market apps were built with NS -- are pretty strong evidence that more productive tools and environments WILL be adopted irrespective of costs. And NS was not cheap. 2. The browsing facility in MSDEV Booo, hsssss! MSDEV sucks! Yeah yeah, but for some reason I still get work done in it, go figure =) When they added auto-completion for members when typing "." or "->" on a member -- wow, how helpful is THAT? Or being able to click on something and say "Show me your definition". This could be taken much farther than it has though. Searching based not on text, but context, would be great (which would remove my complaint about function overloading -- do a search for "open" and you'll get a zillion hits, when all you want is "where do I call open on a HFile object?"). Being able to query for things like the (contrived) following: - "Show me all instances of class XYZ, but NOT its derivatives" - "Show me all instances of class XYZ or its derivatives" - "Show me anywhere I call this method for this object type, but not its children" - "Show me all functions that are overridden but don't call their parent implementation" - "Show me all objects that are derived using MI" - "Show me all abstract classes" - "Show me what functions I need to implement to make this class concrete from its abstract parent" > 2) what are specific examples of dev environments that "put > it all together" and boost productivity? I haven't found one yet, which is how this all got started =) My nearest guess would be SmallTalk, but I only know about it from reputation. Brian |
|
From: Brian H. <bri...@py...> - 2001-12-20 19:29:10
|
A-ha. Someone sent me a link to www.wholetomato.com and their Visual Assist program. This is the kind of thing I'm talking about! That's definitely a step in the right direction. I'll have to give it a whirl. Brian |
|
From: Zach B. <za...@za...> - 2001-12-21 19:29:56
|
Brian Hook wrote: > A-ha. Someone sent me a link to www.wholetomato.com and their Visual > Assist program. This is the kind of thing I'm talking about! That's > definitely a step in the right direction. I'll have to give it a whirl. I'm quite happy with it myself. It crashed and ate up resources until a recent version (September, I think?) but it was still worth using. I'm working on a PS2 game and use Developer Studio with Visual Assist. There are ways to shoehorn foreign code into Developer Studio's slow and error-prone browsing database, but I get by fine with VA and the occasional recursive grep. Any system like this (syntax highlighting, completion, parameter info, etc.) is only as good as its parser, and VA's parser seems to handle my code very well and updates itself in the background whenever I save a project file. The prime virtue of this kind of setup is that I rarely have to switch buffers/modes/whatever to look at declarations and can just concentrate on a single file. --- Zach Baker <za...@za...> "As a rule, I never touch anything more sophisticated and delicate than myself." |
|
From: Warrick B. <War...@po...> - 2001-12-20 19:34:51
|
Yeh it's quite good and takes off from where Visual Studio leaves off but it annoyingly crashes quite often.... -----Original Message----- From: Brian Hook [mailto:bri...@py...] Sent: 20 December 2001 19:30 To: gam...@li... Subject: RE: [GD-General] dev environments A-ha. Someone sent me a link to www.wholetomato.com and their Visual Assist program. This is the kind of thing I'm talking about! That's definitely a step in the right direction. I'll have to give it a whirl. Brian _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
|
From: Daniel V. <vo...@ep...> - 2001-12-21 23:50:29
|
Most people here use Visual Assist and I haven't heard of anyone reporting crashs so far. While we are mentioning great tools: Araxis Merge is the best tool for merges I've seen so far. -- Daniel, Epic Games Inc. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Warrick Buchanan > Sent: Thursday, December 20, 2001 2:35 PM > To: gam...@li... > Subject: RE: [GD-General] dev environments > > > Yeh it's quite good and takes off from where Visual Studio leaves > off but it > annoyingly crashes quite often.... > > -----Original Message----- > From: Brian Hook [mailto:bri...@py...] > Sent: 20 December 2001 19:30 > To: gam...@li... > Subject: RE: [GD-General] dev environments > > > A-ha. Someone sent me a link to www.wholetomato.com and their Visual > Assist program. This is the kind of thing I'm talking about! That's > definitely a step in the right direction. I'll have to give it a whirl. > > Brian > > > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > |
|
From: Brian H. <bri...@py...> - 2001-12-22 17:20:13
|
At 06:49 PM 12/21/2001 -0500, Daniel Vogel wrote: >Most people here use Visual Assist and I haven't heard of anyone reporting >crashs so far. While we are mentioning great tools: Araxis Merge is the best >tool for merges I've seen so far. Not to go on and on about NextStep, but for years its FileMerge program was the best you could find, period. When working on Quake 2 and Quake 3 we had a dedicated OpenStep box whose job was ONLY merging files. Brian |
|
From: Brian H. <bri...@py...> - 2001-12-21 23:42:49
|
> Even when you take into consideration that everyone would > need Macs to use the tools and PCs (or PS2 etc.) to run the game? Well, ideally the game is written in a cross platform fashion so you could run it on Mac or PC. Even so, obviously the ROI depends on the number of team members. With a 100 person team, then the cost of Macs per person might be larger than the incremental cost of suffering through C++ and MFC. With a 10 person team, the Macs gotta be cheaper. > Personally, I'd rather build the tools into the game using a > GUI library. It saves all that messing around with stand > alone tools :) This is fine, when it works, but there are many types of tools where it just doesn't fit within the game. Tools that need lots of forms entry, database manipulation, large surface area (e.g. multiple monitors, lots of open windows, 1600x1024 resolution, etc.). Brian |
|
From: Philip H. <ph...@me...> - 2001-12-23 10:05:37
|
> Well, ideally the game is written in a cross platform fashion > so you could run it on Mac or PC. Even so, obviously the ROI > depends on the number of team members. With a 100 person > team, then the cost of Macs per person might be larger than > the incremental cost of suffering through C++ and MFC. With > a 10 person team, the Macs gotta be cheaper. Does working on the Mac solve all the C++/MFC problems then? Or just interface building issues? > > Personally, I'd rather build the tools into the game using a > > GUI library. It saves all that messing around with stand > > alone tools :) > > This is fine, when it works, but there are many types of > tools where it just doesn't fit within the game. Similarly there's many types of game where it's inefficient to run cross platform on the Mac. > Tools that > need lots of forms entry, database manipulation, large > surface area (e.g. multiple monitors, lots of open windows, > 1600x1024 resolution, etc.). That depends entirely on your GUI library, if the desktop can give you lots of windows or high resolution then what's to stop the game doing the same? Several of those examples you mentioned I wouldn't build a standalone app for anyway, a straightforward spreadsheet can sometimes be far more efficient than a custom tool, no matter how easy it was to write the tool. Don't get me wrong, I've not used the system you're proposing so I'm not saying you can't be right :) Given that we're considering porting a couple of titles to the Mac I may have the opportunity to try out your suggestions in the future. Phil |
|
From: Brian H. <bri...@py...> - 2001-12-23 21:04:21
|
At 10:10 AM 12/23/2001 +0000, Philip Harris wrote: >Does working on the Mac solve all the C++/MFC problems then? Or just >interface building issues? Mostly interface building and maintenance issues (once you build the interface, you can change it later trivially as long as you adhere to the MVC paradigm...I never found AppWizard to be nearly as good in that respect. It always felt that once I built the skeleton code, editing it later was just not tenable.). But using Obj-C is definitely a big part of the plus. >Similarly there's many types of game where it's inefficient to run cross >platform on the Mac. Er, maybe console games, but architecturally speaking the Mac is just a PC with a different processor (at least in the case of OS X -- MacOS has its own set of annoying issues, but that still shouldn't make x-plat that more difficult). So porting between the two should be trivial, given code that is reasonably portable to begin with. If you're hardcoding calls to Win32 or DSound, well, yeah, you're asking for trouble. >That depends entirely on your GUI library, if the desktop can give you >lots of windows or high resolution then what's to stop the game doing >the same? Most games create a single window and operate within it. Windows specifically is architected around the MDI paradigm so writing multi-window apps that don't exist inside a parent workspace is not commonly done (obviously it CAN be done, but most sample code and docs don't go out of their way to illustrate this). Brian |
|
From: Patrick M D. <pa...@wa...> - 2001-12-23 22:13:31
|
On Sun, 23 Dec 2001, Brian Hook wrote: > So porting between the two should be trivial, given code that is reasonably > portable to begin with. If you're hardcoding calls to Win32 or DSound, > well, yeah, you're asking for trouble. For the most part, the code can be factored around such calls or even a wrapper around the Mac OS can be built. The biggest offender I've seen is DirectPlay. While some innovate hackers have built a compatible implementation of DirectPlay, it doesn't take much effort from Microsoft to break that work. If you care about portability, implement TCP/IP support using WinSock. Patrick |
|
From: Philip H. <ph...@me...> - 2001-12-24 11:10:50
|
> Mostly interface building and maintenance issues (once you build the > interface, you can change it later trivially as long as you > adhere to the > MVC paradigm...I never found AppWizard to be nearly as good in that In that case it probably wouldn't benefit me as much as it does you. I don't find MFC gets in the way, building and maintaining the GUI for the tools is a relatively small part of tool development for me. > >Similarly there's many types of game where it's inefficient to run > >cross platform on the Mac. > > Er, maybe console games, Exactly, I didn't phrase that very well, sorry. > >That depends entirely on your GUI library, if the desktop > can give you > >lots of windows or high resolution then what's to stop the > game doing > >the same? > > Most games create a single window and operate within it. Windows > specifically is architected around the MDI paradigm so > writing multi-window > apps that don't exist inside a parent workspace is not commonly done > (obviously it CAN be done, but most sample code and docs > don't go out of > their way to illustrate this). Windows has been moving away from MDI for some time (Word defaults to non-MDI mode for example) and there is a lot of support but as you say it's not publicised very well. I suspect Windows users are used to MDI so want to stick to it. Phil |
|
From: Patrick M D. <pa...@wa...> - 2001-12-23 22:02:16
|
On Sun, 23 Dec 2001, Philip Harris wrote: > > > Personally, I'd rather build the tools into the game using a > > > GUI library. It saves all that messing around with stand > > > alone tools :) > > > > This is fine, when it works, but there are many types of > > tools where it just doesn't fit within the game. > > Similarly there's many types of game where it's inefficient to run cross > platform on the Mac. Having done quite a bit of cross development work for Mac/Windows, what types of games do you think are not appropriate on the Mac? I'm not disputing the claim - just curious about your opinions. > Several of those examples you mentioned I wouldn't build a standalone > app for anyway, a straightforward spreadsheet can sometimes be far more > efficient than a custom tool, no matter how easy it was to write the > tool. Absolutely - one really nice tool I used in the past was Resourcerer. It provided an environment for editing data structures that only required a simple definition of how that structure should be represented on disk. That, combined with a spreadsheet for raw data, provided almost all the tooling we needed for game development. > Given that we're considering porting a couple of titles to the Mac I may > have the opportunity to try out your suggestions in the future. Will this be OS X only or will you support older versions of the OS? Many modern games do not port well to older Mac OS versions. This is especially true for games that rely on virtual memory and file i/o performance. Patrick |
|
From: Philip H. <ph...@me...> - 2001-12-24 11:20:02
|
> > Similarly there's many types of game where it's inefficient to run > > cross platform on the Mac. > > Having done quite a bit of cross development work for > Mac/Windows, what types of games do you think are not > appropriate on the Mac? I'm not disputing the claim - just > curious about your opinions. I didn't phrase that very well, specifically I mean most console games. > Absolutely - one really nice tool I used in the past was > Resourcerer. It provided an environment for editing data > structures that only required a simple definition of how that > structure should be represented on disk. That, combined with > a spreadsheet for raw data, provided almost all the tooling > we needed for game development. Sounds interesting, was this a Mac tool? > > Given that we're considering porting a couple of titles to > the Mac I > > may have the opportunity to try out your suggestions in the future. > > Will this be OS X only or will you support older versions of > the OS? Many modern games do not port well to older Mac OS > versions. This is especially true for games that rely on > virtual memory and file i/o performance. It will be modern Macs only although I couldn't tell you exactly which ones yet :) Phil |
|
From: Philip H. <ph...@me...> - 2001-12-21 23:32:15
|
> a game company (that had funding, heh), I would give all the > developers a PowerMac, simply because it would be more cost > effective developing tools on OS X than it would be trying to > leverage existing PCs and forcing reluctant toolsmiths to use > MFC/Win32/C++. Yes, it's THAT good. Even when you take into consideration that everyone would need Macs to use the tools and PCs (or PS2 etc.) to run the game? Personally, I'd rather build the tools into the game using a GUI library. It saves all that messing around with stand alone tools :) Phil |
|
From: Tom N. <t.n...@vr...> - 2001-12-21 11:15:57
|
Hi,
I find Borland's Delphi IDE to be pretty hard to beat. It has a very
elaborate class library behind it, including a comprehensive GUI
construction toolkit. You hardly ever need to mess with the Win32 API,
there's no need for MFC or ActiveX controls or whatever, and the
graphical GUI editing works great. It's like Visual Basic, only without
the disadvantages :-)
The Object Pascal language behind Delphi is, in my modest opinion, also
a step up from C++. Coincidentally, I believe it originated on the Mac
-- is there a pattern emerging here? I don't know if Apple still uses it
today, though. Perhaps it got replaced by Obj-C?
Finally, there's also a Linux version available ("Kylix"). I have no
personal experience with this, but I've had reports from people who
compiled the OpenGL demos from my website on Linux, without significant
problems.
> When they added
> auto-completion for members when typing "." or "->" on a
> member -- wow, how helpful is THAT? Or being able to click on
> something and say "Show me your definition".
Yeah, except "Show me your definition" only works _after_ you've
compiled the project with browse info. If you wipe out your "Debug" and
"Release" directories, your browsing abilities are gone. Delphi allows
you to browse your code at _all_ times, compiled or not, and even if you
_would_ have to compile it, it'd take about two seconds to do a complete
rebuild of your entire project, as opposed to several minutes if you
were using VC++.
Oh, and did I mention that you can get Delphi for free? :-)
-- Tom
|
|
From: Daniel V. <vo...@ep...> - 2001-12-22 07:12:05
|
> Yeah, except "Show me your definition" only works _after_ you've > compiled the project with browse info. If you wipe out your "Debug" and This restriction doesn't apply if you use Visual Assist. As Brian already mentioned Visual Assist is THE MSVC addon you want to get. Not only does it allow "goto definition" without any hassle but also has very clever general autocomplete functionality and working (as opposed to basic MSVC where you have to wait forever after entering . or ->) member completion. It also shows you the function declaration of the function you're currently trying to call, expands macros if you move the mouse over them and shows you the scope you're currently in. Oh, and it allows better syntax highlighting and gobs of other useful features I forgot to mention. Visual Assist, cygwin, putty and Araxis Merge are my favourite productivity enhancers besides sleep ;) -- Daniel, Epic Games Inc. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X