Really???
OH, thanks. That will be amazing ...


So... we'll become builders?

Well looks like I'm asking for Java then. Ummm I though it was going to run slower because you were going to develop it faster. hmm.

Just bumping the thread so people will look at the update. I'll post the new update here as well so you don't have to go back and look at the first post.

*UPDATE Nº2 (03/01): Okay, it seems that no one else is going to offer their opinions or specs, so I think it's time to make a decision.
Since the majority voted against Java (5 vs. 3 at time of post), the game will be implemented natively on Windows. Also, the target platform will be an approximate average of the specifications that were posted. Concretely, this means the game will be made so it will run well on:
CPU: 1.8 Ghz
RAM: 512 MB
Video Card: GeForce 2 minimum; if time allows, there may be optional pixel shaders for you people with cards that can handle them.
HD: Kind of irrelevant in light of the kind of computers you all have. There's no way I can fill up that much space.

from what i've read in some it magazine, java is very close to native code in terms of speed.
but on the other hand, it's not that hard to write code that is portable, it's just very small portions that have to be system-specific. for instance, if you stick to standard c++ libs and opengl for graphice only stuff like initializing the output window/context is different for each system, whereas the actual rendering code can be shared due to the common opengl api.

Well, you're right in that saying 20% slower is a bit of an exaggeration, but it's still definitely not as fast as C++. C# can get about 98% of the performance of equivalent C++ code when we're talking 3D hardware accelerated games, but Java is not C#. Both are bytecode interpreted languages, but C# can access pretty low-level stuff because it's not intended to be a crossplatform language (Mono project notwithstanding).

Anyway, as the poll ran I did some more research on 3D libraries for Java, and found that development would not be faster at all because the existing libraries are few and poorly documented.
So, my choice of implementation technologies boils down to:
C++ for performance critical code (i.e. game engine), Python or a similar scripting language for game code (so it's easily modified), OGRE for graphics stuff, and possibly ODE for physics.
I'm still undecided on whether to use Python, Lua or Ruby as the scripting language. I have to do some more research on them to make an informed choice.

Who knows, maybe it'll end up being pretty portable as well; none of those components are strictly platform dependent.

edit: By the way, you seem to be pretty knowledgeable about this stuff. Ever done something like this?

I think playing a game on Virtual PC would hurt performance a lot.

Linux has "WINE" ("Wine is Not an Emulator") but it has problems with some things, runs them slow, etc. In particular, I got Half-Life 1 to run well on it, although the menu screen was buggy.

If psiberpunk isn't going to use DirectX, it should be pretty portable...

Worry not. I'm going to use OGRE (Object-oriented Graphics Rendering Engine) which is API-independent (can use OpenGL or DirectX depending on what's available). So, I think it'll definitely be portable. The thing is, if it doesn't just run right away on Linux or Mac I won't know what to do to fix it. Mac is going to be the most trouble, because I don't know anyone who has a modern one to test it on. Macs aren't very popular in Chile.
Anyway, there's lots of other things I'll have to worry about as I develop this game that have a much higher priority, so I guess I'll get to the porting issues when they're relevant.

i have started a small game project some time ago, using c++ with opengl and javascript from mozilla for scripting, but it's in such an early stage that it's not even worth to show. what i planned was to use quake3 bsp maps stitched together to create a big world composed of smaller maps so a map editor could build one part of the world without to recalculate the whole world in terms of pvs and lighting. there are already tutorials showing how to load and render quake3 maps and editors are pretty high developed.
the idea for the game is in fact a blame-ish cyberpunk mmorpg, complete with netsphere, different races etc, but that is so far in the future i dunno if it's ever going to get so far.
some of my ideas for the game include "real" programmable in-game computers with javascript and areas with different gravitation, just like in blame.
btw check this funny game out: http://www.ageoftime.com/blockland/
i like the idea of players interactively modifying their environment as it somehow resembles the builders in blame.

Oh, now that you mention it, I'm pretty sure you've posted something about this before. I'm also pretty sure I said it sounded cool, but there might be lighting glitches in the areas adjacent to the place where you stitch the levels together. It could be fixed by implementing a portal engine for the lightmap computation and rendering, but that forces the maps to be stitched together in a predefined way.

Perhaps we could join efforts some time in the future after we've finished our projects. Are you planning on doing this professionally at some point?

Oh, and that game looks awesome.

edit: Duh, looks like my memory is failing massively. We'd talked about this through private messages. Well, as you can see I'm now starting out with a simpler project than what I originally had in mind. I think this one's actually plausible.
Jeez, I really feel like some kind of Alzheimers sufferer. I honestly didn't remember any of what we'd talked about... I guess the semester was harder on me than I had thought.

yes, we definitively talked about it before and you said you wanted to use c# back then.
it would be cool to be a game programmer, but first i've got to finish university, and i guess game programmer jobs are quite rare.
the problem with lighting on adjacebt maps is quite easily solved, you just have to ensure, that the lights in reach of the border area are on both maps, so the stitched together parts are identically lit.

atm i have some tests to finish and i have to wait how much work there is to do in the next semseter...