Legacy:Mix/Developer's Journal

September 30, 2004

Been a while—yada, yada.

After the results were released for Phase 3, we decided to step back and re-evaluate. Duffers is going through a bit of a metamorphosis, and the core gameplay is changing. We haven't announced this elsewhere, but adept followers (are there any?) should realize that we're going totally mini-golf. We're also not aiming for a simulation, but our version of it. Duffers' previous incarnations were too simulation-y, and a poor one at that. We never intended for it to be that way, but somehow it happened. Now we're focusing on what gameplay we can accomplish with our limited resources, so things like player models are out.

Another change is that since we're only concentrating on "Putting", we're going to recode the physics for it. The previous system was more of a hack, and wasn't too concerned with collisions other than vertical (ball on ground). Now we're moving to a more general physics/collision method.

Also, the holes are constructed from modular 'set pieces' instead of being specific meshes. This allows us to spend less time constructing holes, and will allow fans to easily create new courses in UnrealEd only. One of the biggest problems we've had with Duffers is the skill overhead needed for course creation.

May 20, 2004

The biggest hurdle in porting Duffers to UT2K4 hasn't been physics, gameplay, or replication; it's been the GUI. Epic rewrote major portions of the GUI and it's been my task to get all our old convoluted menu code converted over to the new system. Some stuff works without modification, but I've had to rewrite the Settings pages and the Server Browser (which is the WORST, as the UT2K4 browser is even more complex than UT2K3's was, and that's saying something). There are things about the new system I like, such as being able to override styles just by creating your own style with the same keyname. That alone eliminated a lot of bad code I had to hack together to change the styles of things like moComboBox. The automated keyword addition makes GUI objects easier to implement. Makes me wish I had that functionality when I was creating the GUI the first time.

I think our initial release went well, even though the game is very rough. Feedback has been largely positive, with most commenting on the achievement of getting Golf into UT.

May 7, 2004

The Unreal Engine continues to amaze me. Not only were we able to code our own ball physics, it has come out fairly convincing. There are a few minor hitches, such as a slight pause when the ball switches from falling/bouncing to rolling, and sometimes the ball does a series of little 'bunny hops' when the velocity is low and the angle almost perpendicular. However, I am confident we can overcome both soon. What we don't have anymore is a problem with the ball falling through the ground. That's a huge relief.

April 15, 2004

We're moving, albeit slowly, towards a public release. Physics continue to be a stumbling block, as we aren't math gurus. I'm still confident we will pull it off, I'm just not sure how long it will take. What I'm worried about (and we haven't getton into yet) is rolling. Figuring out what the velocity should be based on angle and friction is going to be a bit intensive. And that doesn't even count rotation.

If anyone has some insight on ball physics and would like to lend some advice, we're all ears.

April 8, 2004

It's been a little while since I updated this journal, but for good reason. We've been incredibly busy with Duffers, trying to get it ready for a public release. I've started redoing the course, and the technique I came up with is working out very well. Each hole is made up of static meshes, and the edge of the hole is faded out to invisible. This allows the hole to blend into the skybox, and makes the whole thing look seamless. The hole, even though they share the same shape and size as the previous course, look much bigger, due to the larger surrounding area and open space. I need to redo the grass textures however, since I changed the lighting quite a bit, and that dramatically changed the look of the current textures. It seems like fixing one problem creates another.

Our other big issue we've been facing is ball physics and the tendency for the ball to fall through the ground. We thought we had corrected it somewhat, but we were still having problems every once in a while, especially on slower systems. Now our approach has turned to creating our own physics, and not just for rolling, but for the entirety of the ball flight. We're doing this so we have a more airtight handle on the ball and it also allows us to have more control over drag, wind resistance, and the hook/slice modifications we need to make to the ball. We've been having to read up on our physics calculations, but it's coming along. We initially had panned this idea since we thought it would be too CPU intensive, but UnrealScript has proven more capable than we anticipated, and there is only one ball per team in motion at any time.

It's just too bad that Karma couldn't handle this situation. We had big issues with multiplayer, as the simulation would deviate on the server and client. Updating the state resulted in jumpyness, and that's not something you want in a golf game. The last thing you need is for the client to see the ball drop in the cup but the server has it rolling just outside. We cannot afford to have a major discrepancy between the two.

We initially wanted our closed beta period to last only a week, then release a public version, but with these problems and the Easter holiday, that looks unlikely. I'm at the point where trying to nail down a date seems pointless. We'll just press on as hard as humanly possible.

March 23, 2004

