Dummy system / client

Ernam

I've already begun building the backbone of this, but I'd much rather take this public, leave it open-sourced, free, and get some other people to help me build and manage it.

I'm building a dummy system that allows you to "simulate" your offense against it.

The concept(s) are:

Three Modes:

• Normal: The system reacts as the game itself would, in real-time.
  
• Fast: the game steps through combat 10ms at a time at CPU speed (allowing you to run like 10 simulations of a pre-set or automated offense against the sim).
• Slow:  Practice like you're in a debugger.  The game freezes on every balance (or optionally, just have everything occur 2-5 times slower than normal, allowing you to practice more intelligently and slowly increase the speed up to normal once you're more comfortable and experienced.

Cures exactly like Ahaea cures, including active cure scenarios, class abilities, passives.  The system knows which affliction it cured, but you do not.  This results in every "run" being different even with the same curing and offense scripting.  Ideally it would also include diagnoses, tricks, and possibly even simulated illusions (down the road).

Three choices I'm considering for output:

• Output in Mudlet window
• Outputs an XML/HTML file of a simulated fight (would now support realtime control)
• A telnet client hosted on a server that people can actually log into and use.

I'm not necessarily going to be "in charge" but I'll probably be doing a bunch of coding.  So far I'm doing everything in collabedit, all in LUA.

Please shoot me a PM or message in game if you'd like some more details or would like to get involved in the coding.

Ernam

I'm looking at you, @Seragorn, @Austere, @Vadimuses, @Klendathu, @Isaiah, and everyone else big into coding (sorry if I left you out).  @Makarios and @Tecton it would actually be nice to know your feelings on something like this, and maybe even have it hosted on Achaea's server (it'd be super low traffic, but would negate the need for us to figure out server options).

Yes, I'm bumping this thread and name-bombing at the same time.  

Austere

Ernam said:

I'm looking at you, Seragorn,  Austere, Vadimuses, Klendathu, Isaiah, and everyone else big into coding (sorry if I left you out).  Makarios and Tecton it would actually be nice to know your feelings on something like this, and maybe even have it hosted on Achaea's server (it'd be super low traffic, but would negate the need for us to figure out server options).

Yes, I'm bumping this thread and name-bombing at the same time.  

I appreciate the offer, but let's be honest.  My coding ability doesn't come close to touching anyone on that list, including yourself.  You guys would probably just filter out all the stuff I wrote, and while I take no offense to that, just seems like a monumental waste of time.  If no one else steps up, I wouldn't mind helping, but I am not going to pit my ability to code against professionals.  Also, you forgot @Jhui

Ernam

I actually didn't know @Jhui did coding at all, hrm.  Everyone's welcome to be a part of it.  Since I'll be keeping the code in collabedit, you don't even have to do anything if you don't feel like it.  It's public and has a chat box & lua highlighting etc.  Not going to post the link here for obvious reasons.

Austere

Ernam said:

I actually didn't know @Jhui did coding at all, hrm.  Everyone's welcome to be a part of it.  Since I'll be keeping the code in collabedit, you don't even have to do anything if you don't feel like it.  It's public and has a chat box & lua highlighting etc.  Not going to post the link here for obvious reasons.

You can feel free to pm me link and I can look at it in my spare time.  I might even learn something or be able to offer ideas. 

Nim

I'm a programmer too. T_T a busy one who doesn't use mudlet, but I do know lua, and depending how it's done, if it is going to be a client thing, writing a tintin++ wrapper can't be too hard if I get into it.

Tecton

Not something we'd host, sorry! Purely from a security standpoint, the risk of running unaudited third-party software is just too great.

Austere

Tecton said:

Not something we'd host, sorry! Purely from a security standpoint, the risk of running unaudited third-party software is just too great.

What about the possibility of updating testing dummies to use serverside curing?  Not sure how hard it would be, you could just give each of the an unlimited supply of cures and do a special message when it would have died.  Could make the whole unkillable thing a toggle with a way to set max health and mana. 

Edit: @Tecton

Ernam

Austere said:

Tecton said:

Not something we'd host, sorry! Purely from a security standpoint, the risk of running unaudited third-party software is just too great.

What about the possibility of updating testing dummies to use serverside curing?  Not sure how hard it would be, you could just give each of the an unlimited supply of cures and do a special message when it would have died.  Could make the whole unkillable thing a toggle with a way to set max health and mana. 

Edit: @Tecton

His name is @Deladan... although @Amranu makes a fine punching bag too.  I probably broke Deladan's right arm 500 times last week.  I also sat there venomlocking (or failing to venomlock) @Savira for like... hours.

Thanks fellas!

Tecton

Austere said:

Tecton said:

Not something we'd host, sorry! Purely from a security standpoint, the risk of running unaudited third-party software is just too great.

What about the possibility of updating testing dummies to use serverside curing?  Not sure how hard it would be, you could just give each of the an unlimited supply of cures and do a special message when it would have died.  Could make the whole unkillable thing a toggle with a way to set max health and mana. 

Edit: @Tecton

It'd be cool, but would require reworking just about every single ability in the game to work on denizens/objects, so probably not.

Nim

No way to make an AI-controlled player? Shame, that might be cool for boss tier enemies too...

Ernam

Nim said:

No way to make an AI-controlled player? Shame, that might be cool for boss tier enemies too...

I mean, that's exactly what we're going to do.  I suspect that it will be more complex than any system ever made, if it reaches its design goals, but I also expect that if that happens, it would revolutionize the game as much as its ancestors (ACP, Acropolis, Mudlet, SVO, (I'll be modest) did during their times, or continue doing.

I mean, do you think Server Curing would exist right now of Vadi hadn't sat down one day and started writing code that would take months of work to build, and years to perfect?

You want a combat dummy?  Well... Then let's make one.  We certainly have more than enough talent, and I don't think anyone reading these forums can really say they don't have the time.

Only this time, would be kinda cool if we could run it together instead of collectively paying for another line coder's mortgage.


Edit...

...and if trends hold true, IRE will decide to implement this right after we spend a few years doing it ourselves  

Vadimuses

Got a life these days, sorry! Too busy working on Svo & Mudlet for ya'll

Keneanung

@Ernam I have a few suggestions:
1) share a link publicly and let people have a look without making them volunteer blindly

2) while an online collab tool might be useful, something like Github/Bitbucket/etc might have some more pros: You have versioning, people can use the tools they like (offline or online), automatic builing/deploying (via 3rd party services), bugtracker, wikis for documentation and some more things I probably forgot. You can even have a developer chat with github and gitter.

3) specify the architecture a little more. You say it's lua but will you have it embedded in some C/C++ as server or pure lua sockets or plugged into mudlet? There are other architectural questions that depend on the answer to the former question, so I won't list them here.

Ernam

Keneanung said:

@Ernam I have a few suggestions:
1) share a link publicly and let people have a look without making them volunteer blindly

