I was looking at the Project Roadmap, and I have some concerns about meeting the next Milestones, especially from the perspective of the AI.
We have Milestone 1.0 due in 7 months, however I feel that developing a good AI is one of most important elements in having a successful game. Of course, I have almost no experience in developing such a project, but I would expect that developing a good AI is something that would take at least 1 year. Or is that something to work on also past 1.0?
About battle AI, personally I am happy the enemy is finally “alive” - and we are already reporting major mistakes (like focusing attacks on War Machines). But should we start pointing out also the smaller mistakes, or that’s for 0.8?
About 0.8, I see “basic AI” among the objectives. In my understanding, that would include already some clumsy Adventure Map AI. If that is the case, shouldn’t we have a couple of more 0.7x releases, to see that the AI starts doing the most basic things, like building what they can afford and exploring the map (even if with no logic or strategy whatsoever in the beginning)? And then have 0.8 pushed somewhere in the fall, when we might have an AI we can actually follow up to report issues…?
Something else I wanted to bring up for a while - regarding efficient AI testing: Could we have a functionality/cheat that would allow us to see all the moves the AI is doing during their turn? And I mean not only watching them on the map (by removing FoW), but also “opening” town screen, building, recruiting etc. Maybe even AI-AI battles, though these are less important.
Lastly, I see for milestone 1.0 “other lacking important features”. Shouldn’t that be part of milestone 0.9 and leave only the “lacking minor features” for 1.0?
That Roadmap is outdated and I given up updating it, because it’s absolutely impossible to predict further development. We still don’t have 0.8 released but we have done one of it’s vital parts (artifacts). We have support for videos that was originally thought to be posponed to 1.0. Development usually goes it’s own way
Making a good AI is ineed a HUGE work. I can’t say if some basic “adventure map” AI will be done by 0.8. I rather doubt it, though we still don’t know when it will be released (not soon). Anyway, a really good AI will be a probably one of post-1.0 targets. To implement great AI it needs to be able to take advantage from practically all possibilities offered by the game. Many of them are still not available in VCMI, so we should not hurry with writing AI now. (though if someone (not me) fancy to start implementing it now, I would be very happy as well ).
I currently plan two more releases of 0.7x series (0.73 and 0.74). Main features are boat and water objects support and town sieges. (The sieges may be postponed, as battles still need very much work without that.)
Other features I’d like to focus on is loading/returning to main menu without restarting application. I’m also going rewrite most of Pregame code, adding many missing functionalities and improvements.
By 1.0 we want to implement all major features. Some details (and really minor features) can be done after 1.0.
Indeed. Although, making a decent (i.e., not really smart. but comparable to the original) AI might be a lot easier.
However, no matter how ambitious the AI will be, I think Zamolxis is correct in his assessment that it will need a lot of testing. It’s not a matter of “it works” or “it doesn’t”, the question is how good it performs in a huge variety of situations. Testing these diverse situations, analyzing the AI behavior, and thinking up improvements, will take time. And the suggestions that the testers come up with will have to be tested thoroughly again. Hence (I think) the suggestion of several releases during AI development.
I also think that the suggested tools for AI analysis (making AI decisions transparent for testers) are a good idea.
I think he simply wants time to test the major features before the big 1.0 release. (Zamolxis, please correct me if I’m guessing wrong. ) I think it’s a sound policy to test major features thoroughly before a 1.0 release - however, I don’t think it matters whether these tests are done on “versions 0.9x” or “version 1.0 release candidate x” (which is probably the plan when you’re adding major features in the last step?).
[size=75]I corrected the reference to 0.9 in the OP and in further quotes to avoid any confusion.[/size]
Well, it depends where you draw the line between major & minor features, and what is considered an acceptable amount of missing/buggy minor features for the release of the 1.0 beta.
My RL job is writing requirements for various enhancements to the applications used in different departments of my company and also testing or supervising the testing of the new code (in direct contact with the programmers). So it is possible I am a bit biased in my expectations by how a project is run at my job, while I actually don’t know much about game developing.
*[size=92]FYI - to understand where I’m coming from - first of all we break the importance of the features in 4 categories: Critical, High, Medium & Low. If I would extrapolate our development plan to VCMI, it would look somewhere like this:
PHASE 1: Writing most of the code, with all tests only “in-house” (coder side only). Kinda what you did between 0.1 and 0.5.
PHASE 2: Gradual testing of all features, feedback to coders, adjustments, etc. Split in sub-phases:
Milestone 0.6 : Most basic functionalities working, though bugs are expected potentially at all levels
Milestone 0.7 : Most Critical features working, plus a good part of all others
Milestone 0.8 : All Critical features working, plus most of the High & a good part of the others
Milestone 0.9 : All Critical & High features working, plus most of the Medium & a good part of the Minor ones
PHASE 3 = Milestone 1.0 : All Critical, High & Medium features working, plus most of the Minor ones. Project is ready for beta - which is performed at this stage with a large number of testers (which might spot details I left out) and with larger volumes of data & traffic to see if the application, but also the servers can handle it (which in our case would mean for example heavy testing of the MultiPlayer functionality)[/size]*
Now, the above was just FYI. We shouldn’t compare apples with pears, so by all means the above was not meant to suggest VCMI “needs” to follow a similar plan (it’s just me who subconsciously tends to expect that because of my job ). The only thing I had in mind with my comment on 0.9/1.0, was that it would be better if we reach Milestone 1.0 with only a limited number of known issues, so that the players don’t get as frustrated as they got when H4 or H5 had their official release for example. H3 is an older (however, better:) game, but because of that, I feel it needs a very limited number of bugs or missing features when beta 1.0 is released, in order for it to stand out (but that may be just my personal perception of things, I don’t know…)
Anyway, sorry for this long diversion, which might prove pointless anyway - The way this project is going, I think feature implementation will probably not be in our list of concerns by the time we reach the 1.0 Milestone
My bigger long term worries (and I don’t know how we’ll stay with that at 1.0) are:
A good AI
Good support for mods (and particularly for most of the current WoG features)
Good support for MultiPlayer (which should hopefully be as stable & cheat-proof as possible :p)
Well yeah though this is open source project so it is a bit different then closed source development at company.
The release of 1.0 will have a huge PR … It will probably be advertised on HoMM portals and many testers will come to try it. Now that may be a good idea to get it out sooner then later because it can speed up the development (new testers, press , new programers etc.) The 1.0 here is very different then a company project which after 1.0 is expected to be finished …
Well on the other hand releasing it with some things lacking may just as you say give bad press to the project which wouldn’t be nice …
So what to do is a bit tricky … A good compromise should be reached so that people do not bitch about it being unfinished , but 1.0 isn’t delayed like forever …