1  |   Order by index

Jun 18, 2006, 12:06pm

I've been playing recently with a concept that the SDK seems to lend itself
to quite nicely, and with the current state of the SDK and the difficulties
involved in using it at the moment, I thought now might be a good time for
some healthy discussion on the subject.

Based on my previous experience of the people that used the SDK and the way
this newsgroup worked (it used to be more of a "how do I do this?" and "why
doesn't my bot do what its supposed to?" forum with code snippets flying
around and, sometimes, even active discussions on specific topics), it
struck me that we would all be better served by something based on sharable,
re-usable components.

If you look for a basic OO abstraction of the SDK, you'll probably come up
with a set of virtual methods in some form of base class to handle SDK
events, which is great for laying down a template for developing bots. This
still targets a single set of code per event, though.

I've spent the last couple of weeks going through several iterations of
prototype for a very simple framework that doesn't attempt to abstract the
SDK, but rather puts in place a foundation for "plug-ins" - reusable
components that can be connected to a base "bot" class, sharable in either
code or binary form. The framework deals with enabling plugins to subscribe
to SDK events and callbacks and their delivery to appropriate components
when they arrive. Additional base class methods open up the plugins (and the
base "bot" class in the framework) to the SDK methods whilst still
protecting the operation of the framework.

This "plug-in" framework enables all manner of components to be created
ranging from the simple (for example, a plug-in for handling the bot's
avatar in the world, logging chat messages, etc.) to the more complex
(Demeter, game controllers, property managers, etc.). Plug-ins can use their
own plug-ins within them and they can be extensible, enabling people to
build on top of existing functionality by subclassing the plug-in.

The prototype isn't ready for public consumption - I'm hoping to have plenty
of examples and documentation before I throw the code up to be shot at - and
it only exists in .NET 2.0 at the moment (the concept was inspired in the
first place by delegates, although the idea of using delegates in the
implementation was discarded after the first prototype).

Most SDK applications spend 95% of the time doing nothing and often multiple
bot instances are running simultaneously, picking up the same events and
callbacks.

