AI Factory

[msm8bball]

I've never understood why Java developers make everything so complicated. What's wrong with exporting a basic set of proceedural functions or simple classes in the interface and letting AI writers apply their own abstractions (Factories, Getters, Services, Gateways, etc) on top of that? Coming from a Python/Lua background I simply cannot comprehend why anything other than "here is an exported variable/function with a namespace prefix" should be forced on the user of a library.

Also I think the Java intefaces need to be moved into the "Test AI" category and/or git submodule and not built by default. Under Gentoo the JavaOO and/or NullJavaAI have been responsible for 90% of build failures on my system over the last 5 years which is why I now have the -java use flag set in the package.use file for spring.

Also most of us don't want a .Net interface. Spring is cross-platform, please keep it that way.

I want a .NET interface. Write it so it's usable by Mono and it'll be plenty cross platform. It'll also give developers a nice option of using Python (through IronPython).

Java may have been my first language, but I'm much happier with .NET's capabilities.

[gajop]

I've never understood why Java developers make everything so complicated. What's wrong with exporting a basic set of proceedural functions or simple classes in the interface and letting AI writers apply their own abstractions (Factories, Getters, Services, Gateways, etc) on top of that?

I've made one Java AI, but I don't know the details as far as the loading goes. Usually Java makes everything look complicated, but that's usually only in comparison, as other languages (most notably Python) oversimplify things which are inherently complex.

I bet the Java loading is so complex so that you could run it in all sorts of weird ways that you normally wouldn't in the case of a set of "procedural functions". Just take a look here: http://en.wikipedia.org/wiki/OSGi.

Now.. normally that's not needed for the simple case we have here (we are not an Enterprise/Big Bank Company), and that's why Python is often used instead of Java to just get shit done.http://en.wikipedia.org/wiki/OSGi


@msm8bball:
Create .NET support in a OS agnostic way and I'm sure the Spring devs would include it :)

[msm8bball]

I've never understood why Java developers make everything so complicated. What's wrong with exporting a basic set of proceedural functions or simple classes in the interface and letting AI writers apply their own abstractions (Factories, Getters, Services, Gateways, etc) on top of that?

I've made one Java AI, but I don't know the details as far as the loading goes. Usually Java makes everything look complicated, but that's usually only in comparison, as other languages (most notably Python) oversimplify things which are inherently complex.

I bet the Java loading is so complex so that you could run it in all sorts of weird ways that you normally wouldn't in the case of a set of "procedural functions". Just take a look here: http://en.wikipedia.org/wiki/OSGi.

Now.. normally that's not needed for the simple case we have here (we are not an Enterprise/Big Bank Company), and that's why Python is often used instead of Java to just get shit done.http://en.wikipedia.org/wiki/OSGi


@msm8bball:
Create .NET support in a OS agnostic way and I'm sure the Spring devs would include it :)

If I knew how, I'd do it. But unfortunately I have no idea where to begin. I'm fairly knowledgeable about the .NET side of things, but I have no experience with C++. I tried looking at the Spring code and I didn't really understand it.

I'd be happy to test or work with someone that is willing to give me a ton of directions.

[SpliFF]

I want a .NET interface. Write it so it's usable by Mono and it'll be plenty cross platform.

That's the theory, not the practice. What happens in practice is developers use Windows-only classes and libraries that cannot be ported to Mono for legal (patents) or technical reasons. Mono is considered by many linux users/developers to be a bloated dependency with inherent portability and legal issues. Many people mistakenly believe C# is an open standard but that is only true of versions up to 2.0 (latest is 5.0).

It'll also give developers a nice option of using Python (through IronPython).

We already had the option to use Python through an actual Python interface. Nobody used it.

Java may have been my first language, but I'm much happier with .NET's capabilities.

When you say "capabilities" are you refering to the language or the available class libraries? Only the first is really portable (even then Mono only supports up to version 4.0) which is why Mono fails to run about 70% of .NET code despite over 10 years of development.

