Anger's Alternative

science wrote:There's this too: http://polycode.org/ (+lua, +network MIT licence)

much closer to what im after - might be right on the money there.

science wrote:You could prototype the game with an off the shelf game engine then see if you needed more. If so, you could replace components with your own as you create them and would have an existing framework to test them with. (until you conclude that a ground up rewrite is necessary anyway) Assets could be created in parallel for the prototype and should easily be transferable to a future system.

ive thought about it but the development timeline using the bigger engines is obscene if it is to be largely discarded down the track... at any rate, i havent found something i would like to use to even prototype it (if i did i would use it outright to make the game if it had networking support too, otherwise yes, just prototyping until the net code)

science wrote:Open third party libs (licence permitting) can be thought of as malleable templates anyway since you can modify them to suit your needs as and when the need arises. Well funded commercial libs are likely (but not guaranteed) to be superior in terms of their feature set and quality though. That's the way the cookie crumbles. Games like MB aren't really pushing the envelope from a technical standpoint though.

MB, technologically, is a joke. ive made more complex incomplete parts of game engines from the ground up. my preference was 1. totally grassroots / self-made, 2. combine existing components (graphics library, sound library, physics...) and link them manually as required and 3. use something off the shelf with minimal changes. reason for that.....

science wrote:The thing is, if you anticipate being the primary developer then you need to look long and hard at your own motivations. If you were really excited about rolling your own engine to pull in and glue together anything you wanted to adopt (sound, physics) then without that additional source of enthusiam, your motivation may ultimately evaporate and the project along with it.

this was why i put it on hold, and why it has been on and off - it started as a personal aspiration. over the last 3 months my motivation for doing this has changed; ive seen that the genre works, ive seen a community starved of features they want and theyre not afraid to ask for them, and ive seen that same community be all but ignored by the people set to most benefit from such feedback... this is why ive stated that im bringing in my list of ideas and do's and don't's rather than saying that ill build this thing on my own - that's clearly not going to happen after 5-7 years of working on the ideas and mechanics behind it.

science wrote:If you just want to make "that game" then it's probably not such an issue. At least if you prototype it you still have the possiblity of implementing your own stuff down the line if needs be. Just be careful to do what you want to do and not what other people want you to do.

yes, this.

i dont like prototyping too far or too wide, i pride myself on the foresight to know that the independent parts will be built to a plan and their interactions set, defined, and properly tested before use / production.

i have quite a few of 'that game' that i want to make, this being the most viable at this time - but importantly i have identified that this is not just for me anymore, others will want to help shape this type of game and in a sense what im offering so far is about the most i could do... research, seed the ideas & guide the development; that's what i do best and how i wish to contribute to this (besides managing it purely on the basis that ive suggested it and pouring my all into it for as long as i can).

ok. im willing to give polycode a go. its likely the only thing ill come close to wanting to use off the shelf... the feature list (and even the way it is laid out) should speak for itself - http://polycode.org/features/

ill still wait out until the poll ends (12-nov) before committing to any such choice, in case something better is suggested / found.

edit - the more im reading into it the more im liking it... thanks science

thoughts?

thoughts?

I have a few, I don't have time to pen them atm though. I'll try and reply later.

Perhaps prototype was the wrong word to use. I didn't mean something inherently disposable, just something you could leverage to rapidly put something together and change only if necessary.
Something that designers could use to load their models, textures, sounds, something substantial to prove that they aren't working on vapourware really.

The poll isn't really a reliable indicator of much either.

no, i suppose not, but it achieves its purpose:

1. bring the project to people's attention - many don't visit this forum frequently anymore so i figured 2 weeks would be enough time for those still interested to browse through at some point and take notice...

2. gauge how many of those are genuinely interested in helping something like this grow, given the state of things - im not going to rely on the numbers too much, the options are there so people are clear what kind of assistance i had in mind when asking.

ok, so polycode turns out to be too early in its development to use... shame too, looked promising, but critically, its network module has yet to be documented let alone compiled by anyone... oh well...