Our weekly testing/coding session went fairly well this past weekend, but it didn't seem on the surface that we got much accomplished. We're at the point where the major stuff is working, and we're tying up the millions of loose ends that help it all work together seamlessly. Our Karma woes are less but not totally gone, as we've had some luck tracing every tick. One problem we have now is that the client can get quite out of sync with the server. You can hit your ball and it seems to go into the cup, but the server registered something different. That's bad. We're looking in to how to remedy this somewhat.

I need to get my issues taken care of (I'm handling interface duties) so I can get back to asset creation and my next major task: redoing the course for the third time. I've decided to construct it entirely out of static meshes, and contain each hole in its own "room". This will solve some problems for us, but you won't be able to see other players on other holes like we had initially planned. I think it's a valid tradeoff.

March 16, 2004

I decided to start writing a journal here on the wiki as a kind of suppliment to the blogging I do on mixworld. The wiki will hopefully allow me to get some feedback on the problems the team is having on our project Duffers Golf. I'll keep this journal strictly related to UnrealScript and UEngine discussions, and relate other thoughts on the blog. Blah blah blah.

Anyway, the current problem we're having is with collision. Maybe we're UnrealScript newbies (which in a way, we are) but we're struggling with the ball flight. After much trial and error, we settled on a solution that has the ball using PHYS_Falling for the main part of ball flight and when it slows to rolling speed, switching over to PHYS_Karma. It works reasonably well about 90% of the time, but under certain conditions (slow machines, weird angles, etc) the ball will fall through the ground. That is bad.

We know why it happens; Karma doesn't have prediction like the other PHYS_ types do. We saw this coming, and even toyed with the idea of using PHYS_Walking and scripting the rotation of the ball as it rolled, but decided it was too much trouble. I'm now thinking it might not be as much trouble. We're kind of caught in the middle. The other PHYS_ types don't do as much as we need, and Karma does too much (in a sense). I wish we had more access to make it work like we want, but that's the price you pay for doing a mod.

Foxpaw: Just thought I'd toss in my two cents.. The reason stuff is falling through the floor is probrably because you're using terrain for the ground, and terrain is a thin sheet. So, if an object is moving more than the size of it's collision hull per tick, it can be on one side of the terraininfo one tick, and the other side the other tick, without ever actually overlapping the terraininfo, which is required to collide with a terraininfo. There's no real "prediction" in any of the physics types, but most stuff in Unreal is moving slowly enough or is big enough that falling through terrain isn't an issue.

Fast moving projectiles in UT2003 trace from their current position to their last position every tick, to see if they intercepted anything during that tick. If they did, you can set them to the point they intersected and go from there. That is how they avoid travelling "through" things. Also, hitting BSP and some static mesh collision hulls will cause this behaviour natively, but not terrain, as you can pass through terrain without ever touching it if you are small and fast moving enough.

Mix: We're actually using static meshes for the bulk of the level now, and are probably going to switch over to completely using static meshes, but the same theory applies. I guess 'prediction' was a bad term to use. The problem is Karma doesn't do that natively, and we're worried that tracing every tick will be too detrimental to performance. What do you think of essentially coding our own 'physics' (as we still have to factor in wind and air resistance)? We're worried that it would be too slow.

Foxpaw: I wouldn't worry about performance if you're just doing the physics on the one ball. The tracing thing is done by many projectiles in UT2003, of which there may be dozens flying about at any time. Traces aren't particularly a "heavyweight" action in UT2003, though they were in UT. (Basically, they're not heavyweight on more modern machines) The exception of course is large extent traces, but a zero extent trace (a normal trace) should be fine for the size of the ball. I would stick with what you're doing now and just put in wind resistance and such by modifying the velocity of the object when in PHYS_Falling. Karma already has wind resistance and such, but you may need to adjust the amount of it.

Mix: So basically we need to add in to PHYS_Karma what the other physics types already have; ie, a trace to see if they passed through anything during each tick.

Foxpaw: Well, no.. The other physics types don't have that. But they can appear to because when they get moved internally via SetLocation(), (natively) if they are inside something else then they will be placed at the nearest possible location that isn't inside that. Non-Karma actors can fall through stuff too.

The thing with Karma is, Karma simulated actors don't teleport to the nearest non-touching thing. I would do what you described initially, basically use PHYS_Falling whenever the ball is airborne/bouncing (and thus take advantage of the "teleportation", and only use Karma when the ball has more or less stopped bouncing and is just rolling. You could implement something like the tracing done on projectiles with the Karma as well, like you suggested. That would probrably work. However, it will likely be somewhat more involved coding-wise.