My program doesn't have bugs. It just develops random features.
Legacy:Haral/Developer Journal
I've been working on 'Stellar Assault' (my favorite name so far) quite a bit lately. I've also noticed a number of people around these parts have been/are working on space mods of some sort. Lucky for me everything I do is off-track so this isn't really a problem other than that a bunch of people are doing mods of a similar theme and that usually results in lesser success for all.
So I'm at one of the least fun parts of development, at least for me. The foundation is in. You can board ships (translation still needs a little tweaking), fly them around, shoot the turrets inside. They have stabilizers to keep roll centered so you don't get too disoriented. There are all kinds of armor mods in, a bunch of turrets. The problem? Everything works, just not well. It's a clunkly concept demo that looks terrible. Even besides my very novice modeling skills, it's replication that's really getting to me.
I know UT2k4 is said to make improvements to the vehicle code, but I want to get things working now and oh man is it bad. The movement is jerky, the rotation is even more jerky. The turrets are equally bad. I don't know what I can do to smooth it out... I fear wading through the player movement code and seeing if I can take advantage of its nativity but even more I don't know if I can use it for this.
Another really confusing bit of awkwardness is the collision for my custom ships. Parts of them well, don't collide. I just used the simple DOP options. I use show collision in the game and it seems to be fit snug around the ship. But about half of it doesn't collide at times. It's got me confused.
Work work work.. I've done quite a fair amount of graphical stuff lately. New emitters for turrets, ship explosions, and shield impacts. Finally set up a basic HUD that displays ship health/shields/energy in bars. Threw in a targeting system that cycles through valid targets in range and highlights them with a circular bar representing their shield strength. Trying out different backdrop systems. It's starting to make a dent in this and is appearing more and more like a real mod.
So to follow that up I've been working on getting all of the tools to make a nice looking level so that I can put one together. I once again wish for multiple inheritance within unrealscript (PLEASE OH PLEASE) as I recreated a large portion of everything within my ship class and added it into a "Station" class. Stations are simply any boardable static mesh that does not move. Like a space station. Could also be a planet. These are not controlled by karma and are not pawns, so they take up fewer resources, which is why I went through the pain of putting in so many exceptions all over the place to account for both of them. Stations can actually move, they just cannot be controlled in any direct way. A level editor could add in a path of revolution or something and it'd work out dandy.
With this in place the entirety of the space portion *can* (doesn't have to be) represented by static meshes of varying scale. I am contemplating putting a handle on this within the level editor, so maps can have their own unique scale. This way maps can be made larger if necessary, or scaled to look right if the mapper wants the player out in space. There are other ways of doing that however, so I might just leave everything tiny. Hmm... more later, if I feel like it.
Still breathing. Still working. Cognizance questionable.
Mod almost pretty.
Ok well ignoring all the development I've done (as it's really not that interesting, just systematically tweaking weapons really) I'll go into a topic that kind of irks me: UT2004.
I came to ut2k3 more for the purpose of modding than actually playing. I played the demo and had some fun with it, but I wasn't really all that impressed or put off when I got the full game (a standard for me and recent games, sadly.) I've been having a great time playing the 2k4 demo, however, so they've certainly done a number of things right this time. I've taken a look at the script, however, and I am getting really annoyed.
The code for vehicles is so blatantly specific to what they've done it's kind of sick. Did they even stop to think about mods for a second? I mean, it's obvious enough seeing that every specific kind of vehicle is prefixed with ONS, but the script is cluttered with all kinds of things I don't want. I haven't yet found anything that will prevent me from using it, but it will be ugly and I can't play with it to see what happens.
Whenever I think someone else is going to work off of my code, I make a point and taking the most essential parts to my base classes and separating them from anything specific to what I'm doing. Isn't that really what object oriented programming is ABOUT? Honestly, though, they could seriously placate a lot of my concerns just by having ANYTHING related to physics (that is, any changes related to location (including velocity, accl) and rotation) that is done natively available from the actor level.
I am still mystified as to why they made the great move of having a controller class and then made it nearly worthless by restricting controllers to the bulky pawn class. Why not simply have a controller's pawn be a very basic child of actor which has added only full native support for player input replication? Epic has in their own code 2 obvious exceptions to their controller/pawn relationship: the Redeemer and vehicle turrets. Considering they seem to want people to make mods for UT* they should imagine that if they have 2, many more will emerge in user script.
I guess I'm mostly just annoyed at how long it's going to take me to adjust things to make use of 2k4's vehicle code.
A "brief" description of Stellar Assault
Stellar Assault is a team space combat mod. The teams have bases, and in those bases there can be terminals of various sorts. Some of these terminals are used for outfitting and deploying ships. For instance, you walk up to the terminal, see a pretty ship, equip a couple of firebrand guns and a burrfire turret, give it some armor modifications, and then deploy it. It then appears near the base. Before I go on...
SA takes a piece from one of my earlier mods and relies on 'batteries.' A battery is a very simple concept, and a flexible class in the script. It is simply an actor that has energy (and a max energy) and a rate of recharge. Most everything in the mod works off of a battery (and they usually share batteries.) This includes 'Inventory Terminals' which can issue weapons, turrets, and possibly player respawning as well.
Ok, so now the entire reason I'm making this mod. The primary concept behind this is that you can move around in these ships. The ships can fly around in space, and you can run around in them. The primary reason to allow this is for the possibility of boarding and combat on a ship. I later realised this opens an entire new world, which I'll go into in a moment. So I needed a way of boarding ships that could be done in hostile encounters and in basic setups. What I came up with, is the 'boarding turret.'
Ok, now it might seem kind of silly, but the boarding turret shoots a projectile which is effectively the player. It will place the player in the first 'habitable' area in comes across, and if it doesn't find anything within its range, the player turns into a glob of exploded bits in space. It's pretty easy to hit a ship sitting still or moving slowly–the projectile moves quickly. It's difficult to hit a ship that's maneuvering, so boarding isn't exactly easy. What I'm hoping (and it looks like it's worked) is that this will create a fast-paced way of merging standard first person and space combat.
In order to use a boarding turret, your shields must be down. Shields play a pretty big part, they are beneficial and detrimental. Besides protecting your ship from damage, shields provide a signature for certain projectiles to lock onto, will cause some more deadly projectiles to simply disintegrate, and make you easier to track. There's good and bad there, the trick is knowing when you want them up and when you don't. Taking them down is instant, bringing them back up takes a few seconds.
Now, for those who might be curious how exactly it works having a ship flying around that you can move in, it's actually pretty simple. The place the player moves around in doesn't move, it's just your ordinary subtracted space sitting in the level. However, in the center of it there's a marker with the ship's name on it. When the ship gets hit by a boarding projectile, it uses the marker's location to translate that hit into relative coordinates and finds the location to translate to. So there's your ordinary karma space ship flying around, controlled by whoever is currently at the helm inside the ship.
Now, what this means is actually pretty rad. This allows for big mobile carrier ships which can deploy other ships. A possible gametype I've thought of is simple 'carrier wars' wherein both teams start with big, beefy carrier ships and just have to destroy the other team's carrier.
There are some nitpicky design issues left to be wrestled with, but all in all it's set up.
All the cool kids are saying...[edit]
Foxpaw: Hmm. That's nifty. It sounds kind of like my mod, only different in some ways. The walking around inside ship is implemented differently on mine, and the customization of ships also sounds different. Also, I like the notion of shields having some negative effects as well as positive.
I would recommend adding the 'carrier wars' gametype you described. The first gametype I made (and so far the only one) was "Carrier Assault" which is very similar in concept.
Anyways, is there anywhere this mod is availible for download, or even just screenshots? I'd be interested to see how the interfaces and gameplay and such are in comparison to mine.
Haral: Hrm... This is about the only thing worth showing:
@block@Haral-SA-01 Ship Deployment GUI. The skin of the ship in the preview can change with your selections. Black Heat Generator will turn the entire thing black. Also, 'Frenzied Peacock' is the name of that instance of the ship. Fighter is the model (called Ridgeback now.) The name is set in the level.
An actual download is really dependant upon getting controls in netplay smoothed out and getting some half-decent skins and levels. All of the gameplay is there but there's not much to display until I get it polished.
I don't know much about the specifics of your mod... I took a look and noticed your mod is so pretty it makes me jealous. If you want we can chat and compare notes, though.
Foxpaw: Netcode, you say. Does it have bot support? I haven't done anything network-related really on mine yet - though I might get to that point soon. So far I've been focusing on botplay mostly. (intelligently avoiding impacts with other ships was trickier than I expected, but my solution is explained on my developer journal if you run into the same issue)
I haven't really tried netplay yet, though I've heard Karma actors are tricky to replicate properly. I had an idea but haven't tried it yet - I was thinking, the ships could be simulated Karmically on the server, and the clients would have a "proxy." The ships would not actually be replicated, but instead feed info into a "replicationinfo" type of thing. The client would then take that information and use it to display a ship with the same static mesh and such, but it could interpolate and extrapolate movement instead of using Karma on the client side. I'm not sure if this would work or not, but it might. I made a "stand-in" system because things farther than about 60,000 UUs don't get rendered, and lots of stuff was that far away or farther in my mod. The "stand-in" uses something similar to what I just described, except of course it's in a zero-lag environment. Basically, the server keeps a "real" version and a mock-up that imitates the real version, and the mock-up is the one that gets replicated.
Anyways, don't know if that would be helpful to you or not, but it's just an idea. If you try it, let me know how it turns out.
Haral: Well, if the simulation could be good enough, that could be a brilliant way to take load off of a client. I'm sure you know that karma is expensive. However, part of the issue is that karma and normal physics are just so different that the simulation would be weak at points no matter how good you 'fake it' with your client version. When you bump into another ship, for instance, normal physics dictates you stop, karma physics dictates you bounce and roll like crazy.
I do not have any plans for bot support. It's "possible" but I feel it's a choice between a great multiplayer game and an okay SP/MP game. Making bots that shoot, dodge, and move realistically is hard enough, especially in a ship. Making them decide between flying a ship, shooting weapon turrets, boarding an enemy ship, outfitting ships... It's possible. In fact, part of being me means that just considering it I have a bunch of possible code for it in my brain now. But not right now.
The whole distance thing is an issue no matter what (I discovered it the first time I tried to make a level) but I have power in deciding the scale of the game. The 'insides' of things and space can be made segregated, since effectively I'm just dealing with little model ships and stations anyway, so I can make them whatever size I like. At the same time, I want this to take place in open space and not restrict level size more than it is already, so I figure I will need to use fog. Also, I need to look into placing warpzones or something at the edges so that space never actually "ends." I wonder if this would kill the engine.
Foxpaw: Using fog is a good idea - I tried that and it looked very good for small craft. The problem I had with it was that large craft were easily visible from far past 60,000 UUs, so covering it up with fog made them not fade into view until much later than expected. One side-effect of using fog also, is that your ships will fade to black or what-have you, even if the background is some other color. When I was first making a level I was using the sky ripped from DM-PhobosII and it looked like crap when something faded in from black, silhouetted against the red planet.
Having said that though, those two things not being an issue, the fog makes a very nice effect. As far as space ending, I wouldn't really worry about it, since you have a lot of room to use for a level - especially if you scale the ships down. Warpzones don't work like they did in UT, unfortunately, and apparently the framerate plummets if there is a skybox and a warpzone visible at the same time (maybe not relevant since the warpzones don't display anymore anyway ;) )
You are right that the simulation would not be too accurate during a collision using the mock-up system I suggested. However, the Karma system will simulate differently on different machines - so a ship may slide or roll or whatever in a totally different direction on the client than it does on the server - either way Karma can't really be kept 100% consistent between the server and client.
My idea with the mockup was actually not to simulate any physics at all - it'd just be a staticmesh with no bBlockActors, etc. When it collided with another ship on the server, the mock-ups motion would be adjusted when it's next updated. Because the mock-ups wouldn't be colliding, they wouldn't really affect anything in the simulation. The ships might overlap briefly while waiting for the update from the server, but this would only really be noticeable at very short ranges, IE if another ship hit the player's ship. (It's an update of only a few bytes, after all, so even at relatively high pings it shouldn't be noticeable.. I would think.)
One thing that you would need to do though is, the client's ship would need to be Karma simulated. This is similar to what the player movement code does: Basically, the player uses an "autonomous proxy." Basically, this means that actors using an autonomous proxy act as if they were the authority (server) version. They behave in every way as if they were operating in botplay, except when the server and client disagree, in which case the server takes precedence. The player stores it's movements and sends them separately - basically the server "takes the client's word for it" on matters involving movement - unless the server decides that the server version and client version are too far apart, and a correction must take place. This is important for the client controlled actors, because if your ping is, say 200, that's still a fifth of a second from when you press a button to when it responds. On other players ships and such, you don't need that kind of system locally because you don't know when they pressed the button and thus wouldn't notice any delay.
