a new programming style

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Dec 24, 2013 at 17:45

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.

6 Replies

Please log in or register to post a reply.

B9c51b24b655b8afcf9f399049e57f52
0
geekymonkey 103 Dec 25, 2013 at 07:52

I’m not following. Can you give a pseudocode example?

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Dec 25, 2013 at 08:44

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)

main
{
	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)
		{
			destroy block
			mirror angle
		}

		if(detect bat proximity, using xy coordinates)
		{
			score++
			mirror angle
		}
	}

	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.

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Dec 25, 2013 at 09:03

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.

B5262118b588a5a420230bfbef4a2cdf
1
Stainless 151 Dec 26, 2013 at 11:04

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

Fd80f81596aa1cf809ceb1c2077e190b
0
rouncer 104 Dec 27, 2013 at 15:06

hmmm, well, a mob might be better, but what are they exactly?

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Dec 28, 2013 at 08:43

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.