[BotSDK] PacketDispatcher for easier Bot-Development

EuadeLuxe · 2015-02-19 16:41:42

Introduction

Hello to all of you out here,

after quite some time I went back to creating bots for EE and soon got into it again. Actually though, I have been disgusted of writing the "message" handlers (as PlayerIO calls them) all by branching for different types of messages and always having to know the order of the messages internally in order to get at the information I want. Therefore I sat down and wrote a small system which might be useful to some of you. Please excuse me, if something similiar already exists, but as I said I just returned to creating bots so i'm not up-to-date when it comes to that.

Below you will find a quick overview of the system and a link to the GitHub-Repository.

----------------------------------------------------------------------------------------------------------------

The Basic Concepts

The basic concept of "MessageLib" (that's what it's called like) is that all messages sent to EE or received from EE are wrapped into classes. Each class may then either be an inbound packet (i.e. a packet which you receive) or an outbound packet (which you may send). Using the Connection object which probably all of you know you are given an extension method called Send(...) which will effectively do all the serialization into the actual Message object for you, i.e. there's no difference in whether or decide to use messages directly or use MessageLib. For inbound packets things even get a bit nicer as MessageLib provides you with something I call a "Dispatcher". Whenever you acquire a new connection object you may hand it over to the dispatcher which will from now on respond to all received messages and dispatch them around all your listeners. I hear you saying: "But what da heck are listeners?" Well, arguably it'd be best, if I'd just show you a little example:

using MessageLib;

namespace MyHyperCoolBot
{
    public class MainClass
    {
        public static void Main()
        {
            // We assume that these instances we're already initialized:
            PlayerIOClient.Connection connection;

            // Here we may now create our dispatcher:
            PacketDispatcher dispatcher = new PacketDispatcher();
            dispatcher.AddConnection( connection );
            dispatcher.RegisterListener( new MyPacketListener() );
        }
    }


    public class MyPacketListener : IPacketListener
    {
        [PacketHandler]
        public void onInit ( Packets.In.PacketInit init )
        {
            // Do something awesome with our packet:
            string worldKey = init.Derot;
        }
    }
}

In this example the onInit(...) method of our listener will be invoked whenever an "init" message is received. Why is that? Because the packet dispatcher does all the work of deserializing the messages appropriately for you and then invokes any methods of listeners registered to it which fulfill the following conditions:

The method possesses an PacketHandler attribute
The method takes exactly one parameter which is an instantiatable type implementing the IInboundPacket interface

This effectively means that you may treat whatever EE sends to you as some kind of event which may be handled by any object you like. Another example for getting notified whenever a user takes the crown:

[PacketHandler]
public void onPlayerCrown( Packets.In.PacketPlayerCrown crown )
{
    // We might do all kinds of things here. crown.UserID is the ID of the user who has taken the crown.
}

For sending a packet back to EE we would do something like this:

connection.Send( new Packets.Out.PacketPlayerTrophy() );

which would give our bot the silver crown. The library comes with a whole bunch of predefined packet classes. If you find them to be wrong or not working please let me now, or even fix them yourself. If you are missing In- / Outbound packets you may tell me as well or you may even write them yourself. Just have a look at how it's done in the library itself, it's really not that hard. Just don't forget to make your packet known to the PacketDispatcher by doing:

dispatcher.RegisterPacket( typeof( MyVeryAwesomePacket() ) );

----------------------------------------------------------------------------------------------------------------

Conclusion

To me this system has proven its value as it allowed me to decentralize my work a lot more than registering message handlers all the time. Also it allows for much cleaner code in my opinion - that must not be true in yours as well (!).

Finally, here's the link to the project's GitHub-Repository, enjoy: https://github.com/EuadeLuxe/MessageLib

Best regards,
EuadeLuxe.

Zumza · 2015-02-19 17:40:12

Why not use CupCake?

Tomahawk · 2015-02-19 20:07:22

Zumza wrote:

Why not use CupCake?

Why not leave cupcake on its shelf and consider fresh software?

~ Though in my opinion this code looks a little lengthier than hardcoding all the handling.

Hexagon · 2015-02-19 20:12:52

I'm interested in this library (PacketDispatcher); have you done any benchmarks? I'd like to see how it compares to other frameworks such as CupCake and PlayerIO.

