Tribes 2 RPG - Ironsphere II Mod
Hello all,
Those with a keen memory (and eclectic interests) might remember a Tribes 2 RPG mod developed by the guys here http://ironsphererpg2.webs.com/
I had some fond memories of playing it when I was younger, so I have ported the source over to github for the purpose of continuing to play around with it
Those interested in fooling around with it, or just want to examine the design of another interesting mod, can find it here:
https://github.com/Jusctsch5/ironsphererpg
See the wiki for installation instructions.
Thank you all for your continued interest Tribes 2, and support of the TribesNext community. I wouldn't have been able to revisit these memories otherwise.
Those with a keen memory (and eclectic interests) might remember a Tribes 2 RPG mod developed by the guys here http://ironsphererpg2.webs.com/
I had some fond memories of playing it when I was younger, so I have ported the source over to github for the purpose of continuing to play around with it
Those interested in fooling around with it, or just want to examine the design of another interesting mod, can find it here:
https://github.com/Jusctsch5/ironsphererpg
See the wiki for installation instructions.
Thank you all for your continued interest Tribes 2, and support of the TribesNext community. I wouldn't have been able to revisit these memories otherwise.
Comments
I was also involved in the development of ACCM which I have a repository here as well if anyone is interested. That develop branch hosts some more recent adjustments I made to the mod since ... 1.4.0 I think?
If you're interested, I occasionally run and play around with my own version of the IS mod. I have both the original 1.3.1.2 version as well as the custom version I've been working on.
You can grab both of those here: http://www.phantomdev.net/Tribes2/ISRPG/
The main issue I saw with the codebase when I started messing with it was some very silly coding practices, not to mention it's littered with hundreds of absolutely redundant function instances.
A good sweep and clean of all of those would be the first step to fixing up the mod. I got started with some of that work in my custom version, and fixed up some of the more annoying problems in the code, mainly the zone position bug.
Also, one big thing that should be fixed is the random spawning of unnamed ScriptObject/FileObject instances that linger in the object list. If you can hunt that down that would be a welcomed fix.
As for the mod's gameplay itself, it's pretty solid and can be pretty damn addicting when you have nothing better to do, however the leveling scheme in the mod was kind of flawed as it had area "gaps" where you'd literally be stuck in one zone gaining slim to none XP, or getting annihilated in the next area by overleveled enemies. I fixed that in my custom version by adding new zones to bridge those level gaps, and tweak the other ones too.
EDIT: Threw up my own repository containing the code for my custom version if you'd rather not want to download the .zip package from my site (https://github.com/Phantom139/IS)
Silly coding practices is a bit of an understatement, but I agree. It's too disorganized on disk and in files, has too many mega functions that do too many things, doesn't properly leverage TGE's capabilities like objects or callbacks or RPCs, and there's a lot of code that just doesn't work or is never called. At least for serious attempts, it's probably best to start over by zealously stripping and reorganizing an "empty" T2 mod (see console_end.cs for where it all starts), then reimplementing the basics with the above pitfalls in mind.
On gameplay, the mod seems confused about what it wants to be and is still stuck in the T1RPG mindset of grinding for grinding's sake. Character progression involves grinding to gain XP for levels to get SP to apply to skills that are also skill per use and whose rates vary with class, which is some bizarre fusion of multiple traditionally distinct paradigms. The grind itself isn't very fun (see T1RPG being played exclusively by "bots" that literally stand still auto-stabbing around a corner at an enemy stuck on geometry), has no overarching goal or purpose, and zones/gains are designed for one player per zone in a multiplayer game. A cleaner identity with a purpose and focus on player interaction would work wonders.
On the other hand, I did see this testing framework written for T3D's version of TorqueScript. I made some minor tweaks to bring it back to TGE compatibility, but I haven't used it extensively enough yet to know for sure. So hey, we can have some nice things!
My limited time working with Torque 3D mainly showed that if you really wanted to make something advanced, then you were much better off writing an internal C++ representation of it, your possibilities at that point were only limited to what the engine provided for you, and what you were willing to install into the engine to get it to work.
Keen does have a great point that you would be much better off writing your own RPG mod from scratch instead of using the existing codebase. I only stuck with it to make some quick fixes and changes that I found to be enjoyable for some free time.
Recently, I came across Jusctsch's repository on github. My original plan was to host a server for some of my local friends and introduce them to TRPG (figured T2 would be easier on the eyes for them). While testing and messing around, I realized that T2RPG is unfinished. For example, I found that #hide just used line of sight instead of checking the vicinity for a wall, so you could actually hide anywhere just by looking at the ground. And there is no remort implemented. And there is an entire zone that seemed to be missing mobs.
After I fixed up #hide with a quick dab of trig, I got nostalgic for modding Tribes. I used to help work on a couple of Tribes 1 rpg server (Sinister's Wasteland and TvT) years ago. I'm familiar with the way T1RPG was coded. So I figured I'd try finish up T2RPG while I was at it.
I was planning on modding it with my friends' suggestions anyway. So getting the base rpg game up to speed isn't too far out of my way. If people are interested, I'll link the repository once I get a release schedule worked out.
Also, I may need some help with the art side of things, if anyone is interested. For example, the skeletons in the crypt are lacking in the bone department (they are just the default player skin). I'll try to reskin them (unskin?) myself, but it won't be pretty :P
Again, let me know if there's interest. I appreciate support.
Are you the same rJay from Tribes 1? If so, I remember you from TvT and Sin's server. I distinctly remember an rJay from TvT.
Made a ton of progress so far. The code is in a state now that I can make new content without having to worry about rewriting it later. Just yesterday, I made a ferry that an NPC pilots from town to town over the water. It's really just the Havoc transport turned into a HoverVehicle that has a low hover height that it can only operate over water (just like the 2 person boat). Thinking about changing up the class system in favor of something more attribute based next.
Yeah, you're probably not him then. This was back around 2007.
As for your question, Tribal IDE can help a lot. But it may not be what you're looking for. It's sorta like a Notepad++ made for Tribes.
The debugger in TribalIDE looks really handy. I haven't had much luck getting it to connect to a server, though
On the bright side, I learned a lot of things last night ;D
Update: I was able to find the particle editor for TGE, that was derived from the Tribes 2 editor. Still can't find the one for Tribes 2. Worse case scenario, I can just re-adapt the TGE one for T2. It'll just take some time, but at least less time than making one from scratch.
And tons of bug fixes and smaller changes I haven't mentioned. A picture of the new skill gui shown in the URL link below. I'd post it as a picture, but I forgot to shrink my resolution when I took the screenshot, so it's a bit massive.
http://imgur.com/Fu6PlgZ
For linear projectiles (e.g. the spinfusor disk), you can scale the initial direction vector. It's "supposed" to be a unit vector, but if you adjust that vector magnitude, the effective velocity will be scaled by that magnitude. You typically need custom onFire implementations for weapon image objects to be able to do that.
If you need to change direction of a projectile in-flight, you can delete it and immediately spawn a new one in a new direction at the same position. Just be sure to maintain your velocity vector scaling if you're also tweaking that. There was a photon missile launcher from Abrickofham that used this technique to create a seeking missile-like behavior with linear projectiles, and would lock onto the first user that got in range of it after it was fired. You might be able to find a copy of that source through searches, and I have a copy of that script.
If you need to create physics enabled projectiles, the Item class (used for the flag object in CTF, and for dropped packs/weapons) supports applying velocity changes. You'd need to do a bit of work to enable applying impulses from projectile explosions, but there should be sufficient examples around the CTF flag item code.
There were a bunch of threads on http://www.advancedmod.com/ that might have some interesting bits if you go digging.
The Construction community (including me) has also done some pretty sophisticated scripting -- really pushing the boundaries of what the game and engine was capable of doing (including binary patches to the game engine). I had code published for the entirety of my mod, but didn't bring that server back online since a move this summer. If you're interested, I could spend the time to bring that code back up in a git repo.
I didn't realize that scaling the direction vector would have that effect. I'll keep that in mind. And I hadn't thought of using items instead. That might make for some interesting ideas.
Off the top of your head, do you know if there's a way to create the ELF beam effect between two objects, without using a weapon image objects. I'd love to use that for some kind of life or mana draining spell effect. TRPG doesn't use weapon images for spells, which I'd like to keep it that way if possible. Worse case scenario, I could create invisible or super tiny ELF turrets ;D. I swear, Tribes scripting requires a "thinking with portals" mentality sometimes.
I'll need to host a server eventually. Since I changed how EXP works, I've likely borked any sense of dungeon progression. So Bot levels will need to be retweaked.
I'd love to make the world more player centered, like TvT rpg on Tribes 1. In TvT, players picked 1 of 2 teams (orcs or humans) which had bases on opposite sides of a large map. Both teams competed against each other for map dominance and resources. Players could also construct buildings and defenses. All the while still being a long term playing RPG with character building and world persistence (it was one long "match" that never ended). Problem is, this kind of RPG won't work with a small player base. So I'm going to try and strike some middle ground.
I have some grandiose ideas of letting players create their own towns and zones in game. One neat idea would be letting players build up their own domain or place of power, which would give them access to unique abilities, skills, bonuses, or what have you even when they are away. Ambitious, but I feel something like this is completely doable within T2. But it'd be far down the road.
I also have plans to overhaul the class system. And by overhaul, I mean toss it out the window (another thing TvT did). Instead, you distribute attributes on character creation, which determine your skill multipliers. When you remort, you get a few more points to distribute how you want. Classes will be something you acquire and can swap out. With their own independent leveling system and abilities (similar to job classes in Ragnarok Online).
Just a couple of ideas I've been toying with for when I start making my own TRPG flavor.
As far as the whole ELF thing goes, there is a turret_muzzle.dts that is very invisible that I used for flame-breath enabled creatures in my own T2BoL mod (it only casts a small, round shadow) that I never finished due to the Tribes 2 community more or less having gone down the drain over the last couple years.
It would be interesting to see how well a proper RPG plays out in Tribes 2. However, a clear issue that's next to insurmountable due to engine limitations regarding character control is that melee will play exactly like it does in Morrowind, which I've personally found to be insanely bland. Click like mad and hope you hit, basically. Ranged weapons were the same more or less, so the only thing that might feel like it's worth playing is magic. At least here we have the benefit of an actual physical sim regarding projectiles, but interactivity on melee is going to be difficult.
Low player counts is definitely a thing to deal with somehow. While you can definitely better design the gameplay to fit lower player counts, you'll still have to deal with sub-par artificial intelligence systems in place. Making a TRPG world seem more lively with placement of bots isn't going to happen without placing a lot of predefined paths and markers (what if you want bots to follow some specific paths instead of whatever the AI nav graph gives them, which also reminds me -- can you even generate a nav graph? I've had some bad experiments with graph generation and large maps). Tribes 2's movement and engage logic will serve as a bit of a hindrance because it's coded to assume jets & ranged weaponry -- and so the bots will have hardcoded routines to try and jump jet when they flat-out can't which could produce pathing errors where bots try and jet to get some place they can't. This will also produce bots that kinda run towards you and run away because the game's inbuilt engage routines have absolutely no concept of zero-range attacks. At the very least you might be able to use AI for random events like muggers and such, especially if you write your own AI engage routines that better handle melee (AIConnection objects have an aimAt method as well as a couple helper methods like fireWeapon to better manually control the bots).
You especially will need to use custom placed nodes if you want the bots to use any sort of vehicle (if there is any -- boats, horse & buggy, whatever there may be). Yes, the AI coding can pilot vehicles (try using setControlObject on an AIConnection sometime to make it control any vehicle type) but it's essentially not recommended because it's a very, very preliminary code that is thusly not nearly finished. Bot pilots will wiggle the ass-end of their vehicle more times per second than a twerker and they do not path at all -- they simply go straight to a destination location specified via setPilotDestination.
There was a whole AI enhancement project I was working on that helped with some of these issues as well as added things like sound reaction (well, faked sound reaction), visibile projectile dodging (only implemented for tracer projectiles), view cones, enhanced objective types & assignment, but I never really finished it. There might be some useful bits sitting around in it: https://github.com/Ragora/T2-DXAI
I'm not expecting much out of the AI in T2. For the most part, bots will primarily be dungeon obstacles. The AI in T1 was far more limited than T2, but they filled to role of mooks petty well. And a game with dumb AI can still work. Many people play Minecraft (even by themselves) and the AI is pretty simple. The challenge is making the RPG interesting in other areas. But don't expect Skyrim combat with AI. Or even Morrowind. Daggerfall might be pushing it as well.
I know what you mean by the wiggle that bots do when piloting vehicles. I ran into this while working on the ferry. The ferry itself is really just the Havoc transport, but as a hover vehicle that has a very low hover height (so it can only work over water). Looks kind of like a boat...just ignore the engines. I mapped out it's route in the editor using a specifically named SimGroup and Makers, and added some extra logic so that certain markers cause the boat to stop for a certain time, or align to the next marker before moving. Anyway, to reduce of the wiggle, I reduced the turning force on the boat, so the boat doesn't overcorrect. It specifically works well for a boat, since it's not unusual for one to turn slowly. The fact that I now have a bot driving a ferry boat is enough to make me happy. That was not possible in T1.
I still have so much to do on the base game though. Right now, I'm redesigning some of the skill code again so that non-skill based commands can use the same methods. And at the same time, I want them to use the same modular UI that I made. To make it more adaptable, I'm moving the text formatting info to the server side. So when a client connects, they are given the format and the skill/command information from the server. Each category of skills will use the same text format, so that should simplify things. Ideally, it will let me add skills easily on the server side, and have the UI take care of itself on the client. I got it mostly working so far.
On the AdvancedMod forums, Lt. Earthworm did create a set of physics crates by using the DTS shapes of different base scenery/crate objects instantiated as wheeled vehicles. In my variant of Construction Mod, I had the capability to "launch" mobile point bases (the actual vehicle objects) as seeking projectiles. Writing impulse based predictive guidance code for heavy objects is a bit of non-trivial linear algebra (especially in a language that doesn't have first-class arrays, or array parameters to functions), so getting good seeking behavior was beyond my capability at the time. There is some form of matrix API as part of T2/Torque (including M*M and M*v operations), but I never looked closely enough to figure out what parameters it expected or how it worked for building the matrices themselves.
I also did something less complex with wheeled vehicles for "destroyed" building objects in my construction mod: when a player deployable object was destroyed, I overrode the default deletion behavior to spawn an invisible wheeled vehicle object with a cubic shape in its place, and mounted the destroyed object onto that vehicle (which would disable its collision mesh... mostly), and would let the physics simulation operate on the wheeled vehicle type for a few seconds before letting the whole thing fade away and be deleted. This was posted on The-Construct over 5 years ago, but the thread itself doesn't seem to be loading: http://www.the-construct.net/forums/showthread.php?t=1996
I had better success with precision control over Item objects, including a system for generating dynamically controllable particle "fairies" that could be set/reset (by the owner) to follow any kind of 3D parametric equation (with coordinate origin either being the player object of the owner, or a fixed coordinate in world coordinates). Since their mass was low enough, linear intercept to target coordinates produced acceptable results (with an added counteraction of gravity). I also used a trick to mount an invisible "weapon" image to the (also invisible) Item object. This Item attached image had an attached particle emitter so that the particle trail worked correctly, and provided no other purpose. I used the turret_muzzle.dts shape as described by Ragora. You might be able to use weapon image "idle" sounds to emulate an ambient sound attribute, which might add control over ambient sound (in the same way I added a persistent particle stream) to an object that otherwise doesn't have that capability.
Biggest things you're going to run into are fairly small overall limits on network tracked objects in the simulation, and the constrained network communication bandwidth overall for simulation events. With a linear projectile, or a conventional seeker projectile, the parameters are transmitted to the client as part of the object creation, and the client side simulation predicts further actions with few/no updates from the server. When you're exploring any of these programmatic approaches, you need to expend a fairly substantial amount of bandwidth to keep updating the client simulation with the new parameters. The effects are noticeable with as few as half a dozen frequently updating (i.e. at simulation tick-rate) objects, and unworkable around 2 to 3 dozen.
There's also a limit to a total of 1024 network synchronized objects. We were able to work around it in the Construction community with a set of binary patches to the client and server sides (called Structural Infinity), along with a script I wrote to mirror static object state (construction mod deployable, specifically) over a secondary RPC pathway. A couple of years ago, Krash (my fellow TribesNext admin) enhanced this system to open a secondary TCP connection between the server and client to use as an out-of-band pathway independently of the ordinary T2 network bandwidth constraints -- the large burst of RPC commands in-band would monopolize all other uses of the RPC signalling channel (used for a lot of essential messages) and lead to sub-optimal user experience.
The thread (also not loading, can be found here: http://www.the-construct.net/forums/showthread.php?t=436) -- note that even with these engine workarounds on the networking side, we started running into other (mostly insurmountable) performance constraints around 20,000 objects. If you want to do village building and other persistent state at scale, be aware that the scale is going to be extremely limited relative to something purpose designed for that.
Would need to have a lot of stuff like that then to introduce the interactivity that's lost in a game engine that's designed for ranged character combat, not zero-range.
Problem is that you might need to rely more and more on the bots to fill in games with the less people you can get on board. There's only so much you can tune the gameplay for. A game with ten people in it and a large world may not work out for an RPG, so you'd either need to fill in bots or reduce the game world size substantially to make it more up close and personal for all players involved -- but then you start to detriment the RPG factor significantly. But again, this is less of an issue with the more people you can get on board.
As mentioned above, there's going to be a lot in TRPG's codebase that's going to need adjusted, rewritten or flat-out removed. This combined with a codebase that seems to have no concept of coding standards is going to make that an awesome task to deak with. Would probably require a good couple people working together to achieve any sort of overhaul on it.
Sounds like he could use an invisible projectile that's updated once per however many MS his sound plays (or any multiple thereof) and for each spawn just kinda direct the invisible projectile towards the visible one. Though there might be cases where this can cause that projectile to ram into something (the terrain below, you) before the next update, depending on how long the sound plays and what multiple you're using. If not that, then the actual sound source might seem slightly detached from what you're seeing. Though it seems like an actual sound emitter would be the best solution since that sound doesn't really depend all that much on velocity-based modification anyway:
new AudioEmitter() { position = "91.1828 -52.9183 96.3989"; rotation = "1 0 0 0"; scale = "1 1 1"; fileName = "fx/environment/drywind.wav"; useProfileDescription = "0"; outsideAmbient = "1"; volume = "0.25"; isLooping = "1"; is3D = "0"; minDistance = "20"; maxDistance = "1280"; coneInsideAngle = "360"; coneOutsideAngle = "360"; coneOutsideVolume = "1"; coneVector = "0 0 1"; loopCount = "-1"; minLoopGap = "0"; maxLoopGap = "0"; type = "EffectAudioType"; locked = "true"; };Pulled out of Gauntlet, should give a decent idea of how to use these. Will just need to setPosition it for each new projectile.