The new blog is available here: http://www.codeandroid.com/~psy/
Everything below is just outdated. :)
This little blog is here so that interested people have a chance to see what we're (or: I'm) currently working on. Besides, it's nice to be able to track one's progress and thoughts over time.
Crouching, jumping and generally strolling around and interacting with the physical environment does work fine. For the physics character controller. It's probably time to hook a graphical representation to it.
Quite a few things happened in the last few weeks. The 0.4.0 release is just one of these :)
The networking code is coming along nicely. I add unit and other tests as I go along. Definitely a useful technique for components.
Today I added the character controller (physics::IAvatar) for physicsODE. Needs more tweaking but is already looking good.
I have a few other little things going, too, at the moment. If all goes well we should have something visually attractive to look at “soon”.
The 0.4 release is imminent. I recently finished the vehicle system. Now I wait for mj's latest patch which fixes a few more issues in the physicsODE plugin as well as includes a refactored XODE parser.
It's time to publish a more complete demo which demonstrates how to pull the different components together in a typical game-like application. More information on this little side project will follow soon here.
Site is up again. No more comments.
I added the car demo this evening. A little bit more tweaking and it'll be fun.
I'm in the process of setting the yake.org server up again after it has been hacked. Pure fun.
Phew. I just comitted the new yake::vehicle component and a little demo (based on yake::raf) to SVN. It's still pretty rough around the edges. Definitely more refactoring needed. But we're getting there and as I'm out of town for two days I thought it best to release something to look at now. I know that some people are quite interested in this. Looking forward to feedback (and bug reports).
The major point for the future will be documentation. The approach is powerful but needs to be documented in order to be useful for anyone else except a selected few developers who live in Yake's code. Actually, that applies for quite a few of Yake's components.
The amount of developers that want to use Yake on the Linux platform surprised me. Now I want to make sure that Yake always works on that platform, too (maybe not HEAD, but all stable released). Thanks to mj that shouldn't be a major headache. And with a little bit of effort on the community's part we should be able to pull this off quite easily.
Hierarchical mount points, mounted thrusters, car engines, gear boxes, wheels… The new vehicle component is coming along nicely. I concentrated on features that I know certain people miss most. The component as well as a demo will be included in the 0.4 release as promised.
I've been thinking more about documentation lately. Not just code documentation but manuals, tutorials, wikis and the different kind of information/documentation storages. I'm quite sure that there are quite a few exceptional features that noone really knows about. Time to think about how to spread the knowledge.
It's been some time since the last entry. Yake 0.3 has been released. We moved to boost 1.33.0, mj send his “summer patch” and I did a lot of work at several places at once.
Here are two things I worked on (about the others I tell you at a later date… probably):
The storm editor still needs a little finishing before I can make a first release. It has been rewritten, now it's smaller, cleaner, leaner… meaner. You get the drift.
I promised mj to finally take the time to revamp Yake's vehicle system. And I did a lot of design & refactoring today. It'll be a huge improvement and a very interesting component of Yake. And it'll definitely be part of Yake 0.4 though I may not be able to keep the original deadline.
During the next few days I'll be moving to another flat. And while that's exciting and fun it's also work and takes time. And I have to get a new broadband account etc so if updates seem sparse this is the explanation. :)
Other than that, the new application framework is coming along fine. A first version has been in CVS for several days now and further updates will follow soon. The refactored entity system will be in place shortly and then it's already time for the 0.3 release.
I'm happy with the development of the Wiki, especially the ongoing contribution of tutorials.
Yake 0.2 is finally out (since Saturday as promised). The sky is bluer, the grass is greener, the sun is warmer and I am happier :)
Now it's time to improve stability and fix bugs and add a few neat little things.
Quite a few things have happened, both in my personal life and my Yake life, and last but not least even in my day-time work life.
But the important thing: While it's not a perfect release, I look forward to release 0.2 this Saturday. We've got so many plans, but really have to get a stable vs HEAD CVS mechanism so that other people have a chance of developing with a stable release ( more or less ).
More about our cooperation with OpenFrag soon :)
The 0.2 code base is feature complete. Time to make it more stable before we officially release it. I'm looking forward to tackling the 0.3 features :) But first things first.
Which means holidays. I'm away for two weeks.
When I get back I'll work through any pending problems and patches.
I totally forgot about this blog!
I'm quite happy with the way I implemented it. It has its shortcomings and it's still missing a few more or less important features (e.g. load balancing) but I'll get to that eventually, too.
A first, actually usable version is now in CVS.
The core functionality is defined in the Yapp project “ent”. The Lua scripting interactions for objects/entities, their state machines and dynamic events etc is implemented in entLua. It's possible to use “ent” without the scripting plugin by simply not loading the latter :) I'm thinking about a more sophisticated demo than the one we have now. The current one features 3 different kinds of flickering lights (using events only, using events and states, and another approach) and a “pawn” object, a generic graphical object.
yake::ent has been design with networking in mind even though there's no direct hint to it. The goal (for 0.3?) is to be able to have replicated entities for which the code is split for server and clients. This basic distinction can already be seen in the way states and events are specified in scripts. But that's still quite a bit of way to go.
Over the last 5 months or so I'm getting more and more (serious!) e-mails of people who're interested in using Yake in their (serious!) projects or have some other kind of collaboration in mind. Let's see whether this turns into some actual work getting done.
The code base for 0.2 is now feature complete. We're tackling stability issues etc and then it's time to finally release it.
regress and others have hinted that they'd be interested to help create tutorials and demos as soon as 0.2 is released. Well, if that's not an incentive :)
I implemented a proof-of-concept demo. Now abstraction of the concept is necessary before committing the result to CVS.
And another proof-of-concept demo is being worked on. Right now it's more or less independent of yake::reflection but later on the necessary links will be established.
In a first step we'll implement server-based physics with interpolation/extrapolation etc on the client. The next step will be a client-side simulation for prediction and simulation of “small” and/or “unimportant” objects to reduce server load (e.g. debris).
Currently we're half-way through step 1. More details soon.
Now in CVS. Read more here.