No I think thats one of the ones that hasn't been done, or at least hasn't been released. I definitely wouldn't be any help on a project like that, I have no clue about php, AJAX or mysql, and very limited html.
 
Yeah, that's a good point. As we're trying to bring to light a community project, it should probably be in C#
 
Hmm.. maybe not quite what you have in mind, but I do have a source to XML Spawn Editor that needs some work.. And could be expanded on some and re-released. Could end up with a wicked spawn program with more current features added to it from xml spawner. There are a few things that need fixed too. Its a bit over my head, sadly.. but would be great to work it out with others.

Could work out nice, having it back available, and with updated features :) Its all C# too. I could post a screenshot later of what it is, for those that dont know.. and for those that dont know, you are seriously mising out ;)
 
Honestly, if we're going to charge people for it I'd prefer to build something from the ground up. We've got a lot of suggestions on the table.. I'm not even sure where to start. Can we narrow it to a list of five we can all vote on?
 
A good old-fashioned democratic election with a diversity of choices.

++Does anyone else have a project they'd like to nominate to be voted on?
 
Last edited:
Hmm...after much deliberation with the voices in my head, I vote AI.

I looked into creating AI awhile back and found it dwarfed any project I've attempted so far. If it was a collaboration I think it would be more likely to be successful and complete.
 
Is the AI system intended to be a drop in replacement of the standard AI system? The current one doesn't exactly have low coupling.

The system can be complex but it should hide the complexity from shard operators. In game menus or reloadable XML are preferable over modifying code and recompiling.

Expanding the system or replacing underlying algorithms should not require modifying the entire system. A strategy pattern could be put in place to choose algorithm. If the system uses decision trees under the hood, it should be easy to replace them with Bayesian network / min max / neural net.

I personally would like to see a system with behavior that is conditional upon (or at least takes into consideration) current stats (STR/INT/DEX) and skill level.
 
I'm not sure what the system is supposed to be right now. At some point everyone who wishes to be involved will have to agree on what we want the project to accomplish and how.

++ Also if you're really serious about developing a neural/bayesian network - we've got a lot of work ahead. :)
 
I think it should be a separate AI system, but you have the base Melee AI and then a separate MeleeAdvanced AI
That way it also gives Owners/Devs the option to make certain Mobs smarter/harder beyond the simple changing of stats/skills
 
Let me give a more specific description on the AI system that I wanted to make. If you all think this is worth the effort I'd still like to try it.

Back when UO was first coming out, they had implemented an "Artificial Life" engine - completely different from static spawns. Here's a short description:

Nearly everything in the world, from grass to goblins, has a purpose, and not just as cannon fodder either. The 'virtual ecology' affects nearly every aspect of the game world, from the very small to the very large. If the rabbit population suddenly drops (because some gung-ho adventurer was trying out his new mace) then wolves may have to find different food sources - say, deer. When the deer population drops as a result, the local dragon, unable to find the food he’s accustomed to, may head into a local village and attack. Since all of this happens automatically, it generates numerous adventure possibilities.


A more detailed description can be found at this blog: http://www.aschulze.net/ultima/blog/blog_20090126.htm

I also wanted to make AI for town npcs that would be more realistic, like vendors for example would stop buying so much of a certain item if the local economy had too many of that type of item in circulation.

I've always thought the Artificial Life Engine would be more successful on free shards with smaller playerbases because players wouldn't be able to kill everything in the world fast enough to stop the AI from actually doing something cool, like an automated dragon attack on a town.
 
If I remember did they not find that during beta testing they found the Artificial Life was too good due t the population. So saying that lesser population ie free shards would be pretty perfect for this system for your above stated reasons.

If only I knew how to code it myself so I could help.
 
So I'd really like to start our project here, with the information from Vii's post.
The idea of reincarnating UO's originally intended AI really seems like an endeavor worth-while.

Edit: meh

As it were, I believe the list of people going to be participating looks something like this:

Jbob
Zerodowned
Vii
m309
myself

If there is anyone who wishes to be added or removed from this list, please let me know. :)
 
Last edited:
So I'd really like to start our project here, with the information from Vii's post.
The idea of reincarnating UO's originally intended AI really seems like an endeavor worth-while.

Are we going to have a Github project set up for this?
Also, I think it would be nice idea to have the main project as listed, and then other side projects that people can submit themselves that are still AI related.
Personally, I'm a fan of...I think Peoharen's Omni AI and I forget who do the additional Mobile abilities.
Anyway, I'd like to take that and expand on it some but shouldn't take much effort.
But also do things like expand on the Wolf Family script. If you've played TERA then you should be familiar with the Mobs that have one main "Parent" and a bunch of "children" Mobs surrounding it.

