Jump to content
  • Advertisement
  • entries
    232
  • comments
    1463
  • views
    961886

Space combat prototype - phase 6

Sign in to follow this  
Ysaneya

413 views

Finally, getting somewhere!

The shots ( i'll try to no longer call them lasers ) have been fixed. They no longer pass through walls. I've also added the correct spawn position for those shots, in the center of each gun. Note that the current turrets have 2 guns per turret. On the Lancet, with 4 hardpoints, this generate 8 shots per fire..

The debrits are now functionning in network.
The balance / parameters still have to be adjusted.
I still have to implement the victory/defeat conditions, teams, player spawning, but it should not be too hard. I plan to do that today or tomorrow, and to add some basic turrets A.I. for the mines and the battleships.

I made a lot of progress this week end, mostly on the network optimisations. One major change is related to how the firing is handled. Before, each weapon was generating a packet ( basically saying: entity ID1, turret ID2, has fired ). Now, you can imagine what happens when two battleships ( 22 turrets each ) and 50 mines are all firing..

Instead, i now send packets on the "change" of firing state. A packet is sent when a weapon starts to fire, and another packet sent when a weapon stops to fire. In addition, the firing rate is taken into account so that slower firing guns do not generate more packets than needed. It seems to work very well.

I implemented a similar system for the state of each ship. Instead of sending the state of a ship ( which parts are broken, the hitpoints for each thruster/gun, etc.. ) every second, i now detect if a state is "dirty", and only send data for those parts of the ship that are dirty. Again, it makes a lot of difference for a battleship: i don't have to send the state of the 22 turrets when only one of them takes damage..

I still have to interpolate the positions/rotations with dead reckoning, but since i have some code to do that from a previous prototype, that shouldn't take too long.

Oh, and... :


Sign in to follow this  


14 Comments


Recommended Comments

I've only done some very basic DirectPlay networking, so forgive me if these are stupid points :)

Anyway, wouldn't the on fire start/stop messages invite problems with synchronization between two players? If a shot package is missed this shouldn't be a big deal, but missing a fire start message might be.

Regardless of whether or not packages could be missed, aren't you worried about timing issues since you only send start/stops and handle the rest on the respective clients? I had to change my silly little ShipHo game exactly the other way around, from start/stop events to 'trigger' messages specifically to combat this issue.

And one last question, wouldn't the 'burst' from all start fire messages cause some latency? Suppose a player clicks repeatedly to fire, you might be looking at some 3 start/stops per second, making for 3 * 2 * 22 = 132 packets per second for a single battleship. For a multitude of players and with other packets that have to be sent, this sounds like a potential bottleneck.

Just my 2 cents, since I'm interested in how you would solve this.

Share this comment


Link to comment
Quote:
If a shot package is missed this shouldn't be a big deal, but missing a fire start message might be.


Those packets are sent in reliable mode.

Quote:
Regardless of whether or not packages could be missed, aren't you worried about timing issues since you only send start/stops and handle the rest on the respective clients?


Depends on what you mean by "timing issues". Each weapon has a timer (to know when it can fire or not) both on the server, and the client's local version. That timer can be sent with each start/stop fire packet, and for every state packet (~1 second).

Quote:
And one last question, wouldn't the 'burst' from all start fire messages cause some latency?


Yes, but start/stop firing messages are only sent when a gun is in "able to fire" state. What i mean is this: if your gun can only fire every 1000 ms; if you press "fire" at t=500 ms, it'll send a fire message immediately. If you then stop to fire at t=750ms, then start to fire again at t=1000ms, your gun cannot fire again before t=1500 ms (500+1000). Which means that no packet is sent until t=1500 ms. Now, if the last state is "firing" at t=1500 ms, nothing is sent again. So, practically, you cannot send more packets than your gun fire rate.

Quote:
Suppose a player clicks repeatedly to fire, you might be looking at some 3 start/stops per second, making for 3 * 2 * 22 = 132 packets per second for a single battleship.


Yes.. and no. My implementation automatically merges the packets together. If all the guns are firing synchronously, only 6 packets (3 * 2) would be sent. Besides, you don't control directly guns on a battleship. I'll try to provide real network stats when the test begins.

Share this comment


Link to comment
That's quite a nice model.

I guess that hit detection is all done server side anyway so even if the lasers look a bit off because of latency then the hit detection will simply mark the ship state as dirty and update all the clients with the new damage states etc.

Very good :D

Share this comment


Link to comment
Thanks for the info, clears up my questions and I'm beginning to understand the boat-load of things I've been doing wrong myself :)

Share this comment


