Updates are looking great overall, extremely impressed!
Quick bump and short update of what's happening:
ATM I'm working on clans which are now handled as being a module, which is a more practical way to handle them when the server need them. The buttons and configs and what else have been identified and very basic features are coded which makes them sorta 'functional'.
Dirk has again delivered some awesome work; ranging from a command to reload modules ingame, to combat improvements and login features. (a more detailed post will follow)
Other than that, development might slow down a bit since we are both back @ parties, uhh.. I mean university .
Some pretty neat changes this time, but first of all I'm thinking of doing a public demonstration (Renting a server, hosting the software with some AI Players) this weekend. It's a publicity stunt, and the server will go offline after the weekend (Possibly the week) since it's a demonstration of what we've done.
These are now sent at a configurable rate (Eg, 30ms, 600ms, 50ms). The lower values make the server appear to respond faster to the user, because the update is sent sooner. This makes the server seem really fast and is an absolute delight.
Ordinary RuneScape tick systems are done by queuing requests and processing them every 600ms. This system, which does not conflict with the old system, will process requests immediately with a 600ms cooldown. So you can't spam click people to deal more hits, but you can click something and immediately have it take effect instead of waiting an average of 300ms!
I now keep track of the time that the ServerThread (Eg the primary one that controls the world) spends idling. Nice to know if lag is being caused!
AStar pathfinding improved
Much improvement, pathfinding now takes a rectangle using the start and finish locations as coordinates of its corners (Plus a buffer on either side). This means that the path doesn't search off into nowhere, wasting processing time for a highly unlikely path! Instead of taking forever to do 200x200 searches, it will (say) assume it only needs to do a 50x180 path search (That's 40,000 vs 9,000 tiles). Pathing to GameObjects will no longer allow players to interact with the object through a wall (Eg, stairs which are placed directly against a wall), and will correctly find a path to the object.
The new FastTickable has given an incredible boost in speed (Also due to the smarter path finding). The server is now simulating 2005 bots and 1 player, all actively moving, with only 40% load on the main thread. My standard Tickable implementation is still rather slow, but I know a solution for vastly improving it. (Cancelling Tickables right now is incredibly expensive, can be done very cheaply)
Combat now gives experience, and I've added a configurable formula for all combat attack/power/block components.
Bots / AI Players
Added, they're rather dumb right now but they will search for targets, equip their best gear, and find a bank whenever their inventory is full. They'll loot items, or run away when they're dying - They won't attack mobs they can't reach or are too high of a level, they'll wander the world and happily walk to varrock or falador (Though most don't make it far north of lumbridge or draynor, they get themselves killed). This required I add complex pathfinding, which uses stairs currently to go up and down Z values. Bots will go down to the ground floor if they "get bored" (Can't find anything to do) and then begin wandering.
And the finale, this is a screenshot of my MapViewer, server console and game client. Each purple oval is a player (The letter is the first letter of their name).
I feel as though hindering with the Runescape clock system will lead to negative effects in the future. Runescape's content relies on the pooling and processing of events that were queued within the 600ms delay. The whole idea is to allow for better efficiency and synchronization, not to prevent spam clicking. Having a half second delay for mob to environment interaction isn't really noticeable, and keeps the game steady and clean in regards to event processing. Plus, what's the design behind your "cooldown" code? I'm sure it's not improving overall performance.
As for the efficiency, essentially a timer object schedules the individual FastTockables for execution, with little overhead. Previously, cancelling tasks was very slow and done frequently which was costly but I have improved upon that and they're now cancelled in a few operations.
Be sure to check it out when I put up a live demo then
Looking good been following this since September, hmu with a PM if u need a beta tester or when you go live; thanks.
|«  HD-PvP: Making Pking Great Again! | 876 Matrix base »|
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)