The Free Software Foundation's Richard Stallman has stated in 2009-06-25 that "[...]we should discourage people from writing programs in C#. Therefore, we should not include C# implementations in the default installation of GNU/Linux distributions or in their principal ways of installing GNOME". In 2009-07-16, Brett Smith (also from the FSF) stated that "Microsoft's patents are much more dangerous: it's the only major software company that has declared itself the enemy of GNU/Linux and stated its intention to attack our community with patents.", "C# represents a unique threat to us" and "The Community Promise does nothing to change any of this".

Teaching people .NET is like weaning babies on mashed banana. One of these days you're still going to have to learn how to eat solid food.

[gajop]

Well I'd be glad to help as my time allows it. If I had the time I would go on and create an interface myself, but I don't so I prioritize things (try to keep that in mind). I actually started it once, but ivand started working actively on it so I thought I might as well do something else.

First thing you should do is read this thread: http://springrts.com/phpbb/viewtopic.php?f=15&t=27062. Then ask us some questions. I even created something myself back then (nothing working though), but it's been a while and I'm not sure I still have the code or if I understand it.

PS: If you don't know C++ and probably even awk it's not going to be easy...

[Petah]

Please don't derail this topic.

It is about getting the Java AI interface back in working order, not about any C# interface.

[AF]

Part of the changes to the Java APIs came because of the pureint push by Hoijui. He may have had other ideas but you'd have to ask him about that

[Petah]

Part of the changes to the Java APIs came because of the pureint push by Hoijui. He may have had other ideas but you'd have to ask him about that

I have asked. While I do agree that implementing it to his ideal implementation would be good, given that it currently is a defunct state and has been that way for a long time, I think it should have been forked until such a state that it is stable.

[gajop]

I have asked. While I do agree that implementing it to his ideal implementation would be good, given that it currently is a defunct state and has been that way for a long time, I think it should have been forked until such a state that it is stable.

Blah.
It's not defunct, it works in most cases, just not when you have two of the same AI.
It's no point to talk about what should have been, it won't be reverted now (it wasn't reverted when I reported it within a month of the pureint changes: http://springrts.com/mantis/view.php?id=2162).

Really try to realize there are nearly no AI devs left and no engine dev is dealing with the AI side of Spring.

[SpliFF]

Really try to realize there are nearly no AI devs left and no engine dev is dealing with the AI side of Spring.

At risk of derailing again that statement is untrue. What is actually happening is that active AI development has moved from traditional C++/Java interfaces to the Lua Gadget interface (I know of at least 4 Lua AI currently being worked on). There are 4 very good reasons for this:

1.) The traditional interfaces and AI built on them have been the direct causes of a HUGE number of build failures and engine crashes over the years - long before pureint was even a factor.

2.) Game logic is increasingly being handled by Lua Gadgets rather than the engine and this puts a lot of game events and statistics outside the reach of traditional interfaces.

3.) Several native AI were Windows-only and this was starting to piss many people off.

4.) The number of extra dependencies required and amount of code to maintain in the interfaces.

The reasons typically given for wanting a native interface are:

1.) It's the author's preferred language

2.) Performance reasons

The first reason has some merit but the second is highly debatable.

Anyway this topic seems pretty moot unless someone puts their hand up to do it but other than hoijoi I know of no Spring devs interested in maintaining the native interfaces and a few in favour of their complete removal (search the forums and chat logs for verification, this topic has been raised several times already).

PS. Petah, if you feel i'm getting off-topic I have no objection to a split. Personally I think this is relevant to the question of why the Java interface is in the state it is in.

[msm8bball]

That's the theory, not the practice. What happens in practice is developers use Windows-only classes and libraries that cannot be ported to Mono for legal (patents) or technical reasons. Mono is considered by many linux users/developers to be a bloated dependency with inherent portability and legal issues. Many people mistakenly believe C# is an open standard but that is only true of versions up to 2.0 (latest is 5.0).

Generally, people use Windows classes when they're working with GUI's. Considering we're discussing AI development, I don't think that would be much of a problem.

We already had the option to use Python through an actual Python interface. Nobody used it.

