Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stainless]

Yesterday was one of those frustrating days you get in game development. It's worthwhile talking about as it was a good example of the sorts of things that can go wrong even when you have been writing games for 40 years.

I noticed some strange things happening in the lighting and couldn't find a reason for it. So I decided it was time to add the debug tools I have been planning for a long time.

The first stage of that was to get the collision meshes into the game. Once they are in I can do a ray collision check allowing you to click on an object and have a debug menu come up.

So I modified the modtool to export the collision meshes and the game to load them. Then I added a debug line draw and added code to draw the meshes.

Game crashed.

I looked into it and the debug line draw had over 200,000 lines in the array. Should have been about 3,000. This made no sense. So I changed the code to only draw a single collision mesh with 84 lines. I had over 5000.

WTF.

I swore a lot, then had a coffee, then had a cig, then swore some more.

Eventually I realised what was happening.

The code is heavily multi-threaded. Two cores of the CPU are dedicated to rendering and asset streaming. The rest of the available cores are used by the game update.

The game update creates render command sets which are added to a list for the renderer to handle. The renderer keeps two lists, one it is rendering and one that the update is creating and swaps between them.

The thing I forgot to do was sync the update and render loops.

The update loop is running about 60 times faster than the render loop. So every time the renderer draws the list , it has 60, yes SIXTY copies of the scene to render.

I am not seeing one spitfire and 12 HE-111's

I am seeing 60 spitfires and 720 He 111's, just on top of each other.

And it's still running at 120 frames per second.

Man sometimes this job takes years off your life.

[Stainless]

Collision meshes in.

They animate correctly, but interestingly it looks like the tail wheel and the flaps don;'t have collision meshes.

One step forward, two steps back.... sigh.

[Stainless]

Added debug menu

[hello]

Wow, every time I visit this thread, another amazing step forward. This is one exciting project
Cheers!

[Pursuivant]

Collision meshes in.

They animate correctly, but interestingly it looks like the tail wheel and the flaps don;'t have collision meshes.

Probably not your fault.

A couple of years ago I did a lot of empirical testing of IL2 damage models and I noticed a number of minor collision mesh errors, particularly in the oldest models like the Spitfire Mk IX. In particular, tail wheels aren't modeled in a number of the models. It wouldn't surprise me at all if other parts of the aircraft were missed as well.

Additionally, for what appears to be a simple collision mesh there are loads of what appear to be extraneous polygons. The extra polygons might actually be damage modeling of critical internal systems, but if that's the case the DM is just wrong (e.g., cable runs modeled as simple lines and without modeling bell-cranks, pulleys and similar hardware, very crude and excessively large area covered by the internal parts of the wing cannon model).

Again, not your fault, but it offends my senses of graphic design, historical accuracy, and fair play.

[Stainless]

Again, not your fault, but it offends my senses of graphic design, historical accuracy, and fair play.

 

I love that. I often get into arguments with games coders for whom code has to be "good enough for the job".

My school motto was "good enough isn't good enough" and I believe that, when it comes too code, good enough often comes back to bite you in the ass.

I have just had to go to Kiev for a week, left the comfort and warmth of my home, food I enjoy, beer that doesn't give me a headache, to fix problems that mostly fit into this model.

One problem was known to the coder when he left Kiev, he just didn't mention it to anyone and hoped that it didn't get spotted by the games testers. Of course it did. Games testers love finding bugs and will go to extreme lengths to produce them.

The fix took me two beers to come up with and five minutes to code.

I think I will add to the modtool an option to generate a collision mesh for a mesh part, tail wheels are really important for the physics. Without it every landing will damage the tail of the aircraft.

[Pursuivant]

I think I will add to the modtool an option to generate a collision mesh for a mesh part, tail wheels are really important for the physics. Without it every landing will damage the tail of the aircraft.

FWIW, the same things I said about tailwheels also apply to landing skids, which also aren't modeled for some aircraft and which would have the same effect on landing/take-off as loss of a tailwheel.

A mod tool that allows you to generate new collision meshes for parts of an aircraft which don't have them would be very cool, especially for modders who create minor variants of an aircraft where some minor system is added or removed. It would also allow somewhat easy upgrades of existing IL2 models to include new systems, like oxygen, electrical systems, radios/electronics, or hydraulics.

The downside is that giving virtually any player the ability to mess with collision meshes and DM potentially compromises the game's integrity as a combat simulation. While there have been all sorts of squabbles about FM and DM for IL2 aircraft over the years, one of the sim's strengths has always been the tight control that developers (later mod teams) maintain over DM/FM. One of the things that ultimately killed the MS CFS franchise back in the day was the ability to cheat with both hands in online play by fiddling your plane's DM/FM.

[Stainless]

Hmmm I hadn't thought about cheating at all.

Will have to give this some thought.

I can immediately see a way to create a hash table for certain key aspects of the simulation as part of the match making for the online version which would detect gross modifications to things like weapon damage , ammo, etc.