I totally agree, but not going to do that until we get it into github, because right now there is nothing stopping the trolls from replacing the code with ASCII cock-and-balls.

2) while an online collab tool might be useful, something like Github/Bitbucket/etc might have some more pros: You have versioning, people can use the tools they like (offline or online), automatic builing/deploying (via 3rd party services), bugtracker, wikis for documentation and some more things I probably forgot. You can even have a developer chat with github and gitter.

Yup, planned on moving this from collabedit to github if people show interest.  So far it seems it like people are up for it (got a few PMs as well), so I'll probably set up something this week.

3) specify the architecture a little more. You say it's lua but will you have it embedded in some C/C++ as server or pure lua sockets or plugged into mudlet? There are other architectural questions that depend on the answer to the former question, so I won't list them here.

The draw of using only LUA is that it's something I know (or assume) that everyone in the Achaea coding community is familiar, if not proficient with.  I'm sure we all have our own other languages we like, but if we start mixing languages it's going to drastically reduce the number of people willing or capable of helping out with it.  To answer your last question, it doesn't matter where you run the LUA.  I think it best if we stick to something that can be run in Mudlet, for the time being (for ease of access), but we don't necessarily have to keep it that way once it evolves into something more practically useful down the road.

For right now, I am still drawing up basic requirements of the system, and it is my intention to get a working pure LUA system that simply receives attack information and other events, and is capable of reasonably accurately keeping track of what's going on.  I see "phase 2" being entirely focused on embellishing the curing priority system (it's basically going to contain our best interpretation of server curing), at which point the output will become meaningful.

Once we have input/output of the system itself working, it will be a completely separate and probably quite simple task to call the system from virtually any 3rd party interface or programming language (including a web browser, telnet, mudlet, lua compiler, compiled .exe, java project, etc).


Now, it's always best to keep the end goal in sight at every step of a coding project, but in this case, I think it's safe and most efficient if we simply focus on getting the basic logic and functionality of the system in, because that'll probably entail a few months of work at the least, before we start trying to find out how to add bells and whistles (like hosting a telnet server, or "pretty" output methods like HTML documents or mimicking Achaea's syntax system and output messages.)

Right now, I'm setting up the basic structure to hold all the variables necessary (number values like health, affliction table, balance flags & timers, and the basic functions required to set and access them (including checking for conflicts and error-checking, etc).

Once there's a skeleton for the system, I'll get it on github and distribute the access information.  At this point I'd imagine we'll need to elaborate on the core system (and quite probably rework some of it) in order to satisfy more complex, but necessary, concepts, like actually keeping track of herb inventory, use of OUTR to get them, concepts like dodging, character stats, damage equations, "known affliction list", and other concepts like simulated player error, latency, dynamic curing, and curing strategy choices.  It's going to be a very, very long process of tackling one challenge at a time, until at some point it becomes close enough to become practically useful.

Once it's at the "useful" stage, we can begin looking at alternative input/output options, like being able to pass the system actual commands like "dsl amranu right leg curare kalmia" instead of calling edummy.attack("dsl",750,{"right leg",500},{"paralysis","asthma"}, {})   (attack name, damage, {limb, limb damage}, {afflictions}, {status effects})