panda3d makes network play very very easy with distributed objects... ill need to read more in depth into panda and have a good look at unity too (uses a js-like scripting language, think unreal-script, from what ive read)

edit - at this point unity seems pretty good... less hard scripting required, meaning more people could help develop the core aspects... 3 am here and ill sleep on it some...

i have an idea for fast travel, you could use some kind of device that phase your ship to an alternate dimension(some kind of hyperspace but you cannot crash since its like your ship becomes ethereal) were you can travel FTL, the trick is you need to stand still for 10 seconds for this device to charge and generate enough energy to bend space and time and when you finish the travel you end with both shields and weapon power depleted, that way you dont have an entire fleet teleporting in front of you ready to lay waste to whatever crosses its path and people can't use it as a cheap escape tactic

unity uses js and c# mostly but there is a big community and free modules.
it is multiplatformed (win;lin;mac) and even browser compatible (if u have the gameplugin(free))
I started using unity some time ago and must say it almost gives u everything u need. I am not familiar with the network socket programming but there are modules too.(although i am a big fan of self cooked code)

I sympathize with different star systems to touch but to get into action will
need lots - i mean lots of players .... to get a map with 10 systems or what into a major battle.
anyway a stable self cooked MB Clone with team choices, new maps or campaign mode and some changes in ship equip would be more than i can imagine for now.

In general we will need a game design concept.
Without an organized and higly detailed feature list we just will produce happy crappy chaos ...

agreed re feature list to an extent...

unity networking looks like this: http://docs.unity3d.com/Documentation/Components/NetworkReferenceGuide.html

Its great you are finally looking at taking your concept forward !

Dont know where i can help out - I voted for 'A' testing days ago and have C++ skills but I would not trust myself to code anything as it was so long ago. The rest are things above I have some or little knowledge of.

What I would suggest is that IF you are planning on using this forum 'moonbreakers.forumotion' to keep contact links, then yourself and the people who are or you wish to work with on the project, are assigned to your own section with your own admin rights - a bit like clans limited access. Otherwise you will have 'everyone giving advice about the whichness of why' over things they know very little about.

Briefs and updates could then be put out by the team and possibly similar to Mech Warrior, in that, a certain few are assigned as filters/responders so as keep the rest who read or who link for updates and leave you to get on with it. Otherwise you will have a Q/A's going on forever.

As for design - have/did you ever play freelancer, specifically the lancers reactors moded version. What they tried to do was to take the basic freelancer ship(s) and add modules to increase certain attributes. Sort of all ships flew but then with the add-ons some should have flown and been more responsive/better fire-power/shields etc than others. I believe that if they had taken the design fully to completion it would have been fantastic but it didn't seem to fully work.

I believe the continual online universe would be fantastic I agree with Thufir it would require a great deal of online support, but the game may be able to be design to be open ended so as something like that could be bolted on? I think Snubby alluded to something similar in the Echo forum http://moonbreakers.userecho.com/topic/101482-suggestions-on-various-topics-for-the-game/

Anyway, (I got a little carried away) if anything, let me know.

Complex lain wrote:
What I would suggest is that IF you are planning on using this forum 'moonbreakers.forumotion' to keep contact links, then yourself and the people who are or you wish to work with on the project, are assigned to your own section with your own admin rights - a bit like clans limited access. Otherwise you will have 'everyone giving advice about the whichness of why' over things they know very little about.

This is already planned...

I like the idea of using different 3-manifolds to play on. Locally all 3-manifolds look like the euclidean 3-space. So if you choose it big enough, it doesn't get noticed by noobs. Dogfights would stay the same, but large scale battles become more interesting.
3-sphere: http://en.wikipedia.org/wiki/3-sphere
hyperbolic space: http://en.wikipedia.org/wiki/Hyperbolic_3-space
Gieseking manifold: http://en.wikipedia.org/wiki/Gieseking_manifold
Seifert–Weber space: http://en.wikipedia.org/wiki/Seifert%E2%80%93Weber_space
Or more complex manifolds with alot of big "wormholes".