Link to comment
First stats:
- one battleship vs me in a small fighter ship. Battleship has 22 turrets, all independently animated, trying to target and fire at me. Damage is handled (my ship can break, turrets stop to fire when they're hit, etc..). My ship has 4 turrets that fire when i press the left mouse button.

Average: 550 bytes received, 990 bytes sent; 4 packets received, 14 packets sent (all stats per second).

Note that position updates are done at 10 fps. Which means that in your average second, 10 packets on the 14 are for the client to send its position to the server (this number will be tuned later). Which means that the cost of maintening the battleship with its 22 turrets all firing, is around 4 packets in sending and 4 packets in receiving.

Of course that's excluding other players, but i can't test that now since the test hasn't started.

Share this comment


Link to comment
Very nice screen shot! I take it that is the inside of a station?
What sort of scale is that at? I guess what I mean is how big is each little bay in the picture?

Share this comment


Link to comment
Quote:
Very nice screen shot! I take it that is the inside of a station?
What sort of scale is that at? I guess what I mean is how big is each little bay in the picture?


Yup, it's the interior of the space station (previously shown on the older screenshots). The central tube section is missing though.

The little bays are (for the biggest shown in that picture) around 100 meters long. Those are the places where each ship will dock.

Share this comment


Link to comment
Quote:
Yup, it's the interior of the space station (previously shown on the older screenshots). The central tube section is missing though.

The little bays are (for the biggest shown in that picture) around 100 meters long. Those are the places where each ship will dock.


This screenshot remembers me of a mod for Half-Life (1), called Earth's Special Forces. It's a mod about the Japanese animation series called Dragonball Z. As we know Half-Life is an old game and didn't support maps/levels bigger than a certain size. To solve this the developers from the mod made the player characters smaller. The effect generated by this is that you compare the character you see in front of you (3rd person) with the environment and you accept (without knowing it) the hugeness of the area, while it is in fact only 30 meters or so.

What I am trying to say here is, there is a very Very thin line between: believing you are in a big space while you arent, and being in that small space but the graphics can't convince ya.
This problem is known to more people than me, I'm sure. The makers of that mod did a very good job hiding the fact that you are just in a small room.

What I noticed when watching that screenshot is that I don't feel the size of it. Actually I also didn't experience the size of the prototype ship (posted earlier). And I noticed one thing interesting: you made several (I know about 2) movies that show us terrain from planets. The latest movie seemed most 'big' and I think it's because of the increased detail (mostly in texture). I really had the feeling of being at a real (big) planet.

Many movies share this problem and it's solved in a nasty way. As seen in the Matrix: Reloaded, a ship enters the underground city (wich is huge). But as seen in the Making Of we saw that it was recorded in a small room. The way they made it 'real' was by adding detail, and I mean a Lot of detail. I said it's a nasty way because we want to avoid this if we want to actually be able to play it on a normal game-pc.

But just to put our minds in gear, how to solve this? And is it really such a big problem, or will it fade away by what is to come (you know more about this then anyone else). Discuss.

==========
My personal suggestion is: add much much more random stuff (not really random) to the ship, planets, whatever, at least to the station. Add bridges, cables, lights, commercial-screens (that flicker and such). Just add add add. Perhaps it's doable for 'slower' pc's since we don't see 10 space stations at once. But I don't know about what situations the player can roll in (huge cities, 2 stations crashed as one and abandoned, collisions between stations and planets and seeing the remains.....) just add add add.

Share this comment


Link to comment
Quote:
What I noticed when watching that screenshot is that I don't feel the size of it. Actually I also didn't experience the size of the prototype ship (posted earlier).


You are completely right. There are many reasons for that. One of them is that screenshots don't work very well at recreating a perspective/parallax effect. The same scene, seen in real-time with animations, looks much better.

It's the same effect than some of the Mars photos released by the NASA, maybe you've seen them. A photo of the ground, with a few rocks in the foreground and haze/mountains in the background. Without any point of reference, there's no way to tell if the rock is a small rock of 10 centimeters, or a large rock of tens of meters.

Details make all the difference. I'm sure that if i showed you the same station, but with animations, and ships flying around, you'd suddenly feel its hugeness. Another thing that helps a lot to feel the scale is collision detection and physics. When you're really flying in a ship as opposed to manipulating a ghost camera, you really start to feel the structure..

Share this comment


Link to comment
As long as your brain knows what size to attribute to those details, that is :) - If there are recognizable objects (people, trees, windows), that have a realtively known size (tree size can vary greatly - a person's size is relatively constant) that can make you understand the scale of a ship, then when you later see that ship flying against a space station, your brain will have a notion of scale. If you don't have a notion of the size of the ships you're seeing buzzing around the station, then they could have been star destroyer size, or they could have been a couple of inches long automated repair robots, and the perceived size of the space station will vary accordingly.

Share this comment


Link to comment
That is all very true. That's why I thrust your way as you know and see more than we do. Still I noticed the difference between a 'newer' and an 'older' movie. And if you ever find out Infinity lacks this so-called 'schrapnell-content' then it's easily corrected ;).

Good luck (looking forward to your next update).

Share this comment


Link to comment
alexmoura's hit the nail on the head .. the best way to get across a sense of scale is to include objects of known sizes ... stuff that people can already relate to. Quite how that pans out for a spacestation set 10000 years in the future I don't know ... maybe some human sized walkways ... windows & doors of normal dimensions (I have a feeling the current "windows" on the spacestation are many meters wide) ... tricky ...

Share this comment


Link to comment
Quote:
What I noticed when watching that screenshot is that I don't feel the size of it. Actually I also didn't experience the size of the prototype ship (posted earlier).


I think Ysaneya has a point though. When you are able to move towards a 'dock' or a stardestroyer (or whatever), the perspective will provide a very important visual clue that is lacking in the screenshot. Also, if a turret from a destroyer would fill your entire screen when you're close, that ought to be an important cue as well [wink]

Another thing that might help to get the idea of the size across would probably be the cockpit. I don't know if Ysaneya is planning on that, but from good ol' WC3 I recall that it added a lot to the feel, compared to flying around without it.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!