As for the main project, is it possible to designate a region on the world map, find say the number of rabbits, and if it's below a certain number then something happens.
XML maybe? I don't know, I've never touched XML but from what I've seen it seems like it's capable of doing that.
 
We will probably have a repository for svn on my friend's server. I'm not a big fan of Git. As I've always said, if you're doing it because it's easy, it's the wrong choice.

++ Cancel that, he was like "NO!" - so I guess we'll be using Git. Sigh.

++ I completely misunderstood what you were asking about XML - it could very easily record position data.
 
Last edited:
World automation and intelligence has been a long time fascination of mine. Despite the persistence I view MMO worlds as essentially dead, or better described as stuck in a time loop. The same creatures will spawn in the same locations, the npcs will sell the same crap at the same prices. Rain or shine, war or peace or the apocalypse itself nothing ever changes. GM staff can take actions to animate aspects of the game world but its a huge time sink. If the world can run itself then that can free staff to do more interesting things.

If its about picking a project, a well targeted AI project would be some pretty good bang for buck. So I'd vote for that.

If we are going to look at virtual ecology there are Three points to consider

1) Player characters break physical laws, as they do not require sleep nor food. Nor do they ever get tired or bored and can grind away at any activity for several days straight of game time. They also have the ability to warp time and space when perform certain activities, for example gutting a deer in the woods in moment. In order to get resources they need the player will gut every damn deer in the woods as there are no physical barriers to slow them down. Oh they also happen to be immortal.

2) The scale of the world is a distorted representation. We are dealing with a world that is way too small to properly represent appropriate populations of animals and people. We are looking at near extinction level populations if creatures were physically represented.

3) Time, it takes time for creatures to mature and then reproduce. Looking at point 1. players are essentially a force of nature. Imagine if lumberjacking involved cutting down the trees. You'd see the forests of Britannia totally clear cut and replaces with fields of chairs, shelves and tables where some guy was grinding carpentry.

These points exist for the gameplay factor, otherwise the game would be not so much of a game. So we have to work around certain details to get to the spirit of the experience we are trying to created. Some years back I experimented with a system that managed hostility between groups. These groups included both players and npcs (mostly) and came in all shapes and sizes, from bandit gangs to kingdoms. In order to make the system more interesting and to respond to player actions the relationship between groups was varying value from positive to negative. So negative action would lead to negative changes in relationship. A few players constantly picking fights would end up starting wars.

The realization I came to was that players represented a minority but in fact hand the effect of a majority. Its when I defined the points 1. and 2. described above. The solution I had in mind was counting the invisible majority. Basically what we see running around in the game would is actually be a subset of a far larger population / world. I gave up messing around with UO around that time and never explored this idea.

I believe the same thing should be considered for a virtual ecology, as in what we see is only a subset of a far larger picture.

In any case this seems like an interesting project.
 
My main goal with the Artificial Life engine was to make a world with little to no GM contact needed while making automated world events like town raids and such that are a result from players doing something like killing all rabbits in sight or mining out all ore in an area, something they didn't know would have consequences. This would also include new AI for various modes of combat and town npc AI. I am also a fan of the Omni AI - if we could use it here I don't know. But the overlaying virtual ecosystem would be something totally new that I think would be fun to figure out.

We have to draw the line somewhere tho on how close to real life we want to make this. It should still be a game that is fun for players so I think it's ok to ignore things like animals going extinct. But putting requirements on players such as requiring rest or food/drink is no longer an AI problem. That's something different that shard owners already have options to choose from in custom script releases.

I've never liked how the static spawners work. I've thought that maybe spawners should somehow communicate with each other and be able to change what they spawn depending on the world situation, essentially making dynamic spawners. I like dynamic systems, they are so much more useful. There may be a better way to go about this without spawners at all, using XML or something. *shrug*

My project never made it out of the design phase as it grew too big for me to do alone. I'm just rambling my thoughts down here so I can remember what I was thinking later and maybe some of you can add to it. :)
 
A more detailed description can be found at this blog: http://www.aschulze.net/ultima/blog/blog_20090126.htm

Raph Koster was the lead designer of Ultima Online at the time the artificial life system was conceived. His blog contains three large entries that describe how the system was supposed to work (very close to fan link at aschulze.net, but with a bit more detail).

http://www.raphkoster.com/2006/06/03/uos-resource-system/

http://www.raphkoster.com/2006/06/04/uos-resource-system-part-2/

http://www.raphkoster.com/2006/06/05/uos-resource-system-part-3/

