nicely into place
Today I managed to change pclinmove so that it is now possible to walk on an object that itself moves. This can be used for moving platforms, elevators, vehicles, ... and it works very well indeed. With this step done I think that a great deal of the machinery needed to develop the Crystal Core game logic is ready now. The only thing I have to do now is wait for the art to arrive (new levels from Xotic and hopefully some models that I can use too). When I have that I can implant a few quests and things to do and that can be released as the first tech demo of Crystal Core.
I want to work a *little* bit more on the level before releasing it and there are still a few minor things I need to do here and there.
On the CEL side things are looking good now. I have a nice working game which is almost finished. One thing that I really would like to do now is to have support for moving on moving objects. i.e. imagine an elevator which is in itself a moving object. When you go inside that elevator and you press a button it will go up or down. In the mean time you can still move on the floor of the elevator. For trains or other vehicles this would work too.
I started sectorizing the game level to get better performance but instead I got worse performance! The reason is easy. There are two sectors: 'inside' and 'outside'. There are about 10 portals from inside to outside (windows and doors). In the 'outside' region there is a landscape mesh object. This object will be drawn essentially 10 times (if 10 portals are visible). Everytime it will be drawn restricted to the portal area but still it means the landscape mesh has to do LOD and other setup 10 times. This is slow. So I started implementing a new feature in Crystal Space. Basically you will be able to enable 'noclip' for a mesh. When this option is set the mesh will not be clipped to the portal at all and it will also only be drawn once. That means that on the first visible portal the mesh will be rendered completely and all other portals to that same sector will just leave the mesh unrendered. This is all nice in theory and I even implemented it but now I have the problem of getting it to work :-/
I also got a new idea for a visibility culler. This idea was sparked from a discussion on the #Once channel. Basically they are having the problem that if you close a door (and the doorway itself is a portal) then it will still render the contents of that portal in many cases. The reason for that is that dynavis is not a perfect culler and the door object and doorway are very close together. This decreases the chance of dynavis culling the portal. Also if frustvis is used then no such culling happens at all. So I'm considering making a new culler that is very simple in nature and would only attempt to cull away 'complex' objects. A portal is a complex object since a portal represents an entire sector behind it. But other objects can also be marked as complex (typically as a function of number of polygons). I still have to decide on how exactly I would do the culling then. The end result should be a culler that is a lot less expensive then dynavis but would be able to cull away portals that are covered by a closed door.
Literally! My work on CEL is progressing very well now. I basically have a very simple game right now. At the start you enter the level in a room with four doors. Three doors are closed and you have to find the right key to open each of them. So the only option is to go through the open door. The doors open on approach and close again when you go further (unless it is locked of course). Picking up a key unlocks the right door. There is also a sphere that you can click on and when you do an entire section of the floor starts rotating so that you can have access to another part of the level. So plenty to do already but still a lot of work. Here is a list of problems I encountered so far that I still need to solve:
In addition to the problems encountered above I still need the following enhancements to CEL:
All in all I'm very happy with the way this is working out. The quest manager is appearing to be a very useful tool for making game logic. It is even powerful enough to completely drive a simple game. In real full games you would of course combine it with behaviour logic for more specialized control.
There are at least two property classes that are interested in creation of other entities. One is pcspawn which is a property class that is responsible for spawning entities of a given type at certain intervals. This can be used for creature spawn points for example. Or places where health-kits can spawn. The other property class is pcquest. I would like to add a reward there that creates an entity. The problem with entity creation is that entity creation is not simply a matter of making the entity. You also need to supply a behaviour and property classes. And you also need to set up those property classes. pcspawn partially solves that by allowing you what property classes and behaviour to use at entity creation. However that doesn't help with setting up those property classes so this really is not very useful. The best way to solve this will be to allow entity factories. This is a new concept I will soon add to CEL. That way you can define an entity factory exactly like you would define an entity (in XML addon). pcspawn and the pcquest entity creation reward can then refer to a factory to create the entity.
With all the new work that I have been doing I think it is soon becoming time to document all this. The CEL documentation is very limited and these new property classes are rather advanced. Documentation is badly needed. This will be my next task after finishing the simple game.
Made some good progress on celtest now. I rewrote it so that it now uses the zone manager instead of pcregion. That makes it easier to seperate the world file from the entity definitions. I'm now busy moving all entity creation from code to that entity file so that we can easily substitute other levels + entity definitions for celtest. When that's ready we can put two levels in CEL/CVS: basic_level and simple_game. The latter will be the new level that I'm creating which will have entity definitions that make it an actual simple game.
Looks like Eric is getting his iMac soon. This will be a great boost to the community if Eric gets faster hardware. Even with his very old hardware he manages to do a lot of amazing work on Crystal Space. I can hardly imagine what he will be able to do with a faster computer. Now hopefully the remaining money (plus new donations, hint hint!) can be used to spice up my computer situation a bit. Because after Eric gets his new computer I will be the one with the lowest-end hardware.
Bah, today is one of these days where you spend more time debugging some stupid problem then doing useful coding. In this case the bug is probably not even caused by me. The problem is that on destruction of a mesh wrapper there is a 'pure virtual method' called. Debugging this is hard since the program doesn't crash so you can't get a decent stack backtrace easily.
If all debugging fails I might have to do a 'binary CVS search'. That's the technique of going back in time with CVS trying to find the exact moment at which the bug occurs.
Wish me luck!
Update! The problem is solved now! Time to move on :-)
The new map is progressing nicely. Please don't expect too much of it. I'm not an artist. It is just going to be slightly more interesting then the current celtest map (partsys). It will contain a landscape and a few more areas to visit. Soon I'll start adding the game logic to it. That will require a bit of coding though. More in particular I need to:
So I have my work :-)
The celtest application and map are getting a bit old and primitive. I'm working on a replacement which will be a little bit more interesting. It will be more like a game with puzzle elements to better demonstrate the things you can do in CEL (like quests and so on). I'm making the map in blender using blend2cs.
It is always satisfying when things work as you intended. In this case I'm talking about the sequence stuff in the quest manager. Today I managed to get a first working sequence in the test quest for celtest. It doesn't do much. Just print out a bunch of numbers during one second. But it proves that the system works. Additionally even persistence works. I can save the state of the entire quest including the running sequences and then later load it again. The quest and sequences just resume where they left off. Pretty nice.
The work will now be in adding more sequence operations to the quest manager so that this actually becomes useful. Also it will be great to have a quest trigger that fires when a sequence finishes. That way you can delay switching of the 'dooropen' state in a quest until the door is actually fully open.
We got a nice offer from Pace University to donate the full Macintosh computer to Eric. If that deal goes through then we need to find a new purpose for the money that has been donated so far (around $1000 USD). One idea is to replace my linux computer which is slowly starting to have problems (bad HD and overheating problems). Also it is underpowered with respect to 3D hardware which means we can't easily test the more advanced renderer features on linux (most of the other CS team members are using Windows these days). And of course I wouldn't mind a new computer :-) But of course that means we need even more money then $1000.
I'm thinking about adding a nice new quest to celtest. Basically I would add a door entity to the world which is initially closed. If you approach the door you would get a message saying something along the lines of 'You need to find a key to open this door'. Then you have to go to another room, pick up a key and with that key you can open the door. I still have to do a bit of work before I can make such a quest but I'm not that far from this goal now. Basically the sequence stuff needs to work and I also have to work on a trigger for the inventory system.
Some time ago I came to an important realization. The persistence system in CEL is *almost* general enough so that you can do the following:
Not much is needed before this can work. It requires that game A and game B are pure CEL games. This means that they should have a behaviour layer that is a plugin (for example, the python behaviour layer or a custom one that is build as a plugin) and it requires that I add a little extension to the persistence system so that the SCF ID of the behaviour layer is saved too. That would allow us to dynamically load the behaviour layer plugin when the savefile is loaded.
Once this is done you would basically be able to run (for example) the CEL boulderdash game and then load a save file from Crystal Core in that. This is fun stuff :-)
I'm working fully on CEL now. The idea there is to create a full fledged quest manager which will be used for defining the story elements in Crystal Core. Basically the entire game logic and game structure will be defined with the quest manager in XML. The quest manager basically works but right now I'm working on adding sequences to it. I would have liked to use the existing engine sequence manager in CS but unfortunatelly the design of that doesn't make it easy for me to use that in CEL except for small and easy cases (like a fan that rotates or a light that goes on/off on proximity). But in all other cases (like doors that open and close in response to some quest element) we need to be able to save state and resume sequences in the middle later. This is not possible with the CS engine sequence manager. The new CEL sequence manager is part of the quest manager as it is closely tied to that and it will also reuse the triggers of that.
After this I hope I can incorporate some real working quests in Crystal Core. Hopefully Xotic will soon have some new levels so we can start to work on the first tech demo then.
I'll keep you posted.
|<< <||Current||> >>|