PSO Remake

[Glader]

For interested parties some of John Carmack's statements about the development of clientside prediction and physics rewind can be skimmed from his exchanges here:

http://fabiensanglard.net/quakeSource/johnc-log.aug.htm

More information on the authorative combat implemenation:

At the moment it's looking like I will be keeping a queue buffer of recent position and state information for NPCs and Players on the serverside so a timestamp based request can be made for an action such as an attack. This will allow pseudo-physics rewind approximations on a discrete level, continuous and smooth rewinds seem like they'd add too much computation overhead and may be overkill.

It's imperative that average latency between the given requesting client and the server is taken into account during the rewind. Supposing an average of 100ms for a player's request to hit the server and start processing then the request is essentially 100ms stale meaning it's likely the timestamp will be 100ms off and we'll have to rewind in the buffer somewhere around there to determine the result, you can imagine the complexity of the world simulation doubling at this point.

This also begs the question of how is it reasonable for realtime combat to take effectively 200ms to request and receive a response. The staleness of the request can be handled. Past player and npc states are buffered but the client has to predict these changes.

Obviously this can be hidden by animations, in fact now that I think about it the request to attack happens upon input and whenever the network queue is flushed... sadly GladNet leaves that completely up to the underlying Lidgren Library. The response isn't needed in realtime. If I swing a sword for immersion to not be affected I need to get a response from the server by the time the sword has cross the creature. I believe this can reasonably mask the delay caused by the authoritative input.

What about NPC attacks against the player? If using Unity's built in NavMesh and NavMeshAgent (no idea what I plan to use for pathing atm), even assuming fully perfect determinism that never strays even on state change somehow, the state change of an NPC, and thus pathing, will be 100ms off on the player's screen. I'm not really sure how prevent player's from being attacked by creatures that appear not to be completely in range. Keeping everything authoritative while preventing the simulation on the client from seeming unfair and broken is becoming complicated. I will have to figure out a solution to NPC's position being 100ms stale on the player's screen while a player himself may be in an attack range of an NPC and not know it because of this.

Thankfully I have time to come up with a solution until I face this problem.

[Stealthcmc1974]

Out of curiosity, have you asked around on the Unity forums about anyone interested in this project? And what version of Unity are you using (with or without assets from the asset store)?

[Glader]

Out of curiosity, have you asked around on the Unity forums about anyone interested in this project? And what version of Unity are you using (with or without assets from the asset store)?

Well, my impressions of the Unity3D collaberation forums is that it's rather a joke. I think projects MAY benefit from posting their after they've progressed. People are generally weary of multiplayer games. This game would not be well received since it technically infringes on someone's intellectual property. That is something I'll explore in the future, especially so if I'm still solo as I get deeper.

I use the latest version of Unity, I'm ambiguous about the version number for a reason though. It's best to, when you start a new project, to prepare for the latest version possible imo. I wouldn't start a project right now in Unreal Engine 3. That wouldn't make any sense since Unreal Engine 4 is very much alive. It would only make sense to stick with older versions if you are mid or near end of development.

As for the asset store. Previously to develop in Unity3D, and keep your sanity, you had to either write a couple things yourself or purchase them. NGUI was basically a requirement but with Unity 4.6 the builtin GUI has been replaced with a better event-driven GUI that is much easier to animate and decouple from game logic in general. An example of the ease of the new GUI check out the Youtube video on my first post. There are only 80 lines of code occurring there, for the outward honeycomb burst of white. If this was written in what people call OnGUI it'd probably be hundreds of lines and this is without any functionally yet. So many lines and animation would be... well I don't even think it'd be possible.

Also, Unity is great but its ability to serialize certain things to the editor can sometimes be lacking. Previous to the UnityEngine.Events namespace release, I think in 4.6, it was impossible to decouple code via Delegates, Action<>, Func<> easily. An asset I purchased allowed for serialization of these, as well as properties and interfaces and etc. It's a really great purchase and definately is nice to touch on interfaces in C# while in Unity which is rather tough to do well given the way it all works in there.

