The following was posted to the project-ironfist mailing list in 2012
Pitsu asked some questions about our capabilities which I thought deserved sharing.
Since we can modify the source code by rewriting selected portions in C/C++, we can change virtually anything. But, depending on how it's built in the game, some things are easier than others.
>>1. Is there a limit how many decorative objects, spells, skills etc can be added.
I believe all three of these are represented by a single code, with length one byte.
It appears that adventure map objects store some of their data in a field of length 5 bits, which means that operations involving them decompile slightly poorly, and thus this part of the code is less well-studied. But it appears that the codes are actually signed bytes, meaning that at most 128 of them can be represented -- and, in fact, PoL already went over this limit, and got around it by using the same code to represent multiple objects, using other information to distinguish between them. If we want to add anything, it would probably be best (and relatively easy) to treat them as unsigned bytes, and bring the limit up to 256. It would take a bit more work to use multi-byte codes.
Spells and skills are stored similarly: each Hero object has an array that indicates the hero's knowledge of eachspell and skill. Spells are represented by one byte codes (unsure if they're signed), though we are nowhere near to hitting the limit. While skills do have indices, they aren't really passed around as codes, except for maybe the witch hut. I don't really see anything stopping us from adding arbitrarily many secondary skills.
>>2. Can totally new game mechanics be added (quest guards or huts, ambush type events). How much of the new will be coded into game (agg) archive (applies to all maps), how much be map bound (map specific script)
Yes, they can, and they should. How much will be coded into the AGG? None -- AGGs don't contain code. How much will be coded into the executable? The new mechanics this team produces should probably all be coded into the game, as it will likely be easier and more reusable than implementing in map scripts. There is, of course, currently no scripting capabilities in HoMM II maps, though that can be fixed.
My understanding of HoMM III: WoG is that it works primarily by inserting breakpoints into the original games, and is hence reliant on event-based scripting. We are actually recompiling the game with modified source code, and thus do not have that limitation.
>> 3. Can the AI be taught to use the new content. For instance if AI has no clue how to use seer's foreseeing abilities, it may be a serious blow to fun and need a different approach.
Yes, and this would be relatively easy, purely because the current AI is a joke, and performs only trivial analysis when making its moves. It also does not know how to use some of the existing content, such as the Teleportspell.
>>4. Not important for development of this project, but the community would certainly be interested whether we can fix the current H2 problems (like full movement points of rehired heroes or gremlin rush)
Yes. In fact, due to the way heroes are stored, I believe this would be particularly easy.
Spells
To implement a new spell, there are several steps that must be done:
How to actually implement a spell's behavior is outside the scope of this article. Do note that the game has some standard machinery for some types of spells, namely, status effects, and ones with normal combat animations.