Unseen Studios

The size of this forum has grown immensely from a basically all-developer forum.

Karl,

Who exactly are the real developers on this project?

Karl's on break right now in Florida. He'll be back next week, so don't expect an answer until then.

As for myself, I am not actively involved (at this time) in the development of PV, other than some peripheral discussions I've been having with Karl. I hope to have a more active role in game development once summer rolls around.

I think it might just be Karl and Thadius right now, I don't know really though so don't take my word for it.

and then the "others" such as me that submit a few models then randomly dissapire for a week then randomly come back, lol

I hate when people randomly dissapire.

Right now Karl and I are the only ones with access to the PV SVN/trac.

Errr, not quite what I meant.

I didn't ask who contributed some models or has SVN access, rather, I meant who actively develops this project and is a member of the team.

that would also be karl and I

You are programming for PV? What do you work on?

"Karl and me"

The Latin gets to I.

map maker right now, I'm converting it to MDX and putting in some .X loader functions

You are converting it to MDX/.NET? Wow, what a waste. You certainly aren't going to get a performance improvement, and MDX2 was killed by Microsoft. Be wary of what your idea of the future and Microsoft's idea of the future is. That being said, I wish you luck on that effort.

As for the X file loader...that is a dog. =\

I have written an X parser before, it isn't a lot of fun. Then again, it was ANSI C and ran under Linux. I don't know what predefined APIs MDX has, but if you are going to use MDX, you are pretty much locked in anyways, so you might as well use the API they give you: it will probably drastically reduce the complexity of the problem.

Mmm, I like how b'itch turned into dog.

I'm converting it to MDX for my own purposes, mainly for learning, but yeah loading .X meshes in MDX is pretty much a one or 2-liner

Well "team" would imply more organization than is really present. At this point we have more of a "loose coalition" of contributors led by myself and Thadius. I am developing most of the root code in the hopes to hand over more of the development control to Thadius in the future once he gets up to speed.

I assume you ask out of curiosity?

Well, at one time I remember the BTR (can I say that here?) team had a large number of people involved with it, and I wanted to know how many developers actually followed your lead on this project. Not a whole lot from what I have seen, but that is OK.

I mostly enjoy reading through open source projects, sometime contributing small amount of code. I have made a few (personal) changed to things, ported a few programs where ports did not previously exist, and submitted code for others. Small, things usually...

However PV isn't open source, and I don't think it should be. I would like to see what the current state of the code is however, and this is impossible. Damned shame that is how it all works out, but some projects just don't work as well open-source. =\

Maybe you could sometime give me a technical rundown of the current state of the project sometime? While I prefer OpenGL/UNIX/C, I have a much more than passing familiarity with Direct3D 9/Win32/C++.

This project isn't BTR; that game will be resumed at a later date and shares no code with PV. The projects are entirely separate, as is the development team. I'm not sure what you mean by "technical rundown" but I'd be happy to discuss it with you at some point.

Sorry about the terms. By technical rundown, I mean a large overview of the extremely technical bits.

For example, TCP or UDP communication, or both? Client single or multithreaded? Fixed Function or Pixel/Vertex shaders, or can switch between the two? Engine as DLL or static link? Renderer as DLL or static link? Server: single or multithreaded? Collision detection? Database or flat files? Pancakes or waffles?

You know, all of that great stuff. If you had to explain to another programmer some of the design decisions were, what would you tell him/her? The answer is likely rather lengthy...

Ahh I see. Well, as much of the code is undeveloped, the technical specifics are rather lax at this point. However, I can address all of the examples you gave

likely, both (UDP for in-game, TCP for connectivity)
single-threaded client
both fixed function and vertex shaders (min vs1_3). no pixel shaders.
engine, renderer, networking, etc, all statically linked
collision detection on a very grainy basis--no model-based detection, 2d collisions only on the flat plane (circle, box)
flat files
depends

Hmm...more specifics?
Platform: Win32
Target OS: Windows XP
Graphics: DirectX 9.0c
Audio: OGG-Vorbis
Input: Win32 (yup, you heard me)
Network: Winsock...bleh

Karl

Sounds fairly decent. I'm not sure what other kind of networking you could use on Win32 based systems other than Winsock, unless you consider Winsock to be the WSAXxxx() functions and not the BSD functions.

It does scare me it a bit that you wrote "likely both" rather than just "both" for the protocol.

How tightly integrated is the graphics/networking/input into the application?

Although I am doing some housekeeping on the code to separate rendering/etc. from PVs more specific code, I'm not being religious about keeping distinct barriers between them. At some point, you have to come to a middle-ground just to get the damn thing to work.

I'm saying likely both because it's possible that I will use TCP for logon procedures, etc, if it is easy and fits in nicely with the rest of the code. If it isnt, well, away it goes.