PDA

View Full Version : Still working



Nicholai Pestot
September 27 2013, 01:43:04 PM
Yeah I'm still plugging away at this.

We had some crunch time in work recently (big client that leads on to other big clients if we do it right), so a lot of my free time has been spent doing development work for my day job. What remains of my free time has been spent doing anything except coding.

That's over now, so I'm cracking back on with this.

Sp4m
September 27 2013, 01:56:46 PM
You better be.

Equium Duo
September 30 2013, 09:32:51 PM
Looking forward to the next update!

Nicholai Pestot
October 4 2013, 03:21:33 PM
It's coming along.

I'm using uLink under the hood to deal with networking (It lets me use unity logic on the server and is infinitely better than the terrible built in unity networking) and as always when using third party plugins there are…integration issues.

I'm using a component/system architecture in this game, which involves attaching data classes to in-game entities and then feeding my entities into logical systems that process them based on that data. This is a little different to the norm (which is attaching data and logic to entities) but it is in my opinion superior as it allows better organisation of logic and a much more modular approach to adding new mechanics.

uLink isn't too fond of this, as its automated network call-backs don't integrate too well with the top level systems I use. This has now been resolved, so I can continue with splitting the single-player logic into a client/server pairing.

Nicholai Pestot
October 10 2013, 12:27:25 AM
Connection handling has been dealt with, so I now have a server that will allow people to connect/disconnect gracefully. There is a (very) crude connection menu that lets players define a Name, enter a password and specify an IP/Port to connect to.

Players connecting now prompts the spawning of a ship for them, which is synchronised across the server and all clients.

The camera controls from the single player have now been re-implemented and the client half of the hotkey/interface has been migrated over.

Next up is dealing with the server half of receiving user input that is routed from the clients.

Nicholai Pestot
October 12 2013, 02:08:04 AM
Client handling of user input for movement has been setup.