Although I do not use Python other than embedding it as an Iron Python debug console in applications I develop, I do understand its merits. Maybe it's not popular as an AI development language for Spring. But my point was more that allowing .NET opens up the possibility for many languages. C#, C++, Visual Basic, Iron Python, Iron Ruby, F#, J# or whatever is possible on the CLR under Mono. That knocks out a lot of birds with one stone since they all compile to CIL. In favor of the JVM, we could do Java, Groovy, Scala etc.

When you say "capabilities" are you refering to the language or the available class libraries? Only the first is really portable (even then Mono only supports up to version 4.0) which is why Mono fails to run about 70% of .NET code despite over 10 years of development.

Both. I prefer the syntax of C# and Java over other languages. And I like the class libraries of the CLR over the ones available in the JVM.

Teaching people .NET is like weaning babies on mashed banana. One of these days you're still going to have to learn how to eat solid food.

That's judgmental. I work in IT, I develop line of business applications for our small-medium sized company. I use C# with .NET. For my line of work, a high level language on a well supported platform is more than enough to get by. And judging by the number of people that like writing Spring AI's with Java, it's enough to get by here too. If you want more people to become active with Spring as AI developers, then making it possible to write AI's in a high level managed language will make it much easier. Not everyone should have to be familiar with C++.

While I respect the work RMS has done, he's so entrenched in his viewpoints that I don't agree with all of it. While I understand why he and the Linux community are anti-Microsoft, that doesn't mean we can't take advantage of the parts that are not patent encumbered. And Mono doesn't have any of those issues that I'm aware of, so I feel like there shouldn't be a problem using it.

I have asked. While I do agree that implementing it to his ideal implementation would be good, given that it currently is a defunct state and has been that way for a long time, I think it should have been forked until such a state that it is stable.

Agreed. Slow pre-pureint AI's are better than not functional AI's.

Blah.
It's not defunct, it works in most cases, just not when you have two of the same AI.

That's a pretty big limitation. What good is one AI playing against a human, even a smart one? And it's much easier to see how you're AI is reacting to its conditions by placing a bunch on the map and watching them run.

