Leaderboard


Popular Content

Showing most liked content since 05/22/2017 in all areas

  1. 2 likes
    Hello all. I've not written in a while, because I've met some hairy obstacles to overcome. In short, it's the thorny problem of collision detection, monster movement, and dungeons, as in my last post. But I think I'm getting there now. I realised I needed a bit of a rethink. I've ended up with a bit of a cheat, but one that seems to work quite well. The basic problem just to clarify is that UAS2 in its original form has no knowledge at all about the objects in the world. It can create a monster and tell it where to go. The client then tries to make that motion happen. But what if there's a wall in the way? One of two things can happen, first the monster can effectively ignore the wall (a set position command is sent), secondly, it can run towards the given target, and not reach that target because .. duh, there's a wall in the way. The first looks stupid, because monsters aren't expected to just waltz through solid objects. The second is a problem because it can't be detected on the server. The server can allow enough time in a measured way and put the monster into combat mode when it thinks it should be in front of the player, but it can't know if the critter had got obstructed. The original game of course was not very good with collisions, but at least it knew when creatures were on the other side of a wall. How to solve... Ideally, the server would have a map in front of it of all obstacles, and be able to navigate around them After a few weeks messing around with the cell.dat data, I realised I could partly solve the problem with information in cell.dat, but the overall collision would still be a problem without doing enormous work. What I ended up with was a system where monsters could navigate to an enemy by staying to the middle coordinates of a cell, which are always 10x10. This nearly always works, but is not enough on its own. My cheating solution is quite fun. I keep track of all clients last 256 positions, whenever the X and Y change by a whole unit or more in a wrap-around buffer. Then when a monster detects an enemy, it logs that position and heads for it using the centre-cell method. Once there, it goes into a sort of breadcrumbs mode. Since the player's progress must have been througoh genuine positions that exist, the monster can follow the same coordinates and landblock cells. On the way, it can try to shortcut those routes, and so if the player dilly-dallies, it will skip those points. It also breadcrumbs its own route back "home", so something like a long piece of elastic, it can wind itself back, again checking points which it's already covered, so it doesn't blindly go round in circles. And the advantage of this is it will work outside dungeons too (but at the moment there's a few hard-coded bits that will make this not work). I also managed to get monsters have weapons and shields. This was a variation of the code I used to equip weapons and shields for the player, and was actually quite easy. I added a field called WeaponsGroup and ShieldsGroup, a new database that defines which belong to which group. I made a new tool to make it easy to set these up. So there's a pile of options that say a skeleton can have, with a few types of shield and a few types of weapon (or none at all), and it randomly picks them out when the creature spawns. Another thing I've played with was the problem of human type monsters. For reasons I am still not sure about, creatures like Bandits, and Mercenaries (any human species) were coming out naked. This is weird because they were captured with their palette and textures saved. But replicating those isn't enough in UAS2 for them to show up. So I took a step sideways... I made it save the packet data it generates when the player makes a costume change, and then fed that back into the capture software (with a few changes). So it was a case of playing dress-up - making myself look like the Bandit etc. Then, exiting, and renaming the capture log data file. A bit of database jiggery pokery to assign the new captured data to the old entry, and bingo, one correct(ish) looking Bandit. I added some randomising to the outfits, and created a small tool to assist in setting them up in the database. So far have done about 5, more to do. Hopefully I can finalise some of the dungeon code this week, and make the combat correct. Then I can happily ditch all the old code that used to handle combat!
  2. 1 like
    I had to smile reading your post and thinking back to the 1990's & gaming. My first thought was "dude cd_noclip" haha! Sorry, Doom reference. With walls and collision detection coming together, are you ready to tackle the "Wi Flag" or threat/threat priority for mobs? I've always found threat/threat priority interesting in AC. your progress looks great. It will be awesome when all three emu projects are out there in prime time. Keep up the good work!