Might be worth while starting a separate thread for discussion of what needs to be checked.
 

[Pursuivant]

I'm assuming that best practice is to build in security features as you go along to preserve the integrity of FM, DM, AI behavior, access to rare or advanced equipment, terrain and weather generation, and so forth, but I'm utterly clueless in this area. The SAS mod team are the folks to talk to.

For a "sandbox" type sim like you're designing there is an inherent tension between player freedom to modify the game environment as they wish vs. screwing over other players. Obviously, cheating is no big deal for offline solo play (other than people posting and complaining about videos of grotesquely modded aircraft on Youtube), but it's an absolute deal breaker for online and/or multiplayer play.

I think the best ways to deal with stuff like that is transparency (i.e., make it hard to hide evidence of cheating) and having a "referee" who can lock down certain aspects of the sim during multiplayer play.

Depending on how sophisticated you get with FM and DM, you might also be able to have unchangeable elements of the game which are based on a given airframe's physical model so that cheating becomes impossible. For example, any attempt to soup up the FM of a Sopwith Camel to give it the flight characteristics of an F-16, or vice-versa, is inherently doomed to fail because the airframe of a Sopwith Camel or F-16 will still "fly like it looks" rather than "how it's programmed." Even with the Sopwith's engine output and mass fudged to mimic that of an F-16, you might still have problems with landing gear collapse, extremely long takeoff run, huge turning circle, lack of fuel tankage due to smaller volume, and so forth.

It might also be possible to build hard, realistic limits on historical aircraft performance into the game, with limitations to things like construction methods, drag, fuel consumption rates, compression ratios, or power/mass ratio for engines set by year. That way, if you really want to fly something that looks like an F-16 in a 1918 scenario you can do so, but its still going to behave like an aircraft built in 1918 - that is, not very well at all.

Conversely, if you want to fly something that looks like a Sopwith Camel in a 2018 scenario, but which is made with state of the art technology, you'd get something much better than a 1918 aircraft but that's still no match for an airframe designed to take full advantage of modern tech. (That said, being able to model duels between modern kit-built imitations of historic aircraft might be fun, especially if you've always thought that the Oshkosh Fly-In would be more interesting if live ammo were involved. )

[Stainless]

The way I see multi-player is that it would be set within a time frame. So you would have various modes but the aircraft within each mode would have a set time frame designed by the host, not the game.

The host may decide to allow a very large time frame of course, but if you don't want to take on a F4 with your P47, don't join the match.

Flight dynamics will be very difficult to cheat on. Flight models are not programmed. They are derived from the air frame and it's materials. So I think some kind of moderator who has access to a database which is read by the multi-player code containing hash codes for "approved" air frames will solve all that. Does mean that someone has to be a moderator and control the database though.

Giving the host of the game a "kick him out" button is something I will have to think about. If the host was someone like Mike, then it's a no brainer. Give him the button. However if the host is a twelve year old who spends most of his time on COD telling people what he did to their mother last night and how mush pot he smokes....... probably not.

Needs more thought

[Pursuivant]

If the game, or important features of it, must be hosted on a server for multiplayer then it makes sense that the server owner is boss, no matter what their maturity level. "My server, my rules." Regular old analog social dynamics can take care of the rest.

For long-term multiplay, it might make sense to allow the server host to designate certain players as "trusted users" or "power users" giving them some or all of the powers that the host has. Likewise, the host could "downgrade" standard user privileges to give certain users "provisional" or "probationary" status.

For example, a power user designated as a flight instructor could be given the power to alter aspects of a given training scenario, either before or during the scenario, while a provisional user might be limited to just flying certain scenarios or certain planes.

User privileges or restrictions could be set up to last for a certain period of time, when performing certain tasks, or when running certain scenarios.

For example, violations of certain rules might result in "time outs" of increasing length, a ban on flying certain (or any) aircraft, a ban on access to certain weapons or ordinance, or a ban on using certain game features.

If you want to steal from forum hosting or online auction software, you could give users the ability to "uprate" or "downrate" certain players, or even give "trusted users" a very limited ability to punish other users who violate the rules (e.g., a one time per day ability to impose a time out on another player, set to begin at some point in the future).

On the upside, giving users the very limited ability to up-rate other players might foster online reputations for sportsmanship and skill, which could translate into real benefits within the game.

For example, players could give a "thumbs up" to a worthy opponent or a particularly courteous teammate (or opponent). Gain enough skill or positive reputation points and you might get first pick of aircraft or crew positions available for a given scenario.

Finally, while it probably won't be built into your game as long as programs like Ventrilo or Teamspeak are available, one of the most elegant and humorous methods of dealing with trolls that I've ever seen is the practice of "dis-em-voweling" whr ll f th trll's ftr psts hv thr vwls rmvd. It not only messes with the troll's ability to carry on trolling, but it also instantly advertises their troll status.

[P51vsFw190]

Dis-em-voweling.....

I’ve never heard of that. That sounds like a phenomenal idea. Mind If I use it for my own purposes?


James