coderJeff wrote:yes, I think the most interesting part of the project for contributors was writing the AI logic. I think that's the key part to keep.
Definitely. That's the entire point of the simulation =D
coderJeff wrote:What I would have in mind:
1) Minimally fix the (possibly only known) last version of the game so it compiles with current fbc and let this be our reference prototype (even though the structure and modularity of the original program is fragile). Overall, the original concept is good, we don't need a new idea.
Agreed, the original concept is very good. It can get better, I'll draft some of my ideas and publish them here later, so make sure that you (and you guys, too!) tell me what you think. However, I wouldn't conserve the old code. I'll also show you what I have in mind in this respect, preparing a pretty barebones 'framework' to demonstrate it.
coderJeff wrote:2) Rewrite in the style of your framework to give it a robust implementation. (Actually, this game/AI simulation could be test case for some portion of your framework, but I would not make that a requirement, so this either project can proceed independently, regardless).
That's not a problem. I'm busy with some things now (which, incidentally, will also be useful in this context, too), so as soon as I'm finish I'll publish a first draft of the code.
coderJeff wrote:3) Run the AI challenge on the forum just as before. I think it would be successful.
Yes, I think so too. We shall see ;)
coderJeff wrote:And, if I were to do a sequel, it would be with tanks. The overall implementation of the program would be almost the same. Difference would be in writing the AI, having already left, right, back, forward, & fire, then adding turret left, turret right, new for responses.
I'd say that we stick to the original idea first, and implement a running framework for it. Once that is in place, we can easily modify it to accomodate anything else.
coderJeff wrote:Case study follow up:
There are 3 things that made this AI challenge project successful as a community collaborative effort:
1) leader to keep the project moving
I'd say that you take that role, as you were there when the original was released and know the mechanics. I can provide the code support, if you agree.
coderJeff wrote:2) simple design (main loop enforces the rules of the simulation and calls the AI)
Yes, that's not very hard to achieve. I can post a simple implementation of a cooperative multitasker
, that should be our preferred method of implementing the loop. And also, provides an interesting frame for some cool stuff ;)
coderJeff wrote:3) modular components (AI) written in FB, that have a simple and uniform API
This is also easy to achieve using an ECS framework. I'm currently working on a class library to do serialization, since this approach is entirely data-driven. It does have, however, some pretty important security vulnerabilities (as we're injecting code into the process, and that could be potentially dangerous).
As for the rest:
coderJeff wrote:In contrast, the reboot, (which I think was going to be called "Atto"), had ambitious changes: new physics, destructible ship pieces, ship designer, openGL, assembler like virtual machine AI, multiple ships, and so on.
I'd say that we should stick to the simple, asteroids-like physics of the original. After all, this is about coding an AI, the rest is purely eye-candy.
OpenGL: we can consider it at a later stage. Eventually, it should be done in OpenGL however.
Multiple ships: trivial. This could give rise to very interesting and hectic battles, indeed!
Destructible ships, ship designer: Some of my ideas go in this direction. We'll discuss them later.
ASM-like VM: I definitely think that this is the approach we should take. A simple DSL
could be implemented to interface with the game code. Scripting-like languages like LUA are out ot the question, as we need it to be as sandboxed as possible. I have a Forth
implementation that runs on top of FreeBasic (to use as an internal tool for scripting) that can be modified and used for this purpose, and makes interfacing with the underlying framework trivial (no need for an interfacing layer; we can simply push the needed parameters and data to the VM stack).
Give me a little time, and I'll prepare a draft with several ideas that we can use. Everybody
can contribute to this project, so make sure that you make your voice heard =D