In case you haven't seen it yet there is a nice deathmatch type game at www.nexuiz.com. It is full free (both art and code) under the GPL and it works on linux and windows. The graphics are nice and I think this is the kind of game/demo that someone should make with Crystal Space too. Crystal Core is almost going to be that except that Crystal Core? is a single player FPS and will have more complicated story mechanisms and interactions with the levels (like vehicles you can control and other stuff like that). I think one of the tasks that I need to tackle soon is to implement some kind of shooting/weapon system in the celtestdemo which I can then use as a proof of concept for Crystal Core?.
Speaking of Crystal Core?. Xotic is back and has shown me a few new things he is working on. Hopefully we can soon get a full set of levels and release the first tech demo (after I added some logic to that of course).
I have been working hard on documentation the past few days but a lot more needs to be done still. More specifically I would also like to document CEL better. One question is if the CEL documentation should be integrated with CS or not. I personally am inclined to think yes but not everyone agrees with that (given that they are technically separate projects).
For CrystalBlend I'm waiting until I get some feedback from Erwin Coumans. He is going to attempt to integrate the existing old GameBlender logic into the current CrystalBlend.
That was it for today.
I did it again! I started yet another new project. As if I don't have enough todo already
The new project is CrystalBlend. It is an alternative to the GameBlender project which you can use to create games from within Blender. The problem with GameBlender is that it is no longer maintained well and is showing its age. A Crystal Space based version of that promises a lot more for the future. Especially since it will use CEL and thus have access to the CEL game entity system. The first version will be compatible with the current GameBlender but the plan is to move to a new CEL based version pretty soon. In the end I hope we can even get a new CrystalBlend game UI in Blender itself. That would really be nice.
As to my other projects. All is still in progress. I'm waiting for the new levels from Xotic and when I get those I will start working on the first tech demo for Crystal Core?.
Now that the celtest demo is released I can start thinking about what to do next. Here is a list of things that I have in my head and that I would like to do:
So. I think I still have a little bit of work to do.
Yesterday and a bit of today I worked hard on a complicated corridor in my new celtest level. It was complicated because it had to follow the curve of another object and in the mean time I had to open windows between the corridor and the other object. When I later tried out the level I discovered that the new corridor ran straight through another part of the level that I put in another sector for optimization purposes. Since the new corridor was so complicated to make I had no choice but to change the older corridors that intersected the new areas. Luckily they were not complicated so this part was not very hard. But in addition to those corridors there was also an elevator that intersected the new corridors. I couldn't easily move that elevator so I decided to cut the new corridor in two sections with the elevator in the middle. All in all it turned out nicely.
I just upgraded to blender 2.37. I'm really starting to like this tool a lot. In 2.37 there are again a few new additional tools that make it a lot easier to manipulate and transform your meshes. My favorite functions in Blender are extrude, subdivide, and split. Extrude is extremely useful to enlarge areas and give walls thickness. The only thing is that you need to be careful that all normals are facing the right direction. Subdivide is very useful if you have made some room or corridor and you want to add a new door in a wall. First you split the wall from the rest of the mesh and then you subdivide it (with or without the 'Beauty' option). After that you can go to edge select mode and drag the edges so that you get the right size for the door. Then you remove the face and you have a door. The reason to split the wall before doing a subdivide is to make sure that the subdivision will not cause adjacent faces to be triangulized. You first want to subdivide the wall on its own. Later on you can then remove double vertices in the mesh to ensure that all is connected properly again.
Well the new level is progressing very nicely now. I'm using the textures from Xotic which he made for the Crystal Core levels and with those textures it is very easy for me to make a very big Star Wars lookalike level. It looks a lot cooler then current celtest level When I started making the level I didn't think of using the textures from Xotic so the first part of the level doesn't look as nice. I'm probably going to create that again.
Currently I'm fully concentrating on the level but during building of that level I found out that there are still lots of things to do on the code side. Here is a small summary:
Today I fixed an important bug in the static lightmap calculator. Apparently shadows didn't cast through portals. For some obscure reason the code that marked shadows relevant was removed. It was not easy to revive that code so I just consider all shadows relevant now.
That's it for now.
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.
|<< <||> >>|