Monday, May 26, 2014

... happens. :)

I even can't decide how to determine all this, but it's a one big source of the experience for me - this is for sure. Beginning of rewrite scripting support is caused chain reaction of needed changes in the my sources. This is very good sample of  HOW IT"S SHOULD NOT BE DONE. Always do planning about "what if I need to scale it later?" I don't do it in the initial part of my code, and this is my price payed for it now. My only excuse - I not written anything with mutithreading before, and has zero experience and knowledge about it.

Well... I managed to wipe most of the old single thread rubbish from the code, and it's begins to look like I will manage to get it all back and running without breaking compatibility with content resources that already in the game. At least on this side I managed to do a good enough planning. :) About optimization - I really not sure if it will be much faster, but at least it will not create strange hard to repeating errors caused by the concurrent access to variables anymore. (Yes, they usually not break anything serious before, but they still been here.)

Current state - still working at it, but already get things under control. Feeling easier now.:)

Wednesday, May 21, 2014

Angry at myself.

Today I spent most time to trying TO GET THIS ... subsystem of my program work as supposed to. It's again all about multithreading in the processing backgrounds code. Well, it's all started as I come with a idea how to really fasten script execution. At least get them to work two or three times faster. But after I finished coding, though it's begins to work faster, but program begins to generate tons of the errors... I begin to think that with my inexperience with the mutithreading, I was setup really big trap in my code, and succesfuly catch myself in it.

Now it's looks like it's much more easier to delete all background subsytem code from the sources, and rewrite it from the scrath. :( Only one good thing that I can see from all this - I got some practical experience.

And sorry, though new content almost done, I can't release new verson in such state. It's will be unplayable. :( I need to fix this issue in game engine and make it work normal. Not sure how much time it will take. But it need to be done.

Tuesday, May 13, 2014

Felling a little like cheater :)

Trying to do working life simulation through scripts only is possible. I'm technicaly done it. But after I seen all this scripts listing, I feel that it's something too much for anyone then maybe me alone. :)  (Long time ago joke: program complexity grow so long as it's not surpass programmer's ability to remember his own code. :) )

So I decided to add new class/object to the game engine - InternalClock. It's now can be used to setup daily schedule for cahracters and monitor where they are with only few script lines. It's more effective, but I still felling a little like cheater - adding new game engine functional for secific task. :)

Sunday, May 11, 2014

What I'm doing now?

I's been a little quiet past week, so maybe someone is curious - what I'm doing this time?

Well, after finishing with last bug report and releasing a last patch, I focused on the expanding new possibilities of game engine and adding new features in the game - together. :)

In the next release you will be introduced to the commoners control system - something like a TES and Fallout characters life simulation. I'm not so arrogant to tell that I can do something completely like this, but my idea is:
- Generating some characters.
- Allow them to move between locations on the schedule (with some randomness or condition based). They can be encountered on streets or in the cafe, shops, etc.
- Allow proxies to talk with them, seduce them, and have sex.
- Allow them to be hired as a new proxies.
- If character is not interacted with proxies too long they will be replaced with another (just seeing on the street not enough - approaching them is what count here).
- (Not sure for initial release) Interactions between these characters - like talking (proxy become
spectator of dialog) or even sexual encounters between them.

Kau village will be first place to add and test this system. And this will be first standard way to get a normal Kau proxy.

For those who interested in scripting: new release will have new variant of the AddButton command:

AddButton("Caption", "path/name_of_event", some_object);

If button added this way, next event that called by pressing this button will have access to the special object with name buttonObject. It can have any type (Creature, String, Item, Map, List) - anything. This way script can pass data directly to the next event basing of the player choice. This way you can script events not only condition based (normal for this engine) but choice based - like most other text game engines works. Be sure to check received value though - it's can be null or incompatible type if set incorrectly.