I'd like to avoid assets if possible. I've written my own networking library on top of Lidgren gen3 so I could avoid licensing costs for that as well as avoid being forced to close-source anything I work on networking related. There are a couple of things that can be done if I go open-source with the project AND use assets, which I'm sure any artist who parties up with me is going to LOVE to use:

SpeedTree
https://www.youtube.com/watch?v=fk1jOk7IxOA

and Substance painter
https://www.youtube.com/watch?v=1rwMCew2GEQ

All this must be taken into consideration. It's possible these products, tools and pieces might just not be pushed up with commits but that would mean components would be missing if someone tried to use the project. It's a tough call. There are closesourcd things I feel are required for high quality development, especially artwise, that may not allow for open-source or easy collaberation. I'm not 100% sure atm what will be happening in that department I guess.

Anyway, Unity 5 and Unity 4.6 make it much easier to avoid having to use closed sourced GUI frameworks and serialization assets, since unity has like a Delegate-like object that can now serialize to the editor.

[Stealthcmc1974]

Alrighty. I was wondering since if I was going to download Unity, I may as well use the version pertinent to the project.

[Glader]

Alrighty. I was wondering since if I was going to download Unity, I may as well use the version pertinent to the project.

Unity 4.6 would suffice to learn Unity in general, that would be fine to use imo.

[Chrysheight]

Speedtree is fantastic. I used to use it with Unreal. Plenty of tutorials on it. I do also recommend for any artists out there, check out the Quixel Suite. nDo, dDo, and Megascans are pleasing to use. Might set you back a bit at $100, but I promise it'll push your models to the next level if you know what you're doing. I also recommend any UI artists maybe check out Scaleform. Unsure if it works with Unity, but it's definitely pleasing to work with.

[Glader]

Hi again guys, Thursday is nearing thankfully and I'll soon have time to start coding up a storm.

This update is going to go over the issue of client-server simulation syncing/predicting; it's a difficult problem and potential implementation of the various Technique spells in Phantasy Star Online.

In the mean time I've been pondering how to solve the problem of getting the client to predict and display an accurate representation of the gameworld being simulated on the server. From what I've been reading Unity3D is not friendly to a setup such as this. I'm not sure if UT5 will be any better with this, it's not really a fantastic engine for rewinding a physics simulation since movement and collision are handled internally... although I guess I could try to rewrite this. That seems challenging. Anyway, that is certainly the hardest apsect of the project by far. Keeping everything seemingly in step will be tough, but if that is the worst a project can face I feel that it'll be fine.

Enough of that deary and complicated problem; let's get technique-ical!

Techniques seem to fall under 4 different categories:

1. Projectile
2. AoE/Aura
3. Melee (Yep, sorry to pull back the curtains but some techs functional almost like Melee)
4. Special

With the exception of two special spells they all generally follow this, and can be implemented simply. You may or may not be surprised to know what the most complex spell to implement is, I'll talk about that later.

Projectile

First, let's talk about projectile spells. Projectile weapons, which I briefly mentioned in the post about melee combat, are probably the most advanced combat mechanic in Phantasy Star Online in my opinion from a development standpoint. I'm not positive how I'd like to handle projects, I may handle them has delayed melee attacks or I may simulate that actual action of a projectile. It's generally best to fake mechanics such as this and provide the illusion instead though.

Projectile Techniques are as follows: Foie, Barta (with the exception that upon collision with an NPC it continues to project the full distance), Medgid.

While projectiles in general may be a small challenge to implement I can't imagine they'd be too much trouble in the grand scheme.

AoE/Aura

Let's talk about AoE/Aura spells, these are a bit more fun to talk about and I've already a plan for their implementation.

To explain how trivial some of these are, this documentation should be referenced. Honestly speaking to another programming today we joked about how easy it would be to write a single player version of PSO or write a version that just trusts the clients like Sega's version.

http://docs.unity3d.com/ScriptRefere...phereCast.html

Resta: It's a simple AoE/Aura spell that does a sphere cast, or radius check, outward to determine affected targets. Also targets self. Simple implementation in Unity (assuming I don't have to implement my own physics for the sync problem above)

Shifta/Deband: Just like resta, an outward sphere cast to determine hit targets including self.