Complex lain wrote:As for design - have/did you ever play freelancer, specifically the lancers reactors moded version. What they tried to do was to take the basic freelancer ship(s) and add modules to increase certain attributes. Sort of all ships flew but then with the add-ons some should have flown and been more responsive/better fire-power/shields etc than others. I believe that if they had taken the design fully to completion it would have been fantastic but it didn't seem to fully work.

this is in the spirit of what i have in mind... eg, a shield module will add a shield layer of a certain strength, and something like a shield booster module could be added to the shield module, which increases its regeneration speed by a factor. weapons and their modifications would work on the same basis. at least that's the goal if it can be done effectively with the engine that ends up being used...

Complex lain wrote:I believe the continual online universe would be fantastic I agree with Thufir it would require a great deal of online support, but the game may be able to be design to be open ended so as something like that could be bolted on? I think Snubby alluded to something similar in the Echo forum http://moonbreakers.userecho.com/topic/101482-suggestions-on-various-topics-for-the-game/

if you mean how i think you mean, then it will... most likely... once the engine is ready, the aim is to have a short turnaround time by design for additional concepts / items to enter the game with next to no changes to the engine necessary, and delivered in regular updates.

Abstractness wrote:I like the idea of using different 3-manifolds to play on. Locally all 3-manifolds look like the euclidean 3-space. So if you choose it big enough, it doesn't get noticed by noobs. Dogfights would stay the same, but large scale battles become more interesting.
3-sphere: http://en.wikipedia.org/wiki/3-sphere
hyperbolic space: http://en.wikipedia.org/wiki/Hyperbolic_3-space
Gieseking manifold: http://en.wikipedia.org/wiki/Gieseking_manifold
Seifert–Weber space: http://en.wikipedia.org/wiki/Seifert%E2%80%93Weber_space
Or more complex manifolds with alot of big "wormholes".

i have been thinking about that some more, re the scale vs realism vs pace...

now, stop me if this is too far...

ive been curious about how real zero-g combat would work as a playable game... contrast it with MB, which someone here has observed to behave more like extreme mini-subs. real zero-g would involve much faster speeds, more advanced motion & maneuvering options, and far more realistic weapons, devices and gameplay implied... the main problem i see is the maneuvering.

give ordinary plane controls to space physics, and you will look like a walrus on a jetpack - funny and inevitably ram into the first object you see.

so how to solve the walrus jetpack problem? taking some inspiration from Orbiter (try some low thrust flying with minimal use of the main engine near the ISS), it is starting to seem possible to create a gameplay style around both high speeds and fine tuned maneuvering by making a couple of radical changes to game play (bear with me) and giving control over linear and rotational thrusters.

(again, only a suggestion at this point)

start with a realistic space flight model (inertia, celestial body gravitation + semi-realistic / playable orbit physics).
the controls should still be intuitive, so mouse / keys ought to do the same thing they do now if possible...

ive been toying with:

w/s/a/d - forward/backward thrust + roll
mouse Y - pitch
mouse X - yaw
(so far as is with MB)

space - align to axis of motion; while held, will rotate the ship towards the condition: abs(ship_vel:normalize():dot(ship_forward)) -> 1

shift + mouse Y - up/down lin thrusters
shift + mouse X - left/right lin thrusters

that should be simple enough to use i think... now the next question this raises is how can you dogfight with those controls? (this is the drastic change)
automated tracking and targeting.
i wont deny it, MWO's weapon groups fit in nicely with this, more so if you remove the need for manual aiming and let an on-board computer do the tracking for you... moving at realistic zero-g physics speeds and scales will make manual targeting all but impossible when coupled with any lag at all, so i figure having only one active target (as per MWO) and having your weapons (now turrets) automatically and realistically aim at your target on their own is a good compromise to being able to truly pilot a space craft in fast pace action (as opposed to piloting a submarine). i mean, come on, surely if we have space flight we would have the sense to install tracking computers on our artillery?