One thing that I would caution anyone that is considering the implementation of this system is that ServUO normally deactivates sectors in which there are no players. This means that npcs / monsters do not actively execute their AI algorithms when the sector is deactivated. This results in a restful server that doesn't hog CPU time.

As I understand it, the Artificial Life system that was proposed would need to have creatures active all the time so that it could process the AI while the players are away. This could result in a lot more CPU usage if not done carefully.
 
Alright - so I've got to say, I think we're over reaching.

First, Vi, who I was hoping would take lead (since it's really a project that he's wanted to do for a while, and probably has spent much more time investigating than anyone else who volunteered) is inundated by work. You can blame our public school system.

Secondly, accomplishing such a task in a year would require all five people to work on it every day. Who's going to do that? Not me..

So, with that said - let's go for something smaller - a singular system. Something you'd value at around 29.99 per copy, hopefully we could sell one each month. That would cover the ServUO expenses and it could actually happen.
 
It is true that I get busy during the school year. That restricts my scripting time to about 1 to 2 days a week if I have a lot of grading. I'm also lead scripter of UORoleplay now and that takes up free time too. I have been sick for 3 weeks and had a family member pass away, so if I haven't been very active this month now you all know why.

Yeah, the Artificial Life Engine is a huge project and could be overreaching what we can do given the time each of us can offer. I'm not sure what you expected me to do - create a github for it and go from there? I thought we were just throwing out ideas to see what the community was interested in. I can still lead a project similar to this, I just needed time to recover physically and mentally.
 
New ideas..

1. A shard configuration gump system.. *Something like what Ryan of RunUO announced he was going to do a year or more ago, and was left empty.
2. Jail system *Still feel that this is something needed anyways, although not the most exciting
3. A nice Spawner Control system... *An admin like gump that holds as many functions possible within one easy gump.. however xmlfind does a lot already..
4. A complete, from scratch, spawned world. Not taking anything from Neruns, as it is just.. awful.. (imho). Maybe something else to go with this too?

Will keep thinking on some things too..
 
I like the idea of the gump system, or maybe just a installer system and you can choose what pre-installed scripts you would like, era, shard name etc etc and the installer configures the appropriate files. Once the installer finishes maybe move onto a wizard to configure any of the individual scripts you asked to be installed for your server. All the time making the edits required in the files for you.
 
Another idea would be a UOGateway/UOConnect website/application for listing, joining and patching servers.. Probably the most useful thing anyone could remake. This will bring in more old or new players as joining a shard would be so much easier than it is now having custom installs all over the place.
 
I agree with the UO Gateway system, but was already kinda mentioned, and the problem is/was the lack of PHP code experience for the web side of it.
 
A random dungeon generator would be fun to build.

The first cut of it could be a rogue like dungeon generator (think Diablo 1/2 style randomly generated dungeon maps) on a flat dungeon surface. These algorithms are well known and could be ported directly. Walls could all be dynamic statics. Shard owners could specify the bounds of the dungeon, and then use a gump system to adjust dungeon settings like respawn rate, difficulty etc.

Dungeons would be wiped periodically and regenerated.

Spawns could be randomly generated with random bosses and treasure tables. Bounds on random loot attributes such as props maximums for items, gold drop amounts, could be altered via gumps as well.

This type of system could be dropped into an existing server to supply players with fresh content.
 
A random dungeon generator would be fun to build.

The first cut of it could be a rogue like dungeon generator (think Diablo 1/2 style randomly generated dungeon maps) on a flat dungeon surface. These algorithms are well known and could be ported directly. Walls could all be dynamic statics. Shard owners could specify the bounds of the dungeon, and then use a gump system to adjust dungeon settings like respawn rate, difficulty etc.

Dungeons would be wiped periodically and regenerated.

Spawns could be randomly generated with random bosses and treasure tables. Bounds on random loot attributes such as props maximums for items, gold drop amounts, could be altered via gumps as well.

This type of system could be dropped into an existing server to supply players with fresh content.

Now THAT I'd pay for. With Ultima Live it would be very do-able since you could have an entire map dedicated to randomly generated areas
 
While I whole-heartedly agree we need something like UOGateway in our community, I don't think that's a project we should charge for.

I personally think the procedurally generated dungeons would probably go over very well. And, with something like that, there's so many routes, we all stand to learn a great deal in the process.

However, I don't see it working without UltimaLive due to the lag of unfrozen statics. Our goal should be to have no prerequisites.

1. A shard configuration gump system

Can you elaborate?
 
Last edited:
However, I don't see it working without UltimaLive due to the lag of unfrozen statics. Our goal should be to have no prerequisites.