(Edit: I've been told Anti can hit all 4 targets. I'd imagine it has a range but that wasn't mentioned in the post below I don't think)
Anti: I cannot recall if Anti was capable of casting on all targets nearby, if so just another basic sphere cast here including self.

RaFoie: This one is a little more interesting. RaFoie does use a sphere cast to determine hit targets but also does so from a given collier P where P is the collider of some targeted NPC. From that NPC an outward sphere cast is done to determine who is hit including collider P. RaFoie also has a component of distance associated with it of course too as it's a dual-component Technique. More complicated than the 3 above.

RaBarta/RaZonde: Another basic outward spherecast that targets all collided enemy colliders excluding self obviously.

(Edit: It's been pointed out to me that these debuff techs work like Shifta/Deband. My memory is obviously rusty lol)
Jellen/Zalure: Jellen and Zalure, I believe, function like RaFoie if I can recall correctly. They act in such a way that their travel time to the target is instance and a spherecast is done outward to determine affected targets including self.

Melee-like

That leads us melee-like spells. This may make you cringe to read a couple spells in PSO function like melee weapons I described on the last page of this thread. In fact, most are simplier as they only require a distance component.

Zonde: Zonde has a maximum distance associated with the spell, that's all it really has to it. Its travel time is instant and basically acts like a melee attack. Albeit with what seems like an absurd range.

Grants: Just like Zonde except it has a delay on which the spell actually hits. You could possibly classify Grants like a projectile, which projectile themselves could then be renamed to delayed actions, but Grants seem to function like both. It's a tough call but either way Grants only has a distance component, and a timer delay, associated with it.

GiBarta: GiBarta is the perfect example of a spell that functions like the melee system described on the previous page. GiBarta's components consist of a frontal cone cleave. Just like swords, they take into account facing and some distance component. The facing being used in conjunction with a defined maximum angle that essentially provides it with the cone feel of the spell.

Special

Well, at this point you may have some tears in your eyes because the Techniques you know and love have been shown to be nothing more than a set of cheap smoke and mirrors. Don't worry though, not all spells are just cheap smoke and mirrors. Some are Houdini level spells. I consider two spells to be in the special category with their complexity rivaling no other techniques.

GiZonde: I believe Gizonde works iteratively, it's one of the spells with linear time complexity. It could be implemented recursively but would provide no benefit really. Anyway, GiZonde basically combines the idea of a sphere cast on a target and foreach target in the spherecast that hasn't been affect by this GiZonde, cast Gizonde on it. This occurs until every possible target has been accounted for. This makes it seem like it's a giant spherecast but it's implementation is probably a bit more complex. Nothing that cannot be handled, the above implementation I describe should be good enough.

GiFoie: GiFoie is probably the most complex Technique hands down in the game. GiFoie creates a continous outward growing spherecast that ignores already collided NPCs after the first collisions. GiFoies affected area grows over time outward. It's interesting. It will likely be implemented as such. Just a growing spherecast overtime. With a max distance component and a duration component. Pretty simple otherwise BUT still one of the most complex spells.

GiZonde and GiFoie are probably the most complicated but still within reach to implement. Hope you enjoyed my breakdown of how these spells will likely be handled and implemented in the future.

Speedtree is fantastic. I used to use it with Unreal. Plenty of tutorials on it. I do also recommend for any artists out there, check out the Quixel Suite. nDo, dDo, and Megascans are pleasing to use. Might set you back a bit at $100, but I promise it'll push your models to the next level if you know what you're doing. I also recommend any UI artists maybe check out Scaleform. Unsure if it works with Unity, but it's definitely pleasing to work with.

Scaleform does have a Unity implementation but sets you back a 500 dollar license fee I believe. Scaleform is not needed thanks to the Unity 4.6 new builtin GUI. Worldspace GUI and animated GUI with rotation/swivel/etc is pretty easy to do now as can be seen with the titlescreen I made. That would have been impossible to do, at least reasonably, with OnGUI (the old GUI) and Scaleform would have been a help. But this is no longer needed.

[Stealthcmc1974]

What do you mean some TECHNICs work like melee attacks?!

Jokes aside, your explanations make sense as to how the TECHNICs work, not something you'd think about until starting a project like this. If you're going to fake the projectile TECHs though, it'd still be cool to see NPCs actually flinch and perhaps even be pushed back by these TECHs anyway (looking at you Barta). Depending on where the projectile hits should also make the NPC flinch differently. (I realize this sounds like physics 101 but I enemy NPC's didn't have that many animations in response to flinches and such iirc so I figured I'd say it anyway).

