just imagine if you wrote code so a single pass of the whole code is an update.
anyway, you introduce variables and code, all in a nest of conditions, whatevers open is what runs.
you close conditions, and you dont run code, you open conditions to run code.
this way you can anything you want in a single function, and you get ultimate reuse if you
always nest the right way.
its alot like a program that conditionally hacks itself… of course the amount of conditions that
never come true, slow you down, but other than that, it could be a sorta nonefficient programming
style, that lets you reuse code better.
i wonder what could improve the false firing conditions, but keep the pluginable nature.
it would be good for non linear adventure games, where there is heaps of dependencies
when things happen in the game, items the character has, things hes done, so you could
have complete state switches happening all the time.
Please log in or register to post a reply.
I’m not following. Can you give a pseudocode example?
remember, its just continually cycling the main.
whats not here is the actual spawning of the instances, im thinking of how i do that, it may be a handplaced scene, just say for now.
so, pong would be this-> (note when you add a variable, it wont run twice, only once… if it closes a condition and opens it again, then itll run it again, only when it opens a condition does it run.
and you can see, ive reused the coordinate variable for every instance. (the cool thing)
run once-> add x coordinate variable
run once-> add y coordinate variable
run once-> add instance proximity detector
run once-> add score variable
if(im a bat)
if(key left) x--
if(key right) x++
if(im a ball)
run once-> add angle coordinate
move ball with angle condition
run proximity detector.
if(detect block proximity, using xy coordinates)
if(detect bat proximity, using xy coordinates)
if(im a block)
draw block at coordinate
so not very exciting, cause its just pong, but the strange thing you can do, is now turn a ball into a block, or a block into a bat or anything, if you wanted, during the game.
but just it has to check what it is every cycle, and thats the thing i want to fix, if you could fix that, then i would really think this way has its definite use. especially for the nonlinear adventure game…
but thats when the speed issue will manifest itself.
of course an adventure game, just imagine you create an instance from a set of conditions, not just one. and they parent each other, but there is intersecting possible, from anding two types.
so just imagine you have.
elf in forest playing guitar with fairy then fairy dances… that would be possible to insert as a special dependency.
Just think about a real game, say 100 different types of MOB’s.
Just think of what a incredible mess it would be. At least 100 if statements, and if you wanted to change something for one MOB you could accidentally change all of them.
Code maintenance would be a nightmare, debugging would be a nightmare. I see no advantages at all for this approach and hundreds of disadvantages
You can do any kind of morphing you want with much cleaner code.
MOB (Moveable Object Block) old coders should remember them
hmmm, well, a mob might be better, but what are they exactly?
A MOB is just a Moveable Object Block, what most people now would call sprites I guess.
It was used in MOS Technology’s graphics chip literature (data sheets, etc.) However, Commodore, the main user of MOS chips and the owner of MOS for most of the chip maker’s lifetime, applied the common term “sprite”, except for the Amiga line of home computers, where MOB was the preferred term.