Yesterday, after 8 months, I hit MS2.
Here is short list of things that I managed to do during that time:
- Items
- Inventory
- Servant
- Interactions
- Unique items and events (used to allow only certain items to be used on other certain items)
- Whole framework is more modular without almost any gameplay related assumptions
It doesn't look that impressive and even without all the breaks, all the time that I wasn't working on Dragontorc, it may look that it took much more time than needed, right?
Well... I really hate dirty prototyping. I just had enough of it in my life and I know that I will have to work like that for many years to come. And that's why I decided to do things a little bit different when working on Dragontorc. Keep everything simple and clear. Do not make any assumptions (or rather, as few as possible) over anything in Game Framework. First implementation of items, interaction with them, opening/closing doors was code driven. It was fine and pretty simple but if I wanted to do all stuff like this I would run in two problems:
You can see here that items can be picked up by wizard or by servant. Wizard has limit of 4 items to be held in inventory and they are organised in FIFO - just like in original game. There are 5 different keys (appearance is hardcoded, this will change in MS3). And there is a locked chest. Only one key may unlock it. You can then put some items into the chest (currently it may contain 10 items) or take them out of it. And you can close the chest as well.
Ok, MS2 is done. Next one is MS3 with first enemies, first spells and some better looking graphics.
Well... I really hate dirty prototyping. I just had enough of it in my life and I know that I will have to work like that for many years to come. And that's why I decided to do things a little bit different when working on Dragontorc. Keep everything simple and clear. Do not make any assumptions (or rather, as few as possible) over anything in Game Framework. First implementation of items, interaction with them, opening/closing doors was code driven. It was fine and pretty simple but if I wanted to do all stuff like this I would run in two problems:
- Code would grow big enough to be much harder to read/understand/modify.
- Adding more stuff to the game would require changes in code and this is something I want to avoid.
So after seeing that basic interactions with items worked pretty well, I decided to make interactions of Servant on items to be done with event system. And then even all interactions of Wizard with everything else (picking items up, opening doors, closing them, hitting objects - example: chest closes). Only thing needed is set of commands and conditions that will grow over time to give as much freedom in creating objects as possible. But then so many things can be done without touching the code and it is so easy to do so that will not only save my time, but will allow people to add more stuff to the game.
Yup, that's true, I want people to be able to modify game, to extend it, to add more and more items, enemies, locations, almost anything that they will want to have in the game. This of course brings another question. How this will be handled in the game which is basically almost linear (well, there are sort of hubs but you have to solve certain puzzles one after another) action-adventure? Probably you may guess the answer on your own. If not, it will be revealed sometime in future.
Now some technical details. I mentioned something about events. What are they? They define interaction between items. For example, key may do "unlock" and chest, being in state "locked", may accept "unlock". If preconditions for both sides are fine then we may perform the event. This isn't anything new and in fact, it is something that I wanted to have before I started to read about Dragontorc. And you know what? Steve Turner did event system in Avalon. And that is simply amazing. So I just took name "event system". And because I am not limited by ZX, I could make it bigger, more universal. So I did. Game Framework is responsible just for detecting when something should happen but all interactions/actions are defined in xml files.
One important thing here is that I wanted to keep controls simple and as in some cases there can be few things to be done on an item (servant may either take something out of chest, or close it) currently only most important is performed. This may or may not change. Or maybe I will add some optional doing other possible actions. Of course I will have to add information about currently available/selected action, so players won't be surprised when they act on an item.
And not only events are defined in xml files, but also how items/actors behave, how much space do they take in physical world. Wizard hovers above ground. Key may be thrown. Chest just drops on the ground and cannot be moved.
Ok, that's it for now. Just check the video.
Ok, MS2 is done. Next one is MS3 with first enemies, first spells and some better looking graphics.
MS2
Started at: 2011/05/27
Ended at: 2011/11/21
Actual time taken: I have no idea, probably I will just remove this info.
Status: success. reogranised lot of stuff to make it easier to develop/extend game in future.
No comments:
Post a Comment