Has anyone tried to pre-cache house data to the client? If it worked you could potentially just "load" a dungeon to the client house cache up front when the player changes maps. Then they would experience a loading gump, but not necessarily a lot of lag when they run around.
 
However, I don't see it working without UltimaLive due to the lag of unfrozen statics. Our goal should be to have no prerequisites.

I could have sworn I read somewhere that it's possible to freeze statics with UltimaLive...maybe you need to have streaming turned on.


Has anyone tried to pre-cache house data to the client? If it worked you could potentially just "load" a dungeon to the client house cache up front when the player changes maps. Then they would experience a loading gump, but not necessarily a lot of lag when they run around.

sorry, I'm not sure what you mean by " pre-cache house data to the client "
 
I could have sworn I read somewhere that it's possible to freeze statics with UltimaLive

I think you can. I thought that was the point of it. What I'm saying is, requiring someone to have it will inevitably lower the amount of people that would use it.

I'm not sure what you mean by " pre-cache house data to the client "

Basically, the client loads and stores nearby houses in a cache so that data isn't being constantly sent from the server like statics. You should see a place in your options that determines the maximum number of houses you want to cache - if I'm not mistaken. (Which very well could be)
 
Another idea for a community built system is to add support for instancing that is configurable and user friendly . I know the instancing part has been done before, this new effort would focus on usability:
  • In-game gumps to manage the system
  • Allow instance regions to be defined in game using gumps similar to custom-region-in-a-box
  • Have variable ways to enter an instanced region - clickable items, teleporters, etc
  • Lockout timers that only allow players to enter a region on a certain time interval - such as once per hour, day, week, month. This should be configurable by gump by instance region.
  • Optional lockout timers on dungeon failure - when a player dies they are kicked and locked out. This should be configurable by gump by instance region.
  • Regions should conservatively use map instances by using a pool of map instances that can be shared among instance regions that do not overlap.
  • Stretch Goal: Add gumps informing the player they are entering an instanced region
  • Stretch Goal: Add support for player-groups to enter the same instance
  • Stretch Goal: Add some kind of raid support for multiple player-groups to enter the same instance
  • Stretch Goal: Add difficulty settings to instance regions
  • Stretch Goal: Add spawners that are configurable by difficulty setting

Pre-configured instance regions could be sold separately or added to the package at the discretion of the team doing the project. An example would be an instanced Doom Gauntlet that could be loaded from the in-game region management gump.
 
Last edited:
1. A shard configuration gump system.. *Something like what Ryan of RunUO announced he was going to do a year or more ago, and was left empty..

Can you elaborate?

Well.. It was brought up as an upcoming project from Ryan a year or more ago, he asked for input on things we would want to have within it..

It would be something like an Admin gump, that would have all sorts of shard settings. Stuff that we all go through when setting up a new shard, as well as anything that is commonly done but by manual commands or whatever.

The only problem I would see with this, is it would almost certainly need distro script mods to be done right. For instance, if we put in a function to set the amount of houses per account on the gump, BaseHouse.cs would need a tag put in for this stored number to be used, since it is currently hard coded.

Here is the RunUO forum thread that Ryan started, and a lot of good ideas for what it could contain;
http://www.runuo.com/community/threads/community-input-configuration-data-and-runuo-setup.533250/
 
This would be nice and donation worthy.

Another idea for a community built system is to add support for instancing that is configurable and user friendly . I know the instancing part has been done before, this new effort would focus on usability:
  • In-game gumps to manage the system
  • Allow instance regions to be defined in game using gumps similar to custom-region-in-a-box
  • Have variable ways to enter an instanced region - clickable items, teleporters, etc
  • Lockout timers that only allow players to enter a region on a certain time interval - such as once per hour, day, week, month. This should be configurable by gump by instance region.
  • Optional lockout timers on dungeon failure - when a player dies they are kicked and locked out. This should be configurable by gump by instance region.
  • Regions should conservatively use map instances by using a pool of map instances that can be shared among instance regions that do not overlap.
  • Stretch Goal: Add gumps informing the player they are entering an instanced region
  • Stretch Goal: Add support for player-groups to enter the same instance
  • Stretch Goal: Add some kind of raid support for multiple player-groups to enter the same instance
  • Stretch Goal: Add difficulty settings to instance regions
  • Stretch Goal: Add spawners that are configurable by difficulty setting
Pre-configured instance regions could be sold separately or added to the package at the discretion of the team doing the project. An example would be an instanced Doom Gauntlet that could be loaded from the in-game region management gump.
 
Back