additional controls then are needed...

weapon grouping controls like MWO - arrow keys + rctrl. imagine a grid: weapon vs weapon group, arrows move the position on the grid, rctrl toggles firing on that group for that weapon, the selected weapon group will fire to mouse1, etc...

R - select target closest to center-screen. something like a target selection mode will be required, either while holding R and rotating the camera to select, or press R + mouse1 to select + mouse2 to deselect + R (again) to cancel... (perhaps multiple target selection, with distance + your ship's orientation = target priority per weapon upon firing? idk, many ways it could be done though i recon its too much)

once you have your target, the challenge is then to intercept them. the skill factor will go into here + when, which and how to use your modules / weapons. i foresee the need of something like a 'zero relative speed to target' button which will attempt to use thrusters to stabilize relative velocity to match your target's while it is held down enabled (i dont think it will take away from the skill; it is going to be used less than you might think and there are clever strategic uses to it too). im not sure where you would want this key available, but i would assign it to lctrl to toggle the behavior vs the current target (switching targets will reset it to off).

so then:

lctrl - toggle match-target-velocity auto-thrusters

it sounds and is a drastic (imo) shift away from MB's controls and gameplay, but what it offers i feel is worth considering...

it would resolve the problem of large scales / speeds hindering targeting. it would justify large scales too if you keep the gameplay localized to specific areas (say by a killzone like BF/MW or barrier / shield, or non-Euclidean space) but the solar system for the most part remains the same (kind of like missions in sandbox games, closest analogy i can think of)... the alternate to isolated game spaces within a fixed world is to allow a means of faster travel but perhaps limit it to a library of known coordinates only (planets, anything with a known orbit, mission markers, player bases, etc; could be mission specific and team specific too, and so on...).

what do you all think? submarine, walrus with jetpack or drastic shift?

I don't want to shoot down the debate, but I don't think the control mechanisms require much forward planning and so can be experimented with and decided upon later.
I do think that there are several different, well defined game types each with a credible provenance, but that in combining their attributes, you may find that they may nullify each other.
An open, exploration and encounter based space game (I dunno, eve with balls?) could be great, but would require the open sandbox side of the game to be commensurate to the combat else you would just have largely pointless empty space. (seriously, why have a huge universe if you then need to corral everyone into a limited combat zone in order to organise a decent punchup)

I played SWG for years. Much maligned though it may have been, it was also unparalleled before or since with it's variety of gameplay and complexity.
It's was also a triple A title funded by an industry heavyweight and so generating that content wasn't such a problem. Content on that scale is beyond the scope of a volunteer project at this stage imo. Also, whilst I enjoyed space, PVE and PVP, crafting and reverse engineering, you could fly for a week and not see a soul unless you attended ad hoc PVP events with arbitrary and poorly adhered to rules. You also had a turnaround of anywhere between a minute or so and several minutes between dying and rengaging. MB in that respect is more fun by virtue of it's consistent gameplay experience.

MMOs, which tend to have lots of space with the gaming population widely dispersed within it, tackle the vicinity problem with battlefields which arrange a matchup and teleport everyone into the same area. But what would a space battlefield be if not something limited like MB?

Ultimately, I don't believe that the small, fast game can be reconciled with the large open one whilst retaining the benefits of each. An open game is also much harder for a volunteer team to create. You need to decide which you want to make, because that decision does require some forward planning.

Personally, I'm looking for a fast, skill based dog fighting game with some variant of an atmospheric flight model. I prefer scifi since you aren't then restricted by reality.
It could be alien germs invading a toilet bowl for all I care about the theme, It's the flight mechanics themselves that I enjoy.

Not bouncing off the edges or getting stuck in the corners of supposedly open space would be nice, but in the case of MB, it's a solution looking for a problem. If the action is behind you, turn around.

Also, if you start removing the restrictions imposed by atmospheric flight, in terms of effective distance, speed and acceleration you start to *need* computer assistance because we mere hairless monkeys are not capable of operating within the resulting tolerances. At which point it stops being a game of skill. Much of what is done in eve would not be possible manually.

eve with balls is an apt way of putting what i would love to create given enough time... it would be awesome. the flipside is i wanted to mesh the idea in with mech warrior, which the gameplay always felt too 'clunky' to me (go figure). but i do like a lot from both games, the problem is you easily bore of either, and i think im far from alone in that assessment . there isn't much point in implementing a good 80% of eve's mechanics, either because they're wrong or remove all skill. one of those mechanics is unrealistic flight. if you can tell your ship to orbit your target, you have nothing left to do except fire your weapons; the skill in MB is split about 4:1 flying skill : aiming skill, and the aiming itself is full of complaints and misunderstandings from even players who have been at this game for a long time... make the aiming automatic, and make the flying more realistic + challenging (ie, requires skill and knowledge of zero-g physics, as well as extra-atmospheric controls like lin thrusters) seems like the first step forward imo. it is a leap away from MB's skill set but i don't think it will make it easier, it will take the focus away from manual aiming (which simply is an inhumanly difficult task in space) and shift it to outsmarting / outmaneuvering your opponent. unless im mistaken, even the current MB gameplay amongst aces cant last as a high-noon head to head charge every time, it quickly develops into complex games of cat and mouse around opportunity and obstacles (while it lasts).

you're not shooting it down, you're moving it forward lol - if everyone simply agreed it wouldn't be a debate.

so yeah, call me a bit purist on the matter but shouldn't a space dogfighting involve astrophysics more so than aeronautics? in the end im not too concerned which is used because im after any workable flight model that is simultaneously sci-fi (inescapable, may as well embrace it) and modeled on realistic physics as a base (ie, in MB, turning changes where you're flying, in space that wouldn't be the case unless you're accelerating too). scale comes as a related question which must be considered when deciding on the flight and game physics that will be at play... i cant commit to a scale until the desired flight mechanics are identified and refined to a sufficient point, which is what im asking for people to think about (trying to anyhow lol).