The reason for the (longer than I'd planned) post, was to see if anyone
wanted to discuss ...

(a) whether this has been tried/implemented before with any success/failure
stories,
(b) the whole "plug-ins" concept and preferences on implementation,
(c) possible target platforms,
(d) whether you think anyone would use it,
(e) anything else.

This is nothing ground breaking, just a concept that seems to work quite
nicely. It may even bridge the gap to "native" SDK development for those
that haven't tried it before. There's a chronic lack of people involved in
SDK development, which is sad.

Any comments welcome, Grims.

Jun 18, 2006, 8:17pm

Considering the changes in SDK we have seen so far, it sounds like
this would be a good experiment of the individual SDK functions
outside of the quirks of coverted 3.6 code.

I would be interested to read about what you discover about the SDK,
even if I didn't use the plug-in.

And I agree about the newsgroup, issues, solutions, questions,
answers, code examples.

-cotarr

On 18 Jun 2006 10:06:07 -0400, "Grimble"
[View Quote] >I've been playing recently with a concept that the SDK seems to lend itself
>to quite nicely, and with the current state of the SDK and the difficulties
>involved in using it at the moment, I thought now might be a good time for
>some healthy discussion on the subject.
>
>Based on my previous experience of the people that used the SDK and the way
>this newsgroup worked (it used to be more of a "how do I do this?" and "why
>doesn't my bot do what its supposed to?" forum with code snippets flying
>around and, sometimes, even active discussions on specific topics), it
>struck me that we would all be better served by something based on sharable,
>re-usable components.
>
>If you look for a basic OO abstraction of the SDK, you'll probably come up
>with a set of virtual methods in some form of base class to handle SDK
>events, which is great for laying down a template for developing bots. This
>still targets a single set of code per event, though.
>
>I've spent the last couple of weeks going through several iterations of
>prototype for a very simple framework that doesn't attempt to abstract the
>SDK, but rather puts in place a foundation for "plug-ins" - reusable
>components that can be connected to a base "bot" class, sharable in either
>code or binary form. The framework deals with enabling plugins to subscribe
>to SDK events and callbacks and their delivery to appropriate components
>when they arrive. Additional base class methods open up the plugins (and the
>base "bot" class in the framework) to the SDK methods whilst still
>protecting the operation of the framework.
>
>This "plug-in" framework enables all manner of components to be created
>ranging from the simple (for example, a plug-in for handling the bot's
>avatar in the world, logging chat messages, etc.) to the more complex
>(Demeter, game controllers, property managers, etc.). Plug-ins can use their
>own plug-ins within them and they can be extensible, enabling people to
>build on top of existing functionality by subclassing the plug-in.
>
>The prototype isn't ready for public consumption - I'm hoping to have plenty
>of examples and documentation before I throw the code up to be shot at - and
>it only exists in .NET 2.0 at the moment (the concept was inspired in the
>first place by delegates, although the idea of using delegates in the
>implementation was discarded after the first prototype).
>
>Most SDK applications spend 95% of the time doing nothing and often multiple
>bot instances are running simultaneously, picking up the same events and
>callbacks.
>
>The reason for the (longer than I'd planned) post, was to see if anyone
>wanted to discuss ...
>
>(a) whether this has been tried/implemented before with any success/failure
>stories,
>(b) the whole "plug-ins" concept and preferences on implementation,
>(c) possible target platforms,
>(d) whether you think anyone would use it,
>(e) anything else.
>
>This is nothing ground breaking, just a concept that seems to work quite
>nicely. It may even bridge the gap to "native" SDK development for those
>that haven't tried it before. There's a chronic lack of people involved in
>SDK development, which is sad.
>
>Any comments welcome, Grims.
>

Jun 18, 2006, 10:03pm

Not sure if you saw the post earlier but some folks have put a bit of time
into helping out the sdk wiki. This would be a great topic for the wiki.

Wiki URL: http://awsdk.addrpg.org

Also I can host files for download if you let me know and then there will
always be a permanent place for the files to reside. Also can have copy and
paste friendly source code.

I may only be involved in a little niche of the sdk development community at
present but feel free to telegram me, I would love to help with projects
like this.

DM

[View Quote]

Jun 19, 2006, 1:31am

Sounds interesting, but you should really code it in ANSI standard C++
instead of proprietary .NET. Standard C++ will be much more useful to
many more people who are not windows/microsoft-centric.

-J

[View Quote]

Jun 19, 2006, 6:43am

Before I say this, I want to make sure that its not read as an argument for
..NET.

JerMe makes an important point here, and one that needs to be followed for
this to satisfy the initials goals of (a) bridging that gap to make the SDK
more accesible and hopefully bringing more people into SDK development, (b)
encouraging working functional component code to be shared based on a common
framework (with an obvious code conversion required to change plaform) and
(c) give us all something new to talk about.

I'm working in C# at the moment because its the best language for me to
rattle out prototype code and I can concentrate on what the framework's
doing rather than getting my head all stuffed up with another language's
syntax. With the skills avilable in this group, there shouldn't be any
reason that its not ultimately available on ANY platform. Having said that,
I don't know the bounds and capabilities of pure ANSI C++, and I've rarely
used Delphi other than out of curiosity. This is where the members of this
newsgroup come in.

I need to fully prove this to myself, knock out some meaningful examples of
plug-ins to demonstrate it, document them and the framework itself and write
up the prototyping findings (why it does what it does the way it does). This
should give the rest of the group enough ammunition to shoot the idea and/or
it implementation (not me personally please!) into little biddy pieces as
they wish, make more contributions regarding the interface and start to
shape it from ALL our experience, whilst at the same time coming up with
conversions of the code if there's a demand for a specific platform. I won't
be able to do the other platforms justice and being kicked for my efforts in
that respect would detract from building on the framework.

Yes, it needs to be ANSI C++, but it also needs to be .NET (providing the
framework for VB.NET, C# and the latest Delphi's), maybe an MFC-specific
version and perhaps others. I'm hoping this will be driven by everyone here
rather than one individual.

The important thing is that they all work the same way with the same
interface and predictable results. Plugin events need to be fired in the
same order, the same syntax (outside of language syntax) used across
platforms, nothing added to specific platforms that can't be implemented on
other platforms realistically. The only potential barrier I see to this at
the moment is different coding standards for each language, but I'm hoping
this can be wrapped up within each framework impacting the interface. We
would have to define a set of sub-standard (bad phrase I know!) for the
interface that retains reference to the SDK documentation but doesn't
necessarily comply with, for example, recognised language naming
conventions. There's also an issue where a plugin subscribes to a callback,
which may prove something of a headache when it comes to the idea of
self-contained functionality (i.e. a callback subscription in one plugin
makes calls to that respective method asynchronous in all plugins for that
instance). This may need to be addressed via development guidelines or
mandatory plug-in documentation. Who knows? This is a good example of where
everyone can contribute to try to resolve it.

Thanks for bringing this up.

[View Quote]

Jun 19, 2006, 8:17am

DM,

Thanks for the offer, I've been to the site a few times and have already
considered approaching you when the time was right. Its just an idea at the
moment, and "community" involvement will likely fade away (as ever) over
time. There has to be something a little more concrete to discuss first
(i.e. an initial spec/design as a bear minimum) so that comments and
opinions can be shared, which means me sticking my head out of the trenches.
To do that, I need to have a few things sorted in my own head so that I can
provide a basis for the discussions and be able to adequately articulate my
own position.

Btw, everyone is in a niche of the SDK development "community" right now ...
there's not enough people involved in it anymore for there to be a
"mainstream".

Keep up the good work, Grims.

[View Quote]

Jun 19, 2006, 8:23am

3.6 features are the only thing I can do on the SDK at the moment without
wasting a lot of time experimenting with features that I know absolutely
nothing about (no documentation for build 60 and the new attributes ya see).
This was the main reason for raising this now (the underlying concepts of
using the SDK haven't really changed much with 4.1), since sadly I can't do
anything with the new toys at present.

Grims.

[View Quote]

Jun 19, 2006, 4:07pm

[View Quote] From my understanding, ANSI C++ is C#, but C# isn't ANSI C++...

In other words, the C#.NET compiler should compile standard ANSI C++
just fine, but the ANSI C++ compiler will choke on C#.

I admit, I'm not a M$ kinda guy, and thus I'm not familiar with C#...
So, don't quote me on that.

I'm sure Strike will be able to correct me if I'm wrong....

-J

Jun 19, 2006, 4:13pm

[View Quote] C# is a completely new language based upon MS Java, it does not support
things like naked pointers and so forth directly, you have to have their
wrapped versions and so forth.

--
- Mark Randall
http://www.temporal-solutions.co.uk

"We're Systems and Networks..."
"It's our job to know..."

Jun 19, 2006, 7:54pm

TBH, platform isn't really my focus at the moment. I think the important
thing at this stage is identifying solution(s) for the "challenges" I've yet
to solve satisfactorily.

The main problem I have at the moment is routing callbacks to the correct
target. Events have the same problem to an extent, but callbacks are more of
a challenge. It all revolves around different plugins doing the same sort of
thing at the same time - who gets what events and what callbacks without
screwing up the other one. I'm working through this to a degree, but I
assume there must be dependencies within the SDK for ordering of callbacks.

By way of example, in a test application I issued 10 async aw_cell_next()
calls without checking in with the server between them (they all used the
same AW_CELL_ITERATOR value with AW_CELL_COMBINE set to true). These seemed
to come back in order (CELL_BEGIN, n x CELL_OBJECT, CELL_END events followed
by a CELL_RESULT callback - each block intact and sequential with the exact
same results). I know aw_query and aw_query_5x5 prevent more than one query
at a time on a single instance, but does anyone know the rules within the
SDK for methods that don't hold that restriction? Are there any rules? A new
attribute would be useful, which we can set before an async call and it
comes back in the callback (and the events it causes), but we've not got it.
The whole handling of the query events and callbacks is an issue at the
moment.

Any ideas welcome!

[View Quote]

Jun 19, 2006, 7:57pm

You're probably thinking about managed C++ code in .NET 2.0 (i.e effectively
C++.NET), for which I would expect your comments to hold true.

Grims.

[View Quote]

Jun 19, 2006, 10:42pm

BTW .NET as a whole is not proprietary. Both the underlying CLI and C# of .NET are ISO standards.
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36769&ICS1=35&ICS2=60&ICS3= - CLI standard.
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36768 - C# standard.

Already efforts have gone into utilizing the CLI with over 40 languages that compile down into CIL (Common Intermediate Language) and projects designed to support programs compilerd into CIL without the use of the .NET Framework or VM. The most notable
being Mono, an open source project to bring the CLI into cross-platform world. As seen here: http://www.mono-project.com/Main_Page

Just figured I'd let people in on the fact that with the ISO standardization of both CLI and C#, they're not much Microsoft anymore. Yes Microsoft, HP, and Intel own patents... but those patents are provided royalty-free to anyone who wishes to implement
C# or CLI.

-Byte

[View Quote]

1  |   Order by index