Sorry your browser is not supported!

To save a lot of clutter in the various beta threads, I thought I'd start this to discuss how plug-ins could work.

I see this as vital in the area of social networking and IAP, because these change almost daily and should be utterly separate from the AppGameKit core. It doesn't seem sensible to expect TGC to keep updating to include or exclude the latest wombat social site.

For me, Delphi's component model, though not perfect, is excellent. Visual or non-visual components, free or paid for, can be added to the toolbar and used as needed. They usually come either with or without source code - source being more expensive. Without source code you will have a chunk of executable code (DCU - Delphi Compiled Unit) and a Pascal or C++ interface. At compile-time the DCU is linked into the program.

Delphi is expensive, but it comes with a big range of components, for example to do networking. We buy components to do things that Delphi does not have components for - advanced word-processing, network speech and so on. There are thousands.

The point I'd like to make is there is a clear separation between the language (Object Pascal or C++) and just about everything else. The language knows nothing about files, graphics, sine and cosine, audio, video. These are in distinct units and are included by choice. Delphi XE7 includes units with a full interface to all current social networks, OpenGL etc. They are not part of Pascal or C++ - they are things which may be added, like salt or pepper to food.

This seems to me to be the way AppGameKit should go. It's unlikely that plug-ins can actually be written using AppGameKit Basic. So for T1 it would need a "Gateway" that would allow extensions to the interpreter, and those bits of object code to be linked.

Over to you!

I think the reason the DBPro plugin system hasn't been ported over to AppGameKit was to keep control of the integrity of AppGameKit apps. That is, ensuring plugins couldn't be used to circumnavigate security etc.

I don't know if that thought process is still valid as AppGameKit has evolved. We can, for example, venture outside of the app folder in Windows now.

I mentioned this in the AppGameKit V2 Alpha 7.1 thread, but I'll put it here too.

Most of AGK's competition has support for plugins such as Unity, Game Maker, and Monkey X, Construct 2, etc. If a plugin system was introduced to AppGameKit, I would certainly develop some plugins for it.



I would say it's more likely because DBPro is not interpreted, whereas AppGameKit is. So a plugin system for AppGameKit would have to work quite differently "under the hood" than DBPro's.



I agree.

Sean

Would the following be possible:

Paul provides us one command 'CallExternalFunction()', this command is a callback to an empty function in the interpreter/core.

We could then do what we want in that function. That's Pauls part done, if that's possible?

Then, we all get together and develop a protocol for calling functions where the function ID, parameter types and values are all encoded into a memblock.

So the plugin developer would provide an agc file which looks something like this:




In the callback the plugin developer will map all the actual plugin functions to the ID, bit of an overhead here, could think of optimisations later perhaps.


I'm not sure if this would be possible, or whether it is too long winded or not efficient enough.

The advantage is that all the work is with the plugin developer, not with Paul or the user

let me know if you think this is possible, or if you can improve on this idea?

The issue with that is it would be difficult for people to use more than one plugin at a time. Also, it would not give plugin developers access to parts of AppGameKit that are "locked away" such as OpenGL.


Sean

That's a very messy way of doing it. It needs an 'external' keyword:

function EatMyPants(param$,paramI,paramF,etc) external 'Wombat.dll' cdecl

The last bit could be omitted by insisting that all DLLs are cdecl

The plugin must have an interface file with these declarations, otherwise the compiler will throw an error.

For purely AppGameKit plugins it's easier just to provide the source files.

It's all fairly easy on Windows' rather "open" architecture, but becomes a nightmare on Android and torture in the prison of iOS.

Apart from the PC, where the excellent DLL system makes modularity simple, the issues are very complex for TGC.

To be brutally honest - if you want a flexible system that's quick to extend you need to move to T2 or Object Pascal.

It is messy and a bit of a hack but I wonder if it could provide an 'unofficial' way for the community add extra functionality.



I don't think this would be too much of an issue, we could develop a plugin handler which takes care of everything for the user. Each plugin would have it's own unique identifier or whatever.



I think what BatVink was saying applies here. I think TGC will hand over more and more access as we go forward, since they developed AppGameKit so they will want to take full advantage of developing official upgrades etc.

They could easily give us access to this stuff via tier 2 but as far as I know they have not. So I think this issue is a separate issue, we may get official plugin support one day but still not have access to certain modules.

The basic idea of Plugins is great, well applied in other TGC or non-TGC development tools and will save a lot of work for TGC in the long term because more and more functionality will be added by the community.

While there are some good ideas here I think you have to step away from either DLLs or external source code files. DLL files are not cross-platform compatible (Windows only) and delivering plugins via source code modules is not an option for commercial (closed source) plugin development.

I think we should be able to call functions of external compiled AppGameKit byte code files (.byc). These will be faster (already compiled), cross platform (interpreted at launch-time by the AppGameKit player just like any other app) and secure (non-readable byte-code). Also I can't image it to be very problematic to implement because the byte-code interpreter is already there, it just has to be able to load in multiple files.

Byte code plugins are only any use for plugins that use what is already available in the compiler. To do anything else requires another compiler and some object code, an interface, and a linking mechanism.

DLLs on Windows is not an issue, because each platform will have a different code-base to call anyway. On Android, for example, it could be Java.

The most elegant solution, as I've said many times, is for AppGameKit to include Lua. The power of Lua in all areas except rendering is massively superior to AppGameKit Basic - and there are libraries to do networking and other stuff needed for social sites. And it's possible to get Lua to create callbacks to an AppGameKit function.

This is only an issue for Tier 1, because in C#, C++ and Object Pascal almost anything can be done. The OGL surface is easily exposed, and very fast object code can be produced.

So I think plugins divide into two types for T1:

* Cute stuff with AppGameKit itself
* Stuff that would be impossible or extremely difficult in AGK

In the first case, having the compiler produce a byte code file is fine.

In the second case, Lua provides a powerful sub-system with double-precision maths. It's used in many AAA games. It's free, and could be compiled into the AppGameKit core with few problems.

So - Lua is not Basic, but advanced plugins will usually be written by advanced programmers, not newbies. If you want advanced AI, or Fourier Transforms, for example, you are not going to get these in AppGameKit Basic because it doesn't have complex numbers or high-precision floating point numbers.

What a compiler can't do can be done by more powerful imports.