It's no point to talk about what should have been, it won't be reverted now (it wasn't reverted when I reported it within a month of the pureint changes: http://springrts.com/mantis/view.php?id=2162).

Is it really that difficult to revert? I'm not really familiar with how much of the interface has changed or how difficult it would be to roll back to the pre-pureint interface.

Really try to realize there are nearly no AI devs left and no engine dev is dealing with the AI side of Spring.

Perhaps the old adage "if you build it, they will come" is applicable?

Please don't derail this topic.
It is about getting the Java AI interface back in working order, not about any C# interface.

I started the topic, perhaps I should have some say in what the topic is? Although I didn't mention C# in my original post, the intent of the post is "let's get a managed high level AI language working". Java or C# would fit the bill nicely.

If you want to move the C#/.NET discussion into a separate thread, I'm fine with that. But I believe they go hand in hand. Our issue is that Java is not working-so we need to decide on a plan of action. And before we entirely re-implement the Java interface to get it working again, we should be asking ourselves "Do we want Java, or .NET, or both?" so that we can plan accordingly.

I kind of view it as "well, my Windows computer has died and I need to upgrade my version of Office anyway. Should I go with Windows again, or a Mac, or Linux, or dual boot". I feel like metaphorically, we're at the same spot with the AI interface.

[CarRepairer]

I started the topic, perhaps I should have some say in what the topic is? Although I didn't mention C# in my original post, the intent of the post is "let's get a managed high level AI language working". Java or C# would fit the bill nicely

Lua is higher than both of those. Name one reason to use anything but Lua? You can write a LuaAi in an hour. Spliff expounded on the topic already.

[msm8bball]

I started the topic, perhaps I should have some say in what the topic is? Although I didn't mention C# in my original post, the intent of the post is "let's get a managed high level AI language working". Java or C# would fit the bill nicely

Lua is higher than both of those. Name one reason to use anything but Lua? You can write a LuaAi in an hour. Spliff expounded on the topic already.

I don't like the language, and I want to experiment with .NET features such as the DLR and event handlers in an AI.

[SpliFF]

Name one reason to use anything but Lua? You can write a LuaAi in an hour. Spliff expounded on the topic already.

I don't like the language,

Tough. It underlies the entire process of building and configuring a Spring game and defining the game rules and the properties of units. Even with the unitsync interface you'll need a Lua parser in your .NET code to get at the really interesting data. Lua is a fundamental part of Spring and you can't escape that.

The way I see it your argument is that MONTHS of another developers time implementing something that saves you DAYS of learning a new language is a good tradeoff. You won't win that argument here.

I can code in 15 computer languages. I learnt them because often the best tool for the job is the one that's already available. I wouldn't code a website in Python any more than I'd write a CLI in Javascript despite both of these things being technically possible (eg, brython and node.js)

and I want to experiment with .NET features such as the DLR

You can do that without writing an AI and it serves no real purpose here. It certainly doesn't magically make a whole range of other languages available as Microsoft would have you believe. There are other hurdles involved and performance issues to consider.

and event handlers in an AI.

We have those. They are the fundamental building blocks of a Lua Gadget and by extension a Lua AI.

Build it and they will come

We tried that with Python and they didn't.

Anyway your arguments don't address the key issue. Spring as an engine has evolved beyond running only TA clones and as a consequence a lot of data the AI will need is no longer directly accessable from C++ but needs to be serialized out of the Lua sim data. Not only is this an expensive process but it forces game authors to provide data in a compatible format with the interface. As games evolve new concepts like additional resources, custom unit behaviours and new win conditions native AIs will not be able to access this data (Spring1944 is a perfect example). This makes native AI obsolete and future removal is almost inevidable*.

* I'm not an active dev so I can't speak for others but the fact that none of the people who are actively writing engine code have chimed in here should tell you something.

[Silentwings]

For the moment I'm still learning my way around the mod side of things, but I think its likely that at some point in the next couple of years I'll become curious about working on the engine.

On a less important topic; I looked into it and the barrier for me against starting work on an AI for BA is that (1) I don't want to use lua for a serious coding project because its syntax is and (2) The wiki on C++ AIs is very bleak and can't even tell me whether there is a suitable C++ API in existence.

[SpliFF]

The AI issue is a bit off-topic because it's mostly a game-side issue (but there is an active discussion here). Trends in the engine development are away from supporting any particular game (ie, *A games like BA) and towards pushing more game logic into Lua. This makes engine-side AI problematic because the engine can no longer presume to know what data/callbacks the AI needs (but again, that's a different discussion). Thread split. Makes no sense here.

[gajop]

Since we are also talking about a lack of AI devs, I can also give my guess that the lack of them is due to not having as many languages supported.

And before someone starts about the Lua AI, I've never seen an AI competition with a Lua AI. Granted, I've only participated in about five of them in different fields entirely (from 2D turned based games, 3D rts, to real world robotics).

On the other hand in nearly every competition there was a AI written in C/C++, Java and C# and most had a Python one as well.

Also I don't think we have any decent AI documentation (I remember abma was hosting the Java AI docs ages ago), and you used to need to build the engine from source to get all the needed files for development (e.g. jars with source).

Ideally, the AI devs should never need to compile the engine, and the docs should be available online (preferably generated each release and put on the wiki). So let's fix that first...

PS: I'm looking at the engine from time to time, but I don't think I'll ever be much more than a random contributor, as I only really want to do the things that interest me and help me create something that uses the engine.

[Silentwings]

...wether AI devs can be arsed learning lua.

From another thread. This is not the issue; learning lua is dead easy and the Spring API is also not hard to work with. The problem is that lua is a toy language and not a powerful tool; it has an idiosyncratic syntax, lack of clarity over variable types, no debugger, limited stacktraces ... its great if you want to write a few hundred lines of widget but imo its not well suited to anything much bigger.

[gajop]

Moved the couple of offtopic posts from http://springrts.com/phpbb/viewtopic.php?f=12&t=30204 to here

[Petah]

(deleted this, posted it in the wrong place)