On a side note, I can't help but feel that Light and dark techs in PSO are underrepresented in PSO compared to the other elements 9Unless you count Resta, Anti and Reverser as light). Any ideas on what TECHs, if any could be added?

Lastly, who specifically do you need to help you at this project at this stage? Artists to be sure, but what kind of coders? Guys who can do some of everything or do you want the team members to be a bit more specialized?

[Glader]

Lastly, who specifically do you need to help you at this project at this stage? Artists to be sure, but what kind of coders? Guys who can do some of everything or do you want the team members to be a bit more specialized?

Until I finish my underlying networking library, should be this week, I say finish but I really mean get into a truly usable state lol... Anyway, once that is done a bit of worked is needed to flesh out the serverside. Several pieces and ideas from the previous PSO serverside I wrote will need to be reincorporated or rewritten. This may take some time, maybe a week but hopefully less. At that point any collaborators will generally be beneficial.

At the moment only really art could be done sadly. A GUI/UI artist would be especially helpful in these initial stages to get up and running, in much quicker time, several interfaces. The GUI could be done well before the networking, as seen with the titlescreen, and just implement the actual logic later. That I think would be most useful. 3D modelers, one possibly willing to work with UMA or me to produce runtime manipulatable models for characters would be nice. I think as far as enviroments go for test purposes it'll be written to use a single instance of forest for testing. No over world or anything during initial development and no pool of instances etc. This would only be for ease of testing.

A tool oriented programmer could develop some applications. If no one else does I plan to cut out RakNet's Autopatcher and p/invoke, after studying interop because I'm new to it, and get a patching system up and running with GladNet. Externally a cross-plat launcher needed to be written in either QT or a Windows form that can function on Mono. Other dev tools could be written, possibly editor extensions for Unity, but it's just the dirty work.

If you're going to fake the projectile TECHs though, it'd still be cool to see NPCs actually flinch and perhaps even be pushed back by these TECHs anyway (looking at you Barta).

Physics based animations are different but possibly doable. The issue with apply collisions and movements based on casted spells is that it's more likely to push the basic physics simulation/prediction the client is doing out of sync with the server. This would meaning an ugly snapping correction is more likely. It's possible though, small polish features like that depend on the resulting size of the team again. Days can't be spent on stuff like that otherwise.

On a side note, I can't help but feel that Light and dark techs in PSO are underrepresented in PSO compared to the other elements 9Unless you count Resta, Anti and Reverser as light). Any ideas on what TECHs, if any could be added?

I've spoken abit about providing a more interesting, and important, support class. I haven't gone into too much detail about how I'd like to go about this. Some game changing designs would change and I don't want to talk about it because it may give some players a bad taste in their mouth atm if they read it. I'm not sure if I've mentioned it but I'd like to expand upon the healing toolset a support class may utilize giving them a HoT like tool, separate from Resta, and an absorption mechanic. Something akin to an effective health increase heal that may absord damage or just transfer it to the support user. Who knows, these things are far outside of what needs to be done at the moment. I've not thought too much about the Dark toolset but yes I agree Dark could benefit from an expanded set of Techniques supposing they fit a certain task.

Edit: As for your question of specialization when it comes to programming. A project of this scope requires several didn't specialties. Every programmer has his/her forte too. Anyone willing to collaborate can speak to me about that and I'd be able to talk about work that would generally be related to their forte so they could decide if it'd be interesting or a good fit.

[SStrikerR]

Anti can affect all 4 players. As for Jellen and Zalure, are you sure they work like rafoie? I was under the impression that they were treated as outward moving spheres, but that their starting point wasn't the first enemy targeted, which is what I think you were implying. I thought their start point was the player's location.