For now, I recommend that the immediate focus (once the skeleton is in place) be to focus on a rudimentary (but expandable) curing system that is able to choose what to cure given a simple list of afflictions.  That'll be the first step in our 1,000 mile journey.

Ernam

One thing I'm not 100% sure of, perhaps @Vadimuses, you may have tested this, but I'm questioning if it's best to contain everything in a single table, like SVO and Godzilla for example (svo.<everything>).  I'm wonder if it'd be better to use global variables for high-use variables and functions.

While it's certainly the best way to organize things, I'm not convinced that it's necessarily the most efficient (although it might not effect anything), and this should be addressed from the ground up, since it's going to affect how nearly every line of code in the system is written.

I might put together a test program to run some comparisons, but honestly I'm not sure what the best way to do this would be (run data storage/retrieval and function calls with both methods 10,000-100,000 times and measure how long it takes, maybe?).


Also,@Keneanung, as a followup to your question, I had another idea that I think might be "best".

What I'd like to do is keep the code up bithub, but have a daily (perhaps more frequently, if automated) update to a public dropbox containing a mudlet profile that can be loaded.

The mudlet profile would simply be nothing but the system itself with some aliases for testing/developing purposes.  Far down the road (when the system becomes practically useful), this will likely change into being a package that can be installed into actual character profiles in Mudlet, so it can be used with whatever "attack" aliases, functions, systems etc, that you would like to use "against" the simulation.

The goal should be a realistic "simulation" of combat, which is probably the most prominent and obvious use for the system.  As much as possible, I'd like for a total newbie to be able to install it, turn it "on", and "fight" against the system without having to even open the scripting editor.  This is going to create a whole new list of challenges, but the system should be designed from the ground up with this end goal in mind.

Keneanung

On the efficency bit: since globals are in the tabke _G, all globals are in a table as well. Most efficient is to organize everything in tables and the include what you need via local. For example if you often use echo, put

local echo = echo

at the beginning of your function or chunk where you need it. ETA: http://lua-users.org/wiki/OptimisationTips

The public dropbox thing is autodeploying which can be easily automated with Travis (a CI service) on each checkin. I'm doing something like that to create pre-releases of my Bashing script.

Ernam

Look at all this knowledge coming out of the woodwork.  This is why I wanted to do this as a community... I had no idea about any of the things you just suggested, and they're all clearly things that we should be using, or at least, considering.

Since one of the secondary goals of the project is that literally everyone involved will be learning a lot, while also contributing some of their own knowledge and time.

As I mentioned before, there's going to be a lonnnnnng list of concepts that basically need added one at a time.  Since so many aspects of it are compartmentalized, I have a lot of hope for being able to break up tasks without stepping on each others' toes, and so on.  Gotta get to a point where that can be broken up well first, though.

Keneanung

It might be worth considering to set up a repository even without a single piece of code. That way discussion about architectural stuff has a home and Github is a great place to do discussions, mainly in issues and pull requests, but also in Gitter.

Starting early with a repo also means you'd have more time to work out a workflow and other organisational crud.

If you don't think discussion should wait till you created the skeleton, ignore my ramblings

Ernam

Sounds good, I agree - and I'll get it up ( ) as soon as I have the base system laid out, and and as soon as I have a good chunk of time available to actually get it all set up.  I still have a few hours of coding to get it to where I want it, so I'd estimate that it'll be up on github later this week.

On a more personal note, right now the code is about half-way thrown together, and I certainly don't want to invite people in to see my dirty laundry, so to speak.  I also want to ensure that the "base structure" of the system is as efficient and well-organized as possible since all future changes will be based it.  Once I get it up, I'll essentially abandon all sense of "ownership" of it.  I'll also probably send you (@Keneanung), and a few others, a link to the collabedit code to look over it for some peer review before it goes public.

Vadimuses

Follow Lua best practices and use one namespace for your thing

Shibumi

@Ernam You are very cool.

Amranu

I could try to help, I'm more of a Perl guy but obviously know some lua for use with mudlet

Ernam

You know would would be so much better?  Just having access to a test server more often.  Perhaps on the low-volume days/times, IRE could leave testserv up for public use.

Since there is no multiplaying rule on testserv, you can just use two tabs, set up your curing system however you want on Character B, then switch over to Character A's tab and test whatever you want to test.  It's better than any "dummy" or simulator.  It's literally the real thing, which you can fully configure and control.

You can sit for hours practicing your offense, developing triggers/aliases/scripts, fine-tuning your reflexes and muscle-memory, etc, without having to ask people to sit there AFK for you (destroying immersion) while you test triggers or gather data for limb damage equations, etc.

It doesn't even have to be the "full game".  Just make the test-server Delos/Thera only, and add a few useful utilities like 100% tradein value and free/instant class swaps, for testing purposes.

It'd also require virtually no work, no upkeep, and could literally be put up literally tomorrow.

Just saying.  It's an option.  That could easily be done.  Nudge.

Aelios

Holy shit I'd love this @Tecton
A mini Anarchaea... god, yes.