I am looking at the revision history of the engien on github, and I've noticed a trickle of extra API additions that are related to various debugging and visual aspects. E.g. Team colour as the last I noticed.
While I agree debugging information is very important, we have a lua codebase with widgets and such, and a means of communicating with lua land, why are we introducing spaghetti soup by adding nonAI functionality to the AI interface when we can use the existing code?
I suggest that in future we refrain from some of the more visual oriented aspects, and instead go down the route of a lua gadget in the base archives of spring that AIs can communicate with, that can also load in AI lua widgets into the same environment as classic lua UI widgets you can grab from Spring Downloader.
Presentation logic should not be in the AI if possible, and we need to be careful with the decisions we make about the structure and composition of the AI interfaces.
Presentation Logic & The AI interface
Moderators: hoijui, Moderators
Re: Presentation Logic & The AI interface
i totally agree there. Kloot and slogic most likely disagree.
Re: Presentation Logic & The AI interface
Given a viable alternative with a nice API I am sure that they would come around, after all they already have a code base utilising these API additions and driving further additions, it would be unfair to pull the rug from under them without providing a superior alternative.
Re: Presentation Logic & The AI interface
Not sure if this is really a black-and-white issue. When an AI coder first encounters the engine they probably wont have the luxury of having implemented a GUI or text interface in their code. In that event it doesn't really hurt to have a way to let the engine pretty-print your debug output directly and create simple buttons and console communication with the option to migrate to a custom implementation later. It shouldn't be necessary to implement any display code to write a basic AI.
Re: Presentation Logic & The AI interface
That is true Spliff, and i guess we all agree with that (except maybe mod devs, in the case this would lead to AIs using GUI stuff they can not customize).
These functions are not for GUI stuff like that (buttons, windows, ...), but for showing off AI internal logic, with eg lines, circles, areas, though the same principles apply to that and GUI (buttons, ...) stuff.
in both scenarios (integrated into AI interface/engine supplied Lua Gadget), the AI would not have to write the draw code. The Lua way has pros, like the AI and the mod being able to extend and customize it easily.
I guess AF is right.. we would need better AI<->Lua interaction possibilities (eg, also to widgets directly, not just gadgets), and a few nice example widgets.
These functions are not for GUI stuff like that (buttons, windows, ...), but for showing off AI internal logic, with eg lines, circles, areas, though the same principles apply to that and GUI (buttons, ...) stuff.
in both scenarios (integrated into AI interface/engine supplied Lua Gadget), the AI would not have to write the draw code. The Lua way has pros, like the AI and the mod being able to extend and customize it easily.
I guess AF is right.. we would need better AI<->Lua interaction possibilities (eg, also to widgets directly, not just gadgets), and a few nice example widgets.
Re: Presentation Logic & The AI interface
I like Italian.why are we introducing spaghetti soup
What I do not like is having to break open a mod and then defining some weird byte-string protocol for an AI debug-data router gadget (that I must write first) or sending over ugly embedded Lua code snippets to get my output on screen in the format that I want, which would still be necessary (and in addition require me to already know Lua, OpenGL, etc) even if there was a template gadget to do the forwarding or a direct AI-widget commlink.
All in all, I'd rather make the handful of calls needed to generate this (that together hardly even qualify as presentation logic) to the debug API in my AI than go down the Lua road to achieve the same or greater flexibility but being served more spaghetti than I could ever eat along the way.
Re: Presentation Logic & The AI interface
- You would not have to meddle with a mutator and a custom gadget because I already proposed an alternative above that sidestepped that, lua widgets that are bundled with AIs and loaded and inserted via the AI comms gadget in the base archive, allowing arbitrary widgets that follow the same development model we already have.
- There is nothing stopping us from making superior graphs and informatics with a C++ API wrapper that is easier to use
- Your personal preference for spaghetti soup is not a valid excuse for irresponsible development of an API that people other than yourself use. This is an API for us, not an API specifically for you, and we all have to work together.
- Opposition was to the addition of further API calls. We are reinventing the wheel here and it is both time consuming, and a waste of our effort to start writing presentation logic for graphs, and then spend hours justifying why presentation logic doesn't count as presentation logic because of a technicality or insignificance in comparison to the likes of webkit or Directx11 Hull shaders
Last edited by AF on 14 Jun 2010, 23:11, edited 1 time in total.
Re: Presentation Logic & The AI interface
please stop it.
AF, we will have a better Lua <=> AI communication system one day, and then you can do it as you describe, and if you and me are not wrong, it will prove as superior, and will be used more/exclusively.
I guess it is obvious that you can not prevent anyone from adding other stuff, and it should be obvious by now, that you will not convince Kloot.
I know what your argument is.. fif we add stuff like this, it will be used, and be hard to get rid off, even if there will be better stuff later...
that is a valid argument, but it will not change anything, talking about it again and again. Kloot will not make the Lua AI comm thing.
AF, we will have a better Lua <=> AI communication system one day, and then you can do it as you describe, and if you and me are not wrong, it will prove as superior, and will be used more/exclusively.
I guess it is obvious that you can not prevent anyone from adding other stuff, and it should be obvious by now, that you will not convince Kloot.
I know what your argument is.. fif we add stuff like this, it will be used, and be hard to get rid off, even if there will be better stuff later...
that is a valid argument, but it will not change anything, talking about it again and again. Kloot will not make the Lua AI comm thing.
Re: Presentation Logic & The AI interface
I never expected him to, but I take objection to the reasoning and logic expressed on such grounds as specified, primarily because of the ignorance they showed of the actual content of prior posts.
I would also submit that the lack of a better system for lua communication is merely a problem of convenience, for which most solutions are already doable, and present via the means of wrappers. Any solution other than this would likely be exactly the same kind of solution but expressed in the engine or interface.
I would also submit that the lack of a better system for lua communication is merely a problem of convenience, for which most solutions are already doable, and present via the means of wrappers. Any solution other than this would likely be exactly the same kind of solution but expressed in the engine or interface.
Re: Presentation Logic & The AI interface
And you assume in your arrogance 1) that I added the extra debug callbacks for myself when they were in fact requested by at least two AI devs and 2) that I did not consider the obvious design pros/cons before going ahead with it, plus you insult me in your very first post by deigning them spaghetti contributions when they are no more complex than any other callback function in the API and certainly not out of place (cf LineDrawer*). Also, irresponsible development? Just who are you to judge my decisions as though there are lives at stake here?Your personal preference for spaghetti soup is not a valid excuse for irresponsible development of an API that people other than yourself use. This is an API for us, not an API specifically for you, and we all have to work together.
But it doesn't exist yet, does it? Unlike the ever-common need to visualize debug data.There is nothing stopping us from making superior graphs and informatics with a C++ API wrapper that is easier to use
Doubtful IMO, eg. group AI's were removed quickly enough when they became obsolete. And I don't mind porting the current code along with the older line-/point-drawing routines to an example widget (stripping it out of the engine is easy enough) if and when the time comes, but until then something >>> nothing. Rest assured there won't be any further "presentation layer" additions from me.hoijui wrote: I know what your argument is.. fif we add stuff like this, it will be used, and be hard to get rid off, even if there will be better stuff later...
Re: Presentation Logic & The AI interface
I was not the first to coin the phrase spaghetti soup in reference to the AI interface. It is a term I, you and most of the AI devs have used in reference to the previous interface prior to Hoijuis work.
I used this phrase with reference to what it would become if we continued a path of adding everything here there and everywhere as and when it was needed with no thought to the APIs design. Not as an insult. There was a genuine need and desire for the additions you requested, which cannot be denied.
I instead raised the point that we need to think carefully about how we approach the problem, and that we need to devise a solution now rather than later, and refrain from adding functions on a purely needs basis, rather than taking the time to evaluate the APIs structure and composition, for fear of it becoming a Mudball architecture in 5 years time.
While you have taken a decidedly defensive tone that does not reflect the actual content of my post and infers a quantity of emotional charge, you must see that your words are judged regardless, by me, by other developers, potential developers, and that I am indeed correct merely by common sense. Development of an API purely for oneself is irresponsible when it is not of your creation, ownership or maintenance, and you are not the sole user of the API.
I as an AI developer use this interface and saw a potential problem that would arise in the future if not acted upon now. We are all in such a position as users of this API, and in response you attempted to justify what I opposed. I am entitled to my opinion on the matter, and I attempted to propose a solution, and articulated that it would not be a simple matter of making you and the other developers use this by force or persuasion, rather that you would use it if it provided a superior API to the additions that are being made.
Since the discussion with kloot is providing nothing of benefit at the moment, I shall outline my own plans.
Starting with Shard I will start a project involving a gadget to attempt to build what I proposed. I will likely use EvolutionRTS as the basis since Forboding is likely to cooperate with anything that might improve AI games. I'll build a small basic API to demonstrate transferring data over to lua gadgets and widgets.
My first demonstration shall be influence maps overlaid on the battlefield. I've seen the widget code to do this demonstrated already by zwzsg.
So what form should the data callbacks take?
I used this phrase with reference to what it would become if we continued a path of adding everything here there and everywhere as and when it was needed with no thought to the APIs design. Not as an insult. There was a genuine need and desire for the additions you requested, which cannot be denied.
I instead raised the point that we need to think carefully about how we approach the problem, and that we need to devise a solution now rather than later, and refrain from adding functions on a purely needs basis, rather than taking the time to evaluate the APIs structure and composition, for fear of it becoming a Mudball architecture in 5 years time.
While you have taken a decidedly defensive tone that does not reflect the actual content of my post and infers a quantity of emotional charge, you must see that your words are judged regardless, by me, by other developers, potential developers, and that I am indeed correct merely by common sense. Development of an API purely for oneself is irresponsible when it is not of your creation, ownership or maintenance, and you are not the sole user of the API.
I as an AI developer use this interface and saw a potential problem that would arise in the future if not acted upon now. We are all in such a position as users of this API, and in response you attempted to justify what I opposed. I am entitled to my opinion on the matter, and I attempted to propose a solution, and articulated that it would not be a simple matter of making you and the other developers use this by force or persuasion, rather that you would use it if it provided a superior API to the additions that are being made.
Since the discussion with kloot is providing nothing of benefit at the moment, I shall outline my own plans.
Starting with Shard I will start a project involving a gadget to attempt to build what I proposed. I will likely use EvolutionRTS as the basis since Forboding is likely to cooperate with anything that might improve AI games. I'll build a small basic API to demonstrate transferring data over to lua gadgets and widgets.
My first demonstration shall be influence maps overlaid on the battlefield. I've seen the widget code to do this demonstrated already by zwzsg.
So what form should the data callbacks take?
Re: Presentation Logic & The AI interface
with data callbacks you mean, the form of the Lua side (functions), that could be called by AIs?
best thing i guess, is if you create what you want/need yourself, and do it in an abstract way.. if someone else wants more, they can request, or do it themselves, in the same form.
best thing i guess, is if you create what you want/need yourself, and do it in an abstract way.. if someone else wants more, they can request, or do it themselves, in the same form.
Re: Presentation Logic & The AI interface
I may add said code mentioned is not credited to zwzsg but actually KDR, although without him I would not have been aware of it