frankly, eve isn't a good base to model space physics off of (MB has better ship collision, and that should say something). but i agree with their use of turrets, and that hasn't degenerated the game play beyond enjoyment (there are better reasons why it does become a bipolar experience quickly though, i'm sure we all have our own examples of that). the part i like is turrets having to automatically track the target. eve is... lax... when it comes to ballistics... (its probability based with optimal range and arctan falloff range after that; Opt + Fall = 50% hit, Opt + 2xFall = 0% hit). however, their angular tracking is accurate - the turrets physically have to turn (like carrier turrets in MB) to fire in the right direction so the projectile intercepts the target; they turn at a fixed rate, and maintaining angular velocity above that means the turret can't keep up. turrets will still have a spread to a degree which will limit their effective range (and the projectile's lifetime kicks in as a limit around that range too, give or take), with the distances across which you fire making evading even perfectly accurate gun fire very possible so long as you're regularly adjusting your velocity.

science wrote:Not bouncing off the edges or getting stuck in the corners of supposedly open space would be nice, but in the case of MB, it's a solution looking for a problem. If the action is behind you, turn around.

If we use a closed manifold the problem is solved: finite space without boundary.

Viking Jack wrote:i have an idea for fast travel, you could use some kind of device that phase your ship to an alternate dimension(some kind of hyperspace but you cannot crash since its like your ship becomes ethereal) were you can travel FTL, the trick is you need to stand still for 10 seconds for this device to charge and generate enough energy to bend space and time and when you finish the travel you end with both shields and weapon power depleted, that way you dont have an entire fleet teleporting in front of you ready to lay waste to whatever crosses its path and people can't use it as a cheap escape tactic

eve lol... (im over comparing it but no choice here)

warping ate the capacitor (a self-recharging bank of energy) to initiate, warping involved aligning to the destination within 5 degrees and accelerating to 75% of max speed. at that point you were removed from play and warped out, but until then your ship is vulnerable to warp jammers (tech: the warp bubble is formed by a depleted vacuum bubble, the charging step is removing energy from the field, jammers flood the bubble with energy preventing its formation, WCS could be used to offset the jammers count for count, etc...). if you didnt have enough capacitor charge, you would warp as far as you could and the ship would retry if on autopilot until it reached the destination. destinations could be selected by bookmark (known / visited coordinates) or by celestial object (planet, station, beacon, fleet member if farther than 150km, etc...).

most of those mechanics i like, but in eve the problem came down to the warping mechanic being the most important one to understand; most open pvp play came down to who could stay in jamming range (tacklers / point ships / interceptors) and web range (slows engine speed to 20% or lower) with the weapons playing a fairly minimal role. there is a lot at stake, ships aren't cheap, so running is seen as the ideal defense (bookmarking your current location mid-warp, repeat a few times between in-warp points, and you have a unique spot in the system to run to that no one can reach without scanners and such) when the odds are unfavorable.

for a dogfighting / space brawling scenario, i would like to have that scale of movement but the fighting itself must not be seen as easy to escape by fast travel of some sorts (tactical modules that allow this are fine though, cloaking, micro-/combat-warp drive, etc...).

the FTL method i suppose doesn't matter so long as for whatever reason it needs to be highly specialized to use instantly or at convenience - ie, normal usage must have a high price. a FTL means is necessary if the combat speeds are going to be relatively tame (ie, will take hours if not days of gameplay time to cross the entire game space, that sort of magnitude) this much i agree on.

as for containment, i would say that leaving the solar system will not be a safe option - the heliosheath i think ought to be lethal to pass through, at least it would interfere with the ships electronics and the radiation bath from extra-solar sources combined would ensure death sooner or later. to that effect the FTL means to travel is infrequent and tactical; some sci-fi have jump drives that need a long time to recharge, im looking at a similar direction here (say every 5-10 minutes with it pre-charged on launch, variations of it will play with distance vs re-charge time with the max charge amount controlling max distance, but all charge is used per jump / travel, and so on)...

keeping the bookmarks thing from eve is probably a step too far for mission-based games, but there will be a need for spawn point markers to warp / jump to as well as one for the main battlefield (think of the FFA beacons on the eve test server, if anyone has been there). planets and major bodies can be (should be) possible to jump / warp into orbit of.

again, the above is only applicable if the entire solar system is available at all times, with missions / battlefields occurring at random (or not so random) areas within it. those missions' action zones (for lack of a better term) will be difficult to reach or escape without FTL / fast travel mechanics, and MB currently has no restrictions on how far you fly from the action anyway (it is debatable whether this will be a problem in a fast enough paced, short mission-oriented games).

on a related note, looking back on some old notes ive found... i had plans for a command-line interface on the ship. i think that is overkill outside of MMO scales, but letting you know that ive considered it and thought of what it could be used for - controlling modules, setting module parameters, FTL commands, radio / chat / scanners / tech, etc... food for thought...

re manifolds, it may require a custom physics engine depending on the choice of topology (even portal had some problems resolving it, i believe they had a localized physics simulation around the portals on top of the regular physics to handle infinite corridors and such)... but i will say that having an infinite 3-space with finite volume, that is also large enough, filled with asteroids (like rock field), would be damn awesome to aimlessly (read, without objectives other than 'shoot down everything') dogfight in...

edit - in hindsight of re-reading all posts so far, id say this is starting to look like a better option than having a solar system to fly about in as well as ditching the FTL mechanic... (ive played a game a long time ago that had exactly that but in 2d with hovercrafts, no obstacles and a single machine gun, 2 player on the one PC - that was a fun game despite its simplicity)... thoughts?

the-anger wrote:re manifolds, it may require a custom physics engine depending on the choice of topology (even portal had some problems resolving it, i believe they had a localized physics simulation around the portals on top of the regular physics to handle infinite corridors and such)... but i will say that having an infinite 3-space with finite volume, that is also large enough, filled with asteroids (like rock field), would be damn awesome to aimlessly (read, without objectives other than 'shoot down everything') dogfight in...

I assume visual range will be bounded. To avoid strange optical phenomenons, you have to make the curvature small enough and the loops long enough.
I don't know, do you want to use an already existing physics engine ?

the physics become an issue when you consider how off-the-shelf physics will handle a manifold; most will assume that you're in regular non-looping space (i dont know of any that will do something different).

unless it abstracts the positional get functions, you will have to correct the physics model when it is out of step with the manifold (ie, if the object 'exits' the manifold it needs to be placed inside it on the other end, and so on). this is fine, but for collisions that could prove troublesome - one way i can think of is to change the collision detection code to be manifold-aware as well, but that may end up causing more problems than it solves...

and yes, an off-the-shelf physics engine/library is preferred, not writing one ourselves if it can be helped, it's an exercise in and of itself to do...

I love you guys

Abstractness wrote:

science wrote:Not bouncing off the edges or getting stuck in the corners of supposedly open space would be nice, but in the case of MB, it's a solution looking for a problem. If the action is behind you, turn around.

If we use a closed manifold the problem is solved: finite space without boundary.

A manifold solves the problem of boundary collisions, but my point was that MB doesn't have a problem with boundary collisions. The boundary has no effect on gameplay and so is entirely sufficient.

the-anger wrote:
and yes, an off-the-shelf physics engine/library is preferred, not writing one ourselves if it can be helped, it's an exercise in and of itself to do...

If you really want to do it, remember that permissively licenced open libs can be thought of as mutable templates in that you can modify them as the need arises. You would then have 3 options, incorporate the entire lib (often done) into your own source tree, fork it into a new project or make your modifications in such a way that they can be accepted back into the upstream project source.

Bullet is zlib licenced so there should be no problem there and it may be a better solution than using the release lib to make
some calculations only to modify the results to work with the manifold geometry within your own code.

ive had a good read through what panda3d and unity can do, and unity's entire game engine is structured fairly close to what i planned on doing initially using Lua. you can create behaviors as components, essentially event-receiving bits of javascript code, which is enough to implement the module ideas.

unless anyone can think of reasons not to use unity, or want another engine to be considered, thats pretty much what ill be using.

licensing... http://unity3d.com/unity/licenses

i don't have $1500 laying around (and i have no intention of asking for it) so free version looks to be it. i cant see anything immediately of use in the pro version anyway...

reselling
they only place restrictions about making games using mixed licenses, otherwise they allow you to sell virtually anything you make other than exposing the creator / a competing product. the other relevant point is that they obviously won't allow you to sell your game without limit using the free license; long story short, i cant use the free license if im making more than $100,000 US / year, regardless if from the game's sales or not.

for the time being i dont care on sales/pricing on this game - it just gets in the way, and i hope to keep it free with bonus, gameplay-unchanging content being priced (like skinning ships and such, exp boosting if it becomes relevant, etc). at the moment my view is that until there is a finished (or close to) game to enjoy, no one should be paying for anything in the game or for the game itself. and i absolutely refuse to discuss it any more than that lol, except to say that any decisions about how this game is priced (when the time comes) will not be done without asking everyone involved first.

models, textures, sounds, graphics, and so on are just imported, so anyone is free to work on the source files of those and ill re-import it when it has been updated.

the kicker is that anyone who wants to work on the game's internal mechanics using the dev tools will have to get their own version of the software and it must also be the free version (can't use content from both in one project). its a 500mb download.

now, honestly, when i asked for client programmers, they were to help build the 'player' program for the game. since unity provides that, it is much simpler if i keep the master files and work on them on my own. anything that i cant import is essentially the internal mechanics of the game (something i want to retain authoritative control over), and it is far simpler if there is one person making changes to that as it stands anyway. unless anyone feels otherwise?

feel free to challenge me on any of the above lol, id rather for everyone working on this to agree on what they will be working with...