Greetings, been watching the list for a month or two now, downloaded the archives and searched through them, still have some unanswered questions.
I am planning on moving a little game/mod of mine over to the Source engine from another. I am using quite a few features which are standard in the other but not in Source, so I am interested in workarounds. I know some things will be just flat-out impossible, but if anyone can think of workarounds then I would be interested. I am not going to bring over the whole thing (just because I know many of the limitations of the Source engine in comparison to what I was doing), but I am still going to list off the capabilities I used that I do not see obviously done in Source, just because if it is there or there is a nice work-around then I will look into using it as I did before if at all possible. I am also most likely going to ask a few different things a few different times as I remember them, all in this thread. Also, anyone that responds could you respond to the whole list (unless you wish to tell something that you do not want me to release) so it could be archived for future users. To start, the previous engine I used was mostly designed for accuracy, although it was quite fast, it was not really for main-stream games. The basic storage unit was not actually a floating point, but rather an integer, with the base unit at about 0.1 millimeters (100 micrometers), although a single line change could change that (a macro). It used a floating-sized integer however, the main storage class mutated to be based on a 32-bit integer, 64-bit integer (or just 64-bit for the smallest when compiled for 64-bits), or an n-bit integer. It was quite fast since it was allowed to make quite a few assumptions. The renderer was odd in that anything beyond a certain distance was rendered in a vastly lower quality (like normals LOD), but rendered in something akin to a Sky-box and not updated unless something caused a change to occur, such a large change of position of the camera, too great of a change of position of something being rendered at that distance (such as a planet moving), a large explosion at a distance (which made the outer-rendering real-time for the duration, still fast due to the few and low quality models at that distance, things that were too small were not rendered at all). There would be multiple levels of this, the nearest being what you see closest, to the furthest near never being updated, generally containing galaxies, procedurally generated (and filled if you ever went to them, down to solar system, planets, foliage on the rare times those came about). You could literally walk on any planet (if it would not kill you in various ways of course), launch in a spaceship of some sort and FTL to any other place anywhere you could see, would be procedurally generated up, although game-play was generally constrained to vastly smaller areas. Internally it handled things in more of a tree, so that objects that were near together were generally within a single node (simplifying often used calculations to always using integers for distance, instead of the more complicated n-bit integers). The basic player class was actor-less (it had no model), but attached to objects. For example, you would spawn a player model, and you would have the playercontroller class attach tot he player model actor class, it could attach by either linking to it, thus controlling it, or viewing through it, thus having the player camera attached to the model (at a viewpoint generally defined by the model, such as the eyes on a person). Even when the player was attached to something else you could still have it re attach one of those aspects to something else, for example a view, such as a remote drone you could be seeing through, or just the controller, remote controlled car for example. If it was not attached by controls then it was like a player in ghost mode, able to move around any which way, model-less, just a controllable viewpoint, of which normal players were not allowed to experience. The client part of the app just received information it needed to know about from the server, immediate area, seed numbers for generating the world, etc..., drew things as stated above in those layers. The main issue I had was lack of content and people to make content, although the only content needed were unit/ship models, textures, etc... Most of the universe was dynamically generated, not always pretty, but it worked, and you could override any section to fill in your own data (a city for example). I had my game/mod to be more of an RTS style with fps interface (think Activision/Pandemic's Battlezone 1/2 series), that by the end of a game session (if you went the full tech tree) that you would be collapsing entire galaxies into singularities for raw power, technologically not hard to do in that engine. Hence why I am here, mostly wanting to create something simple, a part here or there as it feels fun, but still of the BZ1/2 interface. The first thing I notice is that the playercontrollers are not quite as separated from the world as I am used to, and as a consequence of that the engine only seems to properly interpolate the player and other basic things. Things like vehicles tend to be forgotten when it comes to interpolation I notice, they just do not work well in the server/client world, only single-player, and since this will generally revolve around vehicles, I need to know how this can be fixed (quite a bit of Internet crawling has revealed very little about fixing the problem, only what the problem is). If (pseudo-)large levels could be done in Source then I would like to bring back the massive ships as well, the ones that you walk around on. The other engine had it so anything of a sufficient size (rather small actually) created a new node for it and anything nearby was part of that node, so players walking around on this ship, although it could be traveling quite fast or transporting around, moved around on it as if it was still (sans the occasional weapons fire or something else that was designed to effect the inertia dampeners). Tests thus far here indicate that it is difficult to keep a player... 'still' on a moving platform, I might be able to work around it by constantly updating position based on a linked parent, seems hackish though, thoughts? Another thing, generally when a ship FTL'd it could do it in one of two ways, one basically just moved it there after fancy effects and so forth, the other actually created a wormhole where you could see through to and interact with the other side, think Portal, just much larger, and tended to destroy things if it closed while they were partly through (or opened inside them). That was also comparatively easy to do since the nodes just auto-linked things as needed, bringing the two physics locations together. That is another thing, it used its own physics system for most things, but things on a smaller scale, battles on a planet, just moving around inside spaceship, etc., it used a local physics world that used the NGE physics engine (nicely accurate unlike... others, still quite fast). I plan for this mod to be mostly on the ground due to engine limitations, but if I can still get space in there I would prefer that this FTL style to still exist as it made for interesting strategies. Thoughts about how this could be done from just the modding side? Also, what about size and scale, I have thoughts about making the mod feel much larger then it actually is and without letting the player go further, but I would still like to get as much usable space as possible, what is a reasonable limit without incurring slowdowns due to distance (since it does not have that multi-leveled rendering pattern described above)? While I am thinking about it, if things are built in this as I used to, then I would need to be able to combine multiple objects into one physics shadow. Normally I would just call something akin to anObject->Fuse(anotherObject, matrix4x4, flags) to perma-combine things into one thing in the other engine, how would I go about combining multiple physics shadow's into one in Source (not welding, not strong/stable enough and has performance penalties I do not want). Players should be able to create their vehicles by specifying parts and link positions and have the thing perma-fused into one physics model (with moving parts added after the fact of course). This is all for now, heading back to work, will add more later as I think of it. Thoughts for now though, and do remember, I stated I am already planning vastly smaller and have thoughts about working inside these constraints (sans the vehicle one, and the fusing), just would like work-arounds if anyone knows of any? _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
