Should the given source code at http://www.mojomonkeycoding.com/jmeforum/viewtopic.php?t=686 with the bug fix reported by Shmooh added to the CVS?
If you vote no, could you please post the reason as to why you voted no?
PS. The full code (with the bug fix) can be found at http://www.myjavaserver.com/~digiwired/ai-code.zip
I’m going to hold off until I can see your full GansterDemo. I just want a chance to see all the pieces working together.
P.S. When did your coding style change? And my God why did you start using arg_* for parameters?
it was a thing to know what your refering to was an argument rather than an internel variable or a variable…
Coding style change? where? how? when? omg a flying saucer!
PS. Has it changed for the better?
I’m also in favour of waiting until the system can be tested more thoroughly.
I’d also argue against its inclusion in the main jME jar file. We already have significant package bloat. Perhaps this sort of functionality would be better suited for an external utility jar. I’m interested in an extremely lean core API specification that does what it’s supposed to extremely well and nothing more. All the other cool features and additions can be integrated separately.
Some things are cleaner, but the args_* is too remenisent of Hungarian notation for my liking… being as this is a Java API, we tend to use Sun’s standards, although we deviate now and then.
Yeah, it really has changed DP, what happened? As for inclusion, is AI part of "a high performance scene graph based graphics API"? Seems out of place in jME core (to me at least.) But a good downloadable add on for people who want it.
Hungarian notation? since when are there strict rules for coding styles? 8-O
Shows how uneducated I am I guess…
Do you have a paper of some sort explaining sun standards?
@Eric, and mojo, sure, a test is fully underway that will take the current AI to the limit providing hundreds if not thousands of AI agents ( scenegraph permitting ofcourse ) all thinking intelligently.
Has anyone played hitman codename 47? I was hoping to get the enemies AI minus the pathfinding…should be interesting…
@renanse, I have just PM mojo about splitting up jME into its various parts; Sound, Graphics, AI, and Physics. So if someone wanted to use FMod instead of OpenAL they can do so without holding up the OpenAL baggage with them. But thats a discussion for another time, another day.
Hungarian notation? since when are there strict rules for coding styles? icon_eek.gif
Since the point when people came together to work on a single project and realized that by not standardizing the code base it became very difficult to manage code one had not written. If the code looks the same, it's easy to work on code you did not originally write.
Do you have a paper of some sort explaining sun standards?
I am all for adding the AI could to the main jar. It would make programming a game 10* simpler. (Especially a network game).
a new update is up, removed things that really shouldn’t be there. E.g Threads in the ScriptLanguageHandler class which is now deleted.
I voted no.
The reason is simply because the ai you include will be what we believe to be a suitable ai for developing games with jME. This will only be a matter of opinion as ai itself is an undeveloped field and the minute someone/some company finds a better solution for ai than the one jME implements people are going to overlook jME and think it’s out of date…
and the minute someone/some company finds a better solution for ai than the one jME implements people are going to overlook jME and think it's out of date...
Not really sure if this is a valid reason as people may overlook JME (or any other package) for a veriety of other reasons. Including AI (may be as a seperate package) will add more functionality to JME encouraging developers to come on board especially if they want to do games. If some of these developers are better at writing AI code, then they can simply ignore the package and develop their own.
I think people can decide for themselves wethere to use it or not depending on what they want to do with it. My vote is Yes.
What I was referring to is another game package other than jME having better AI than jME… when AI becomes a defining feature in how interesting a game is to a game player jME’s AI will eventually be out done by another complete package. I’ll vote yes only if another project is responsible for the AI included with the jME package (seperate from the jME project). AI projects very rarely are outright successes as this requires solving AI and then using the AI solution in a cruder form in a game running on a non-parallel computer.
I’m more than willing to put the AI stuff in as an official module, when I see some impressive stuff out of it (which I’m sure will happen). So, I’m going to wait until DP et al have something to show, then we can discuss if it’s ready to be “official”.
Ive decided to seperate and rename stuff. E.g. the AISystem class will no longer be called AISystem, it will be called GameSystem. Because that is what it does…it manages entities, nothing to do with AI!
Also, AgentActions will be renamed to EntityActions…again, because they have nothing to do with agents.
Is that OK with everyone?
After this, i will produce that awsome demo that mojo was talking about.
What is it that your GameSystem do? If it does the same as the game state system I posted on code review, we could consolidate the two…
Looking forward to that awsome demo
the game system does exactly what the AISystem does. It sends messages to entities, checks collisions with entities, fires global events to al entities…stuff like that.
Yeah, i think we can bring those two together me thinks…
well, mojo gave me this idea of flying airplanes one chasing another. Ive decided to make this test into a GameSystem test instead because I think the AI controlling airplanes is a good test for the GameSystem and its performance…
So the test im making will be two fold: 1) the GameSystem, and 2) the LaserTrail…
How soon? Well, can’t really say, because i dont even know. Ive never done plane behaviour before, so I dont really know. But whatever comes out of it, its gonna be good i promise you that
Guest, if you stick around long enough, im sure you will find out…
I created the EntityResource class, and the zip is found here if anybody is interested.
Now you can do this:
in a text file and then do this:
HamsterEntity = (HamsterEntity)EntityResource.createEntity(urlToText);
hey DP can you cook up a small test or release the VZ2 source as promised it will be helpful in allowing me to understand it
thanks in advance