Fixed bugs with movement synchronisation.
Fixed bugs with disconnect destroying the clients main game camera (don't ask).
Fixed bugs with disconnect causing null-reference errors on server.
Fixed bugs with rapid connection/disconnection causing inconsistent connection control panel behaviour.

Next up - server/client handling of shield systems.

Equium Duo
October 12 2013, 11:15:07 AM
sounds good so far

Nicholai Pestot
October 12 2013, 11:37:49 AM
It's getting there.

This morning rather than pushing on with the shield system I did a quick review of what I've already created.

I've setup some more refined logging of the existing systems that should allow me to more quickly identify bugs in the future and documented the existing systems/components/data so that a month from now I'm not left looking at this code going "wtf does this do?".

Now, on to the shield system.

Nicholai Pestot
October 14 2013, 09:44:00 AM
Modification of the shield system to work in a networked environment for the owner of the ship and the server is complete. The server is now correctly interpreting commands from users and applying them to that user’s ship. In return the server is correctly sending data back to the ships owner about the status of the shields, with all that being correctly displayed on the client side as it was in the single player alpha.

Much of this communication is just passing mode changes as and when a mode change occurs, but shield hit points are a continually changing variable that appear on a number of readouts for the user. In an effort to reduce bandwidth, I have set the shield hit points to only synchronise twice a second (and then, only if they change), rather than with every frame. One of my first optimisation passes (after the first multiplayer alpha test) will probably be to have a client-side approximation of the shield calculations that is re-synchronised with the server every second. This will further reduce bandwidth while providing a more smoothly changing interface readout. For now however the half-second ‘ticks’ of shield updates are acceptable.

The last thing I have to do for the shield system now is apply it to the proxy representation of player ships on other clients. As a player needs significantly less information about other player’s ships these proxy representations are going to have a more limited update procedure and slightly less frequent numerical synchronisations. The important part here are the visual cues that provide information about the status of other player’s shields. Everything other than that is just an added bonus that can be sacrificed to limit bandwidth usage. As the proxy version of the code is really just going to be a paired down implementation of the owner version I can easily copy-and-paste my way to victory this evening after work.

Next up (probably starting tomorrow though I may take a one day break) will be turret battery controls.

Nicholai Pestot
October 20 2013, 05:12:58 PM
Ohgodsomanybugs with that networked shield system.

Had an issue that was causing other peoples shields to flicker on/off on the client each frame.
Had an issue with shields initialising incorrectly if a certain combination of orders had been issued to someone else's ship prior to the client connecting.
Had a great issue with shield commands intended for the proxy being routed back to the owner (turned out to be a uLink issue, which I devised a workaround for).

All resolved.

Now, on to the turret battery controls.

Snottus
October 23 2013, 11:17:23 PM
How's it coming along man?

Nicholai Pestot
October 23 2013, 11:38:10 PM
I realised that the turret battery systems needs the turret system working first.

I have to be really careful with how I synch this as streaming rotational data about hundreds of turrets every frame(or even every few frames), is simply not viable.

What I'm working on is:-

-Rather than sending rotational data I'm sending target data and allowing clients to make their own rough approximation of turret rotations. Because the turrets are arranged into a hierarchical structure and parented to 6 directional turret banks I only have to worry about maintaining up to 6 targets per ship and even then, only when a user decides they want to flip targets.

-Whenever a turret actually fires a quick 'firing package' containing the servers reality of the target location/turret rotation is sent out from the server.

-The client takes the data from this firing package and then quickly synchs its local approximation of the turret up with it, before initiating a local simulation of firing.

Because the turrets calculate their rotations based off the positions/rotations of the ships and the ships themselves do have their positions/rotations updated over the connection, the local client approximation should be so close to the server reality that this doesn't produce a judder in the turret just before/after it fires.

So in effect the client will always be running its own local 'best guess' of rotational statuses that is periodically updated by the server (which holds the authoritative reality of what's really going on)

I'm still slugging away at that.

Snottus
October 23 2013, 11:56:18 PM
Cripes, sounds like a good and proper mind-fuck

Equium Duo
October 25 2013, 11:36:15 AM
You are a hero, is the "server" a standalone application or is it a client that acts as the server? If that makes sense?

Nicholai Pestot
October 25 2013, 12:31:19 PM
The client and server both share the same codebase/dev environment, but they have separate scenes assigned to each of them in Unity. When I do a build I include either the client scenes or the server scenes and that produces one or the other as an isolated executable.

The server runs as a unity instance, without any graphics/input enabled. One of the reasons I chose uLink as a networking solution is that it supports creating the server-side in unity. It's basically the only professional-quality unity networking solution that allows this and it is highly scalable - its designed to work with PikkoServer (by the same company) which is the networking tech supporting the upcoming Warhammer 40k MMO.

Client SOI issues aside, there is nothing stopping me plonking my server straight into a pikkoserver solution and having it load-balanced across dozens of physical servers, allowing it to process an MMO-scale environment. Given that one-man-MMO's just don't get made, that's not something I'm planning to do, but it's nice to have as an option :lol:


Once the MP Alpha is ready for abuse by forumites, I'll sort out some hosting to hold a death-match style test of the environment. I won't be throwing out the server for others to use until I at least have some form of version tracking integrated into connection negotiations.

QuackBot
October 25 2013, 01:00:12 PM
You are a hero, is the "server" a standalone application or is it a client that acts as the server? If that makes sense?
If i have to spend stupid amounts of points to do it standalone.

Nicholai Pestot
October 25 2013, 01:07:54 PM
You are a hero, is the "server" a standalone application or is it a client that acts as the server? If that makes sense?
If i have to spend stupid amounts of points to do it standalone.

Tell me about it Quackers. Tell me about it.

Rami
November 20 2013, 02:19:05 PM
Nicolai, are you sharing codebase? With the holidays coming up I feel guilty for not having paid more attention to this subforum (in my defense nobody poked me and I forgot about it for ages). That does imply the code is visible to other members who help out though. Happy to pay for a secure git if needed.

Nicholai Pestot
November 21 2013, 12:40:58 AM
I'm not sharing the codebase at the moment.

I did ask for coding help at the start, but no-one stepped forward to assist so I didn't bother setting stuff up for easy cooperation :(. Since then I've purchased some additional third-party add-ons so I'm going to have to go over their license details to see what impact that will have.

With the arrival of my first born son 3 weeks ago I've been a little slack on the coding and have done nothing since the 29th of October. I'll be diving back into this again in a few days so I'll see if I can sort something out then.

Rami
November 21 2013, 08:44:03 AM
Roger that, unfortunately as this is a subforum in a subforum my front page doesn't show it (and I generally venture into gen. games only). Consider this an open offer, for when you feel ready to take on some extra hands :)

Congrats on the newborn, best feeling ever c/c?

Snottus
November 21 2013, 01:39:09 PM
Yeah man, congrats!

Nicholai Pestot
November 28 2013, 03:16:04 PM
Right, now that everything has settled down a bit after the arrival of my child, I have picked this back up again. A few hours running back over my notes and going through the code and I’m back up to speed with where I was before. Proxy-turret-targeting-packet funtimes.

I’ve had some offers of help from a few sources, both within scrapheap and without, so I’m going to be sorting out a wee meeting so everyone who wants to get involved further can come have a chat.

If you want in on the meeting than either post here or PM me with your skills, experience, what you are interested in doing and how much time you are willing to contribute on a weekly basis.

Nicholai Pestot
January 2 2014, 09:12:35 AM
I had an overwhelming number of offers of help both from here and other sources that know about my little project and have now finally gone through them all and let the people who can contribute know who they are. Iíll be contacting them shortly to organise a meeting time. Thanks to everyone who offered Ė Iím just sorry I couldnít bring you all in.

From the development side, the alpha multiplayer is now almost done. Iíve been derping around with my local test rigs and have multi-boxed a small fleet fight (10 ships). All the functionality from the single player is now there, I just need to do a bit of debugging and alter some mechanics that donít suit a multiplayer format.

Last few issues I need to fix

-Ships refusing to fire through their own shields. - Fixed. Error in shield layer flipping logic when performing LOS checking
-Shields not dropping when reduced to zero damage - Fixed. 'Immediate disable' logic on server was not replicating out the change in status/HP's to the client

-Damage meters not updating on the client - Fixed. Forgot to include logic for anything except fuel.:oops:

- HUD icons not positioning themselves correctly

Functionality that needs changing

-Death handling (currently a disconnect/reconnect is required to spawn a new ship)

Functionality I want to add
-Labels showing a personís name, based on their login name.
-A little message when someone is killed, showing who killed them

This is all small fry compared to what was required to get the turret/turret banks system working, so I should have a fully working multiplayer alpha available shortly for you all to destruction test.

Equium Duo
January 2 2014, 08:32:54 PM
A thought, maybe add a scene camera looking over the enemy fleet at a bit of a distance,. This could be what happens when you join the room before you click spawn + the camera that is activated after you die?

Nicholai Pestot
January 3 2014, 12:10:20 AM
Good idea. I'll probably throw that into a later iteration.

Nicholai Pestot
January 3 2014, 08:57:58 AM
So something's gone a bit wrong with my logic. Shields will no longer raise correctly. Now a shield will raise for a split second, before instantly bringing itself down again.

The most likely cause is the enabling of the 'immediate disable' network logic that brings down shields when the server detects their remaining hit points have hit 0. The RPC's that replicated this out across the network were not being called and I had to make some alterations to the server shield processing logic to support calling them at the right time.

I suspect there is a flaw in the server logic (rather than the RPC's) that is being a little over-zealous with the detection of downed shields and is not giving the shields a chance to charge themselves up before bringing them straight down. Hence the noticed bug.

Thankfully the shield system is well documented, so even though I wrote it about 3 months ago it should still be quite easy to fix this.

Nicholai Pestot
January 3 2014, 01:38:20 PM
New shield issue resolved.
It was due to a change in process ordering that resulted from some small server-side modifications. I was checking if the shield HP was at zero while still transitioning from a disabled state to a charging state, so the shield was forever assuming it had been burned down before it even came online.

So this leaves

Bug fix
-HUD target icon incorrect locations (I suspect the conversion I perform from world space coordinates to UI space coordinates have been slightly fucked by some alterations I made to the UI logic) Fixed

Modification
-Auto respawn on death instead of forced disconnect/reconnect on death (Wonít take long as I wrote a separate system to handle player ship spawning, so the ship destruction event can simply call this system again after a short pause)

Additions
-Addition of player name to HUD target icons (Small additions to ship spawning, proxy object instantiation and HUD target icon objects)
-Kill message popup (Small addition to ship destruction event, along with a new RPC call to replicate the message out and a new UI zone to hold the messages)

Nicholai Pestot
January 6 2014, 01:13:45 AM
Last outstanding development task is kill messages. Everything else is done.

Once I've implemented that, I'm going to be sorting out hosting for the game server and a teamspeak server.

Then it's just down to the organisation of real life and free time. The latest date the first multiplayer alpha test will be performed on will be the 12th of this month (Sunday) as I know I have that day free.

It may well be sooner if I can persuade my wife to look after my son all by herself one weekday evening and can get enough volunteers together at the same time.

Nicholai Pestot
January 6 2014, 11:03:54 AM
All done.

I'll be creating a separate thread for the test.