EuadeLuxe · 2015-02-19 22:18:13

It's quite hard to get any reasonable benchmarks for it as there are several points one should consider about any kind of information posted here:

The number of handlers which will be invoked once a packet is received will change dynamically. Therefore invocation times will ultimately sum up.
The more payload a packet contains the longer it will need in order to be deserialized. As the length of packets varies greatly (from the init packet to the god packet for example) there's no really "consistent" time a deserialization of the raw message data will take

But still I've benchmarked the time it takes to deserialize different messages into their respective packet wrapper classes and summed them up here:

205 x PacketPlayerCollectCoin: 00:00:00.0041107 => 0.02005ms per Packet
200 x PacketPlayerBrickPlace: 00:00:00.0056117 => 0.02848ms per Packet
36 x PacketPlayerChat (each one contained exactly four characters): 00:00:00.0009833 => 0.02731ms per Packet

Still, these numbers will barely be of any use to you as you should do not have to worry about them in any existing system.

I do not now how the dispatcher compares against CupCake or similiar as I did not try them out yet (as I mentioned in the introduction, I just recently began to develop bots again). In fact a comparison against PlayerIO would be useless as the packet dispatcher still uses the PlayerIO.Message object internally. The only place where the packet dispatcher might be faster then using PlayerIO message handlers directly is, when it comes to the point that multiple handlers deserialize the very same message multiple times. Still, these are very vague predictions.

lrussell · 2015-02-19 22:56:29

Processor has been working on CupCake 2, which will use his new BotBits platform (https://github.com/Yonom/BotBits).
Either way, the more the merrier!

Processor · 2015-02-19 23:19:30

BotBits is basically this without the bloat that CupCake offers, but yeah, nothing wrong with yet another bot framework. Welcome back to EE!

EDIT: I just gave you permission to post links. (Usually you have to make your first 10 posts before you are allowed to use links, because of all the spam bots out there)

Hexagon · 2015-02-19 23:23:04

EuadeLuxe wrote:

It's quite hard to get any reasonable benchmarks for it as there are several points one should consider about any kind of information posted here:
The number of handlers which will be invoked once a packet is received will change dynamically. Therefore invocation times will ultimately sum up.
The more payload a packet contains the longer it will need in order to be deserialized. As the length of packets varies greatly (from the init packet to the god packet for example) there's no really "consistent" time a deserialization of the raw message data will take
But still I've benchmarked the time it takes to deserialize different messages into their respective packet wrapper classes and summed them up here:
205 x PacketPlayerCollectCoin: 00:00:00.0041107 => 0.02005ms per Packet
200 x PacketPlayerBrickPlace: 00:00:00.0056117 => 0.02848ms per Packet
36 x PacketPlayerChat (each one contained exactly four characters): 00:00:00.0009833 => 0.02731ms per Packet
Still, these numbers will barely be of any use to you as you should do not have to worry about them in any existing system.
I do not now how the dispatcher compares against CupCake or similiar as I did not try them out yet (as I mentioned in the introduction, I just recently began to develop bots again). In fact a comparison against PlayerIO would be useless as the packet dispatcher still uses the PlayerIO.Message object internally. The only place where the packet dispatcher might be faster then using PlayerIO message handlers directly is, when it comes to the point that multiple handlers deserialize the very same message multiple times. Still, these are very vague predictions.

Thank you for your time to produce these benchmarks. If it does use PlayerIO messages in the background, I assume that it should be not much different than Cupcake or another alternative in terms of speed. However, because this interface exposes more lower level functions, it may be possible to be more efficient.

Processor · 2015-02-19 23:28:17

https://i.yonom.org/nn0 Pretty similar code bases!

There should be no noticeable performance difference between this and CupCake / BotBits when parsing messages. Not that it matters anyway Anything less than 10ms is good enough for EE.

EuadeLuxe · 2015-02-20 01:04:32

@Processor: Yeah, but how should something be different if it's explicitely defined by EE ? And yes, I totally agree with you, that performance shouldn't be the greatest of all concerns when it comes to writing bots for EE. Currently for getting into it I'm developing the "Game of Life" for EE just to get used to it again and in fact performance of deserialization is not really the big problem there.

Official Everybody Edits Forums

#1 2015-02-19 16:41:42, last edited by EuadeLuxe (2015-02-20 01:01:06)