Thread: [GD-General] Online collaboration site?
Brought to you by:
vexxed72
From: Jason B. <bay...@ho...> - 2003-03-28 21:23:59
|
<html><div style='background-color:'><DIV> <P>I'm working on a little game with a few other people who are not in my town, and I'm wondering if there are any web sites that would assist in remote artist/developer collaboration, and storage of game assets.</P> <P>I'm thinking it would need to have remote storage (hard drive space), some sort of rudimentary source control system, and document tracking features. Basically, a central point that would serve as a hub to store design docs, code files, art assests, schedules, etc.</P> <P>It seems like there's got to be something out there, but I haven't had any luck finding it after quite a bit of searching. Any ideas?<BR><BR>- Jason Bay<BR></P></DIV></div><br clear=all><hr>The new <a href="http://g.msn.com/8HMVENUS/2737">MSN 8:</a> smart spam protection and 2 months FREE* </html> |
From: Jeremy N. <jj...@kr...> - 2003-03-28 22:09:35
|
We use a mixture of CVS and a Wiki for collaboration, in addition to IM clients and a MUX we chat on. Works pretty well, and easily hosted off a cable modem or dsl line, though we've just moved to a server from johncompanies.com On Fri, 28 Mar 2003, Jason Bay wrote: > > I'm working on a little game with a few other people who are not in my > town, and I'm wondering if there are any web sites that would assist in > remote artist/developer collaboration, and storage of game assets. > > I'm thinking it would need to have remote storage (hard drive space), > some sort of rudimentary source control system, and document tracking > features. Basically, a central point that would serve as a hub to > store design docs, code files, art assests, schedules, etc. > > It seems like there's got to be something out there, but I haven't had > any luck finding it after quite a bit of searching. Any ideas? > > - Jason Bay > > > ________________________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > ------------------------------------------------------- This SF.net email > is sponsored by: The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ Gamedevlists-general > mailing list Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
From: Thatcher U. <tu...@tu...> - 2003-03-28 22:14:04
|
On Fri, 28 Mar 2003, Jason Bay wrote: > > I'm working on a little game with a few other people who are not in > my town, and I'm wondering if there are any web sites that would > assist in remote artist/developer collaboration, and storage of game > assets. > > I'm thinking it would need to have remote storage (hard drive > space), some sort of rudimentary source control system, and document > tracking features. Basically, a central point that would serve as a > hub to store design docs, code files, art assests, schedules, etc. > > It seems like there's got to be something out there, but I haven't > had any luck finding it after quite a bit of searching. Any ideas? Sounds like you're describing SourceForge (http://www.sourceforge.net). Maybe you're not making an open-source game though. You could always pay sourceforge to host your closed source project, although I suspect that's not very cheap. What I've done in the past is set up CVS and some simple web-based file-sharing on a web-hosting account, or even a home server. I think sourceforge is by far the easiest of the above options though. Server administration is a PITA on the 'net; you have to stay on your toes to keep on top of security. -T |
From: Brian H. <ho...@py...> - 2003-03-28 22:44:18
|
We're doing distributed development, and so far it works= extremely well. For source management we're using CVS -- it works with Windows,= Linux and OS X, so we're covered there. For asset management we use Unison, which is like rsync but with= bidirectional capability. I can't say enough good things about= it. It's also free, which is a good thing I should mention. For communication, we use ICQ + e-mail + phone. For copying specific files around where unifying assets is= overkill and simple SCP works. For common files, I write Bash scripts and= just have my artist click on a desktop icon -- the Bash script changes directory, scp's a zipped file down, unzips it, then= exits. That's how she gets the latest executable. For hardcore collaboration and/or debugging on a remote system, I= use GoToMyPC.com, which lets me take over selected systems to see= what crashed and why. I can also install and update scripts, tools,= etc. without forcing the artist to deal with the gory details of= Cygwin or what have you. So far it's working fantastically great. We still need to find a= good virtual whiteboard so visual things can be shared a bit= better. Brian |
From: Brian H. <ho...@py...> - 2003-03-30 19:01:18
|
You know, a whole book could be written about dealing with= multiple screen resolutions... Handling text seems easy enough if you use something like= FreeType. Handling 3D stuff is obviously easy enough as well. The GUI components can be handled either by drawing them vector style or= by having multiple resolutions for your components. What doesn't scale well, unfortunately, are tile graphics, be= they isometric or just good old 2D grids. If your artists makes a set= of 32x16 tiles designed for 640x480, then going to other resolutions= is going to be problematic. For our lower end games it's reasonable to just choose a= resolution and say "Hey, deal with it". The problem is that LCDs pretty much blow this to hell. If you= force 1024x768 on a 1280x1024 LCD, the interpolation artifacts can be extremely jarring, bad enough that a game with significant text= isn't playable (at least, to me). So what I've thought about is forcing 1024x768, and just= centering on systems that are running at a higher resolution, and possibly allowing an override. Multi-monitor can really blow this to hell though, because there= are several distinct versions available and all have different= semantics. Doing something naively like simply centering a 1024x768 window= is very wrong when that window straddles both monitors; but on other= multi-mon configurations it won't straddle both, etc. Brian |
From: Ben H. <cr...@ca...> - 2003-03-30 20:44:01
|
>You know, a whole book could be written about dealing with= multiple >screen resolutions... > >Handling text seems easy enough if you use something like= FreeType. > Handling 3D stuff is obviously easy enough as well. The GUI >components can be handled either by drawing them vector style or= by >having multiple resolutions for your components. > >What doesn't scale well, unfortunately, are tile graphics, be= they >isometric or just good old 2D grids. If your artists makes a= set of > 32x16 tiles designed for 640x480, then going to other= resolutions >is going to be problematic. Most games I can think of simply show more of the surrounding= area at bigger resolutions, which neatly sidesteps the problem. Admittedly, that does give the higher-end machines an advantage,= but they already have an advantage because they're less likely to= suffer from jerk-o-vision. [ cruise / casual-tempest.net / transference.org ] |
From: <_da...@ya...> - 2003-03-30 21:32:58
|
--- Brian Hook <ho...@py...> wrote: > You know, > What doesn't scale well, unfortunately, are tile > graphics, be they > isometric or just good old 2D grids. If your > artists makes a set of > 32x16 tiles designed for 640x480, then going to > other resolutions is > going to be problematic. I've thought a bit abut this for an (amateur) project I'm about to start. I came to the conclusion that I will store the tiles as a simple mesh, then render a tileset at the start of a level/room or if the resolution changes. Nice and cacheable (especially on a PC where you can dump it to disk afterwards). > Brian Dan (Out of lurk-mode) __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer |
From: Ivan-Assen I. <as...@ha...> - 2003-03-31 09:09:46
|
> I've thought a bit abut this for an (amateur) > project I'm about to start. I came to the conclusion > that I will store the tiles as a simple mesh, then > render a tileset at the start of a level/room or if > the resolution changes. Nice and cacheable (especially > on a PC where you can dump it to disk afterwards). So, it's like, enjoy the problems both from 3D and tile technology, and reap the benefits of neither ;-) |
From: Dan B. <_da...@ya...> - 2003-03-31 18:05:12
|
----- Original Message ----- From: "Ivan-Assen Ivanov" <as...@ha...> To: <gam...@li...> Sent: Monday, March 31, 2003 10:06 AM Subject: RE: [GD-General] More screen res love (tile graphics) > > I've thought a bit abut this for an (amateur) > > project I'm about to start. I came to the conclusion > > that I will store the tiles as a simple mesh, then > > render a tileset at the start of a level/room or if > > the resolution changes. Nice and cacheable (especially > > on a PC where you can dump it to disk afterwards). > > So, it's like, enjoy the problems both from 3D and tile technology, > and reap the benefits of neither ;-) I'm a masochist... ahem, it's not quite that bad, the foreground stuff is 3d, but the backgrounds are static so I might as well save some cycles if the tile meshes become more intricate (i.e. if someone other than me does the artwork). I didn't need dynamic effects so I decided on this scheme. Cheers, Dan |
From: Tom S. <to...@pi...> - 2003-03-30 22:05:31
|
> So what I've thought about is forcing 1024x768, and just centering on > systems that are running at a higher resolution, and possibly > allowing an override. I'm confused... isn't the problem different aspect ratios? I don't see how different resolutions from your target resolution with the same aspect ratio are a problem. Tom ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Sunday, March 30, 2003 1:01 PM Subject: [GD-General] More screen res love (tile graphics) You know, a whole book could be written about dealing with multiple screen resolutions... Handling text seems easy enough if you use something like FreeType. Handling 3D stuff is obviously easy enough as well. The GUI components can be handled either by drawing them vector style or by having multiple resolutions for your components. What doesn't scale well, unfortunately, are tile graphics, be they isometric or just good old 2D grids. If your artists makes a set of 32x16 tiles designed for 640x480, then going to other resolutions is going to be problematic. For our lower end games it's reasonable to just choose a resolution and say "Hey, deal with it". The problem is that LCDs pretty much blow this to hell. If you force 1024x768 on a 1280x1024 LCD, the interpolation artifacts can be extremely jarring, bad enough that a game with significant text isn't playable (at least, to me). So what I've thought about is forcing 1024x768, and just centering on systems that are running at a higher resolution, and possibly allowing an override. Multi-monitor can really blow this to hell though, because there are several distinct versions available and all have different semantics. Doing something naively like simply centering a 1024x768 window is very wrong when that window straddles both monitors; but on other multi-mon configurations it won't straddle both, etc. Brian ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
From: Brian H. <ho...@py...> - 2003-03-30 22:21:47
|
>I'm confused... isn't the problem different aspect ratios? That can be a problem, but I'm not even looking that far ahead. >I don't >see how different resolutions from your target resolution with= the >same aspect ratio are a problem. If you design your artwork as a 32x32 titles, then your game is predicated upon, say, 15x10 tiles in your play area if you= designed it around 640x480. Now you try to run at 1024x768. You can either fit more tiles on= the screen (but note that they'll be much smaller and harder to identify), which can screw up play balance, or you can try to= scale up your artwork to match, which will obviate any advantage of= going to a higher resolution. The typical solution is just to force things into 640x480 mode,= but on an LCD monitor the interpolation artifacts are so severe that= this isn't really a tenable solution either. Brian |
From: Greg S. <gr...@st...> - 2003-03-30 22:54:04
|
You could create art work for each resolution that you're supporting - for example, appropriate sized tiles that maintain your ratio for 800x600, 1024x768, and 1600x1200, then limit the screen resolutions to those values. Sort of sprite based LOD. It's more art time, but probably not TOO much more as I imagine most of the source material is high-res renders anyways. Barring that, I think the only other viable solution is to show more tiles on screen. You're not going to ever get any more detail out of them by blowing them up (arguably less, thanks to filtering), so why not just show more? That leaves it up to the user - if they're squinting to see something, they'll bump the res back down to the default. Sure it could screw up balance - but if the game is designed for a certain resolution, only those who bump it up are going to get the advantage. And if seeing a few extra tiles is so important to someone who is competing, they're going to know about and take advantage of the higher screen res anyways. Some pretty popular games have successfully taken this approach, including Age of Empire/Kings. -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Brian Hook Sent: Sunday, March 30, 2003 5:22 PM To: gam...@li... Subject: Re: [GD-General] More screen res love (tile graphics) >I'm confused... isn't the problem different aspect ratios? That can be a problem, but I'm not even looking that far ahead. >I don't >see how different resolutions from your target resolution with the >same aspect ratio are a problem. If you design your artwork as a 32x32 titles, then your game is predicated upon, say, 15x10 tiles in your play area if you designed it around 640x480. Now you try to run at 1024x768. You can either fit more tiles on the screen (but note that they'll be much smaller and harder to identify), which can screw up play balance, or you can try to scale up your artwork to match, which will obviate any advantage of going to a higher resolution. The typical solution is just to force things into 640x480 mode, but on an LCD monitor the interpolation artifacts are so severe that this isn't really a tenable solution either. Brian ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
From: Tom S. <to...@pi...> - 2003-03-30 22:59:34
|
> From: "Brian Hook" <ho...@py...> > or you can try to scale up your artwork to match, which > will obviate any advantage of going to a higher resolution. Ok i see. So what is the advantage of going to a higher resolution on a 2d game which has fixed resolution art to begin with? Is is just the artifacts with LCD monitors? Sorry for all the questions, but i'm interested. =) Tom |
From: Brian H. <ho...@py...> - 2003-03-31 01:05:55
|
>Ok i see. So what is the advantage of going to a higher= resolution >on a 2d game which has fixed resolution art to begin with? Is= is >just the artifacts with LCD monitors? Sorry for all the= questions, >but i'm interested. =3D) That is the gist of it. Running at a resolution other than the native LCD resolution looks really bad -- not in a "this is kinda= crappy" way, but in a "this is pretty damned illegible" kind of= way. So just going fullscreen is actually worse than running windowed.= I tried playing Homeworld the other day, and it has a cap of= 1024x768. When I tried to run it, I pretty much couldn't read the menus on= my Viewsonic VA800. So if you make a game at higher resolutions, you're now doing= some really weird supersampling that's completely wrong and looks like= crap. Probably the worst case I can envision is what we're= trying to do: 1024x768 on a 1280x1024 LCD, which looks WAY worse than a= 640x480 game on a 1280x1024 LCD. Brian |
From: Tom S. <to...@pi...> - 2003-03-31 02:02:28
|
> From: "Brian Hook" <ho...@py...> > That is the gist of it. Running at a resolution other than the > native LCD resolution looks really bad -- not in a "this is kinda > crappy" way, but in a "this is pretty damned illegible" kind of way. > So just going fullscreen is actually worse than running windowed. I > tried playing Homeworld the other day, and it has a cap of 1024x768. > When I tried to run it, I pretty much couldn't read the menus on my > Viewsonic VA800. Had no clue it was that bad of a problem. I doubt LCDs are so widely used to warrant creating a whole new resolution of art for it, but you can't just ignore this problem. I don't see a solution better than your current plan to center the scene. Maybe you can make use of the borders in some kind of useful way like moving hud elements into that space or just do something decorative. Tom ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Sunday, March 30, 2003 7:00 PM Subject: Re: [GD-General] More screen res love (tile graphics) >Ok i see. So what is the advantage of going to a higher resolution >on a 2d game which has fixed resolution art to begin with? Is is >just the artifacts with LCD monitors? Sorry for all the questions, >but i'm interested. =) That is the gist of it. Running at a resolution other than the native LCD resolution looks really bad -- not in a "this is kinda crappy" way, but in a "this is pretty damned illegible" kind of way. So just going fullscreen is actually worse than running windowed. I tried playing Homeworld the other day, and it has a cap of 1024x768. When I tried to run it, I pretty much couldn't read the menus on my Viewsonic VA800. So if you make a game at higher resolutions, you're now doing some really weird supersampling that's completely wrong and looks like crap. Probably the worst case I can envision is what we're trying to do: 1024x768 on a 1280x1024 LCD, which looks WAY worse than a 640x480 game on a 1280x1024 LCD. Brian ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
From: Brian H. <ho...@py...> - 2003-03-31 03:31:35
|
>Had no clue it was that bad of a problem. I doubt LCDs are so >widely used to warrant creating a whole new resolution of art= for >it, but you can't just ignore this problem. Tying together a thread here and on gamedevlists-windows, neither= LCDs or multimon systems are super prevalent, but as time goes on= they will be. Apple is pretty much pushing LCDs exclusively for their computers= now, including the iMacs (15" and 17" widescreen LCD) and their= 17", 20", 23" and 24" Cinema Displays. In addition, notebooks are becoming more popular. The Apple notebooks and some PC notebooks have widescreen LCDs (1280x864 I= believe on the TiBook 15"; 1600x1024 or something similar on some= PC notebooks I've seen). Monitors have a cap on usable size before they're too large, and= at that point for people that need multiple monitors (which is more= people than you'd imagine) the incremental cost is justified. Especially given that you can find $75 graphics cards with dual outputs, and a second 17" CRT is only $150. For $225 someone can= go multimon -- even cheaper if they get a $25 PCI graphics card to= use with their existing one. And to show even more synchronicity, a lot notebooks happen to= have a second video out to run dual mon. I know the Dell Inspiron and= Apple TiBooks have this feature. So it's not a huge problem right now, but both of these are= growing problems. In the case of LCDs, they'll probably supplant CRTs completely within about 5 years. 15" LCDs are down to < $300 and= prices will only drop. Brian |
From: Ray <ra...@gu...> - 2003-03-31 02:08:49
|
I think another option is to just have a black border around your tiled area to fit it to whatever res you're in. Of course that wastes a fair amount of screenspace. Another option is to have the artists make the tiles at like 2-3x size and then scale them down in software to the size required to view them. Another is to do each tile in 3d and let the 3d hardware deal with it. Sorry if any of these ahve already been discussed. - Ray Brian Hook wrote: > You know, a whole book could be written about dealing with multiple > screen resolutions... |
From: Brian H. <ho...@py...> - 2003-03-31 03:33:00
|
>Another option is to have the artists make the tiles at like= 2-3x >size and then scale them down in software to the size required= to >view them. This balloons content size, but it might end up being the most reasonable approach. The downside is that the scaled down images= look significantly worse than hand tweaked ones. >Another is to do each tile in 3d and let the 3d hardware deal= with >it. This is the easiest approach, except when you're doing a 2D= isometric game that runs completely in software =3D) Brian |