Sorry your browser is not supported!

Hi,

I started a new game recently (maybe I'll even finish it) but I decided to go about things in a different way. I've inserted a new Events layer inbetween the normal "cause and effect" logic. So far, I'm liking the possibilities. I've written an article on my ideas and implementation, and could help people to design a better framework for their game.

The system uses memblocks, bitmasking and bitshifting so it's perhaps not suited to the DBPro newbie. The article weighs in at 9 pages so bring a drink. Please appreciate that the article is not supposed to be a packaged solution - there's no "codez" here. It's an idea, a paradigm if you will. It's not a new idea in terms of programming but I've not seen anyone discussing this approach on the forums before.

Modelling Events in DBPro

I too have recently been working on a different way of managing resources and events.Inspired by Batvinks great tutorials I was using arrays not memblocks but i like your approach,mainly the bit shifting.Nice tutorial,thanks.
I`m going to have to read it a few more times before implementing it but it looks useful and powerful.
Thanks again.

I have to say, while the idea does seem to have potential, it also sounds extremely slow in comparisin to a classic modular engine with a detached scripting language for expandability and modularity. There's a whole lot of unnecesary logic there in otherwise simple subsystems such as input.

I would be interested in seeing games or examples made using that design paradigm though .

I'll admit, the memblock stuff is a touch unnecessary if you're going to end up stuffing all your data into a dword, like I did in the example.

As someone else has said they'd probably ditch the whole memblock thing (sigh - that's about 5 pages) and just use the notion of queuing actions. Even though you are putting in another layer (and as you rightly say, adding in more complexity), I think the benefits for simplicity of networking and AI could pay off.

We'll see - perhaps this system could make or break my game, notwithstanding my inability to finish anything off.


--- edit

Oh yeah, thanks for actually taking the time to read the thing

No problem, it's not often I get to read ideas around here by people who I know are competent

I was thinking of taking a break from my RPG to write a simple space invaders like game, I might pursue this method for that game, see how it fits.

I actually think the memblock stuff can work out fine for you in the long run; especially if you are trying to store lots of events and triggers (I read your work, but I skimmed through the memblock stuff, since I did something similar). The speed issue is somewhat valid for small lists, but when you start getting into the hundreds of events, the memory savings will keep the executable running faster. I said "somewhat valid" because I would suspect that in most cases using a small events list won't inflict a heavy drain on resources, so it won't make much of a difference.

I do have to look though your triggers section a little bit more to get the complete idea. I've recently started playing around with neural net ai and I can definately see the value of a time-delay trigger. I like the idea of "getting bored" trying to get the ball, so stop trying after a while. Of course, the applications for a neural net would be along the lines of a neuron firing for a short period of time, and then not firing after a while, or reducing the power of the "charge" over time. I also want neurons that are triggered only once in a while. So, when a trigger is set off into the event stack, and the neuron checks to see if the event is "in play", then the neuron can produce a charge. Otherwise, the neuron remains dormant.

I know it works, and I know it's fast. My issue was the overhead of actually coding it - It's about 10 lines of code to store 3 or so parameters, and it was just too tempting to use bitshifting



There's nothing new about giving a time limit to behaviour. I'm sure we've all done the if (timer()-startTime > A_CERTAIN_AMOUNT) style thing - but it's the modularity, the reusability that I was after.

That's along the lines of what I am looking for as well. I originally played around with each neuron keeping it's own timer/delay value, but that would be very inefficient. So, I started on the track of a global timer(s) that would set neurons to fire as needed.

I am trying to keep the neurons as small as possible and I am down to a nibble for the "firing mechenism". It's the rest of the neuron that seems to be taking up space. 1 nibble for a charge value, 1 nibble for a threshold value, and a final nibble for a weight value. And finally, 4 bytes to track which of up to 32 neurons to link to.
Adding a time-delay would be a second huge cost (add a DWord for each neuron) to track things like when to sleep, when to go to work, and so on. But a global queue of "events" created by something like your trigger mechenism would probably do the trick. All the neuron would really have to record is which event value to wait for, or better yet, program the event to give specified neurons a "charge."

So, events might be along the lines of "spend energy" (which translates into "get hungrier"). Another event would be it's morning, noon, or night. Another event might be a nearby npc is cooking food ("mmm-mmm, smell that cooking"). All of these may, or may not, add a charge onto the 'stop whatever you are doing, and eat' neuron. Once that neuron has a sufficient charge - it 'fires', then npc stops and eats food.

Anyway, forgive the rambling. Just trying to work it all out. My way saying I like what you have there.