next »

[Arne]

Here's something else I won't finish, but hopefully it'll leave me with some useful code or programmer experience points. I don't know what it is yet, but I'm thinking a side-scroller exploration game.

I'm using BlitzMax and I'm writing things from scratch. I can't understand other people's code. The code I have now does basic map (array) drawing, and there's a camera which can be focused on stuff, like my test entity. If the camera tries to look outsize the map it will be nudged. The entity is existing on the playfield and has nothing to do with the camera, other than when the engine needs to figure out where to draw the entity in relation to the camera's top left corner.

Floating point is not accurate in BlitzMax and it can create problems with characters bobbing in and out of blocks. My coordinate system uses a 'Long' for the game units, which means fixed point and I'm using bit shift l/r instead of multiplication or division. At the moment a pixel is 1 shl 16 (65536 units). I hope that is enough for slow analog movement.

A Long is a signed 64 bit integer, but I'm only using the positive values (63 bit) atm, so that gives me... 9223372036854775807 / 1 << 16 = a replicable MacOS calculator crash. Quite many pixels for the playfield. *300 that's a 469 billion screens high playfield, yes, thank you Wolfram. Of course, I'm using a tile map here so I'll be limited in size, but I wouldn't be if I made a space game or something where I could use the coordinates and stuff to generate the local environment (or I could just spread out stuff).

Anyways, I've been trying to keep the code clean, using descriptive variable names, constants, classes, and all that jazz.

300+ lines of code so far.


Left side: absolute map. Right side: relative scroll stuff

Next: Instanced entities, buckets for camera and collision purposes, some kind of movement code.

So, the buckets are not very difficult to write. Just another Shr to figure out which bucket something is in, then do the bucket change check yadda yadda. Then some update lists. Perhaps immobile objects are only checked against, and can be put in a less active update list.


Inquiry:

The platform collision code is always a bitch. This time I'm gonna try moving the stuff in steps then abort when a tile collision occurs. This will prevent tunneling and nasty move-back code. I assume that I need to... figure out how many steps the movement is. This is not trivial though, or is it? If I need to move say 2 units to the side and 4 up... should I use a Pythagoras and normalize here, or is there some easier way to find the x,y step distances? It seems bad to move 2 to the side then 4 up, or 1 to the side, one up, one to the side, one up, one up, one up. Maybe I'm confusing myself here.

With my taste for persistent and global world simulation, I want the movement code (used by all enemies) to be fast.

Also, I've never bothered with delta time. Should I?

[Arne]

Well, I got the trace ahead character to tile collision code working somewhat, but it's a rather clunky piece of code with Pythagoras and a bunch of stepping variables.

The question is if I should do bounce physics stuff inside the stepping loop, or if I should wait until after. E.g. if the player hits a wall on step 1/3, should I bounce him then, or just glide him against the wall and bounce once I've finished the stepping?

I get some kind of delayed bounce bug if I bounce inside the stepping loop.

[nihilocrat]

The platform collision code is always a bitch.

Use the line equation to "draw" a line, pixel by pixel, from point A to point B. At each pixel, test if it's filled. You know what to do from here.

Code might look something like this:

Code:

line : x1, y1, x2, y2

for x in range(x1,x2):
    y = (x * slope) + b
    check_tile(x,y)

Of course, you'd need to put in the if checks to see if you're drawing a vertical line.

Also, I've never bothered with delta time. Should I?

Yes. Well, I dunno if Blitzmax does some sort of FPS throttling on its own, but you need to delta-t to make everything consistent at all framerates.

[Arne]

I don't understand that code... where does slope and b come from?

Here's my clunky code. It works, but I think it's dirty.

Code:

'// Add Velocities (XVel, YVel) to Positions (XPos, YPos)
'// Also do tile collision checks.
Function FAddVel()
	
	'// No movement, so let's jump out. 
	'// I'm not sure if moving platform quirks, wall stuck tests should be done here later.
	If XVel = 0 And YVel = 0 Then Return
	
	'// These probably do not need to be Long, cuz of short distances.
	'// Although, maybe the math stuff is quicker if all variables are of the same type?
	Local xstep:Int, ystep:Int, dist:Int, stepdist:Int 
	
	'// Basic Pythagoras for the length of the movement.
	dist = Sqr(XVel^2 + YVel^2)
	'// Step using pixel size
	stepdist = 1 + dist Shr PIXEL_SHIFT
	
	'// No division by zero.
	If stepdist = 0 Then End 
	
	'// 'Normalize'.
	xstep = XVel / stepdist
	ystep = YVel / stepdist
	
	'// Todo: Optimize: If stepdist = 1 we've got a really short step. No need for a loop.
	'// The new coordinates as stepping runs, needs to be Long.
	Local xahead:Long, yahead:Long 
	'// Just a counter for the loop. Won't be larger than stepdist.
	Local trace:Int = 0 
	
	Repeat 
		'// Trace starts at 1.
		trace:+1
		
		'// Let's not calculate these several times later in the code.
		xahead = (XPos + xstep) 
		yahead = (YPos + ystep)
		
		'// Vertical test to determine if we'll hit bottom or top of a tile.
		'// Is the tile free at Old X, New Y?
		If TMap.FValue(XPos Shr TILE_SHIFT, yahead Shr TILE_SHIFT) = 0 
			'// Make the move.
			YPos = yahead
		Else '// Not free - collision!
			'// Should any course changes be done here, like bounce and friction?
			'// Doing so produces a strange delayed bounce.
			YVel = 0 '//-YVel 
			yahead = 0 '//-yahead 
			
		EndIf
		
		'// Horizontal test to determine if we'llhit the sides of a tile.
		'// New X, Old, no, actually New Y too, because of above.
		If TMap.FValue(xahead Shr TILE_SHIFT, YPos Shr TILE_SHIFT) = 0
			XPos = xahead 
		Else
			XVel = 0 '//-XVel
			xahead = 0 '//-xahead 			
		EndIf
	
	'// Are we done steppin'?
	Until trace = stepdist
	
End Function

I think it does this atm.



And no, BMX is more of a programming language than a game maker / rpg maker thing. I guess it's a bit like BASIC meets some OOP language. It does do double buffering easily though, but I always get frame tearing in windowed mode, regardless of whether I wait for the vblank or whatever. Might be an LCD refresh thing.

[nihilocrat]

Sorry, I didn't have a huge amount of time to make that post and I figured you'd recognize the line formula y = mx + b

slope = (y2 - y1) / (x2 - x1)
b = y1

The only really big problem I see with your algorithm is that it uses sqrt, which is slow when you might want to do it tons of times a second.

[Arne]

I'm not I've never seen it before. Yeah, sqr is mighty slow.


Rough graphics from a while ago

Golds made a game called Space Barnacle, and I liked the character and title. Unfortunately I never wrote up the ideas I had for my remake, but it might come back to me. It would be the usual persistent world sim + ecology stuff I always do. I actually had some code working for the platform jumping (walljumps, wall grabbing, walking, running) but it was crummy. Instancing players is kind of trivial so it could be a 4 player split screen thing. I'm not touching network code with a 10 foot pole. I have some pencil sketches I need to scan.

Yes, I don't want to code slopes, but to prevent a blocky feel, there could be sloped background tiles. I could save my map as a 256 color raw thing in Photoshop. Then I could load that into my map array. This way I could use PS for some or all of the map editing.

I'm just trying out ideas here, so the graphics are kind of rough and all over the place.



---

Experiments with fluids

The basic idea was to have particles which repelled and attracted. I think lava would be easier to simulate than water, because it's kind of slimy and sluggish. Unfortunately here it seems like the attraction force of groups overcomes the repelling force. It gave me these little multicellular organisms which moved about, eating cells and each other to change shape, move faster. Kind of weird getting that kind of emergence out of simple distance checks.


After tweaking the code I got something fluid'ish, but it's probably too jittery.


This is what would be the fastest. A simple tile based Boulder Dash -like routine. I just shake things a bit to make it flatten out. Perhaps buckets or RLE can be used to speed things up. Just having the game verb of lava in at all could add a lot of gameplay (along with destructible terrain). For example, in Mario you don't have destructible terrain on a pixel level, you can just smash big blocks. Imagine the game without it. I could make rounded corners for the lava blocks (and sparks), which would just be computed for drawing on screen.

[Arne]

I just remembered the idea for the space barnacles. I think it's important to kill many birds with one stone when it comes to making a plausible mechanic and game environment.

A few of the birds:
  The Space Barnacles needs to be destroyed, why?
  Some enemies respawn.
  I want an ecology and global persistence because it's fun and gives replay value.

So, the space barnacles are like plants, they grow on the walls and send out spores which grow into more barnacles. They have 4 stages: Spore, Bud, Reproductive, Cocoon, Metamorphosis. I'm thinking that instead of dying of age they cocoon, then metamorph into an enemy, with the type depending on which environment the barnacle grew up in*. It's a bit like in Alien, but quite different 

This solves the respawning problem, I don't need to create a superfluous factory mechanic with complex supply lines, mining, etc. It explains why the enemy types are localized. It explains why the space barnacles are a threat. It justifies the title of the game.

* Some space barnacles could even become stationary turrets. Even enemies could die of old age. This may be necessary to prevent tons of enemies getting stuck in some stupid place.

There can be a Queen space barnacle too. I think I marked it on my map.


Edit:

[ChevyRay]

Everything in that last post sounds amazing <3

Sorry for lack of replying, but I am following the thread quite closely. This is actually pretty cool to see you coming along with this! I love the idea that it would have a persistent ecology, as several replays could result possibly in entirely new results of play.

Also those pixel sheets... have I seen those before? They're giving me deja-vu.

[Loren Schmidt]

Hi Arne, the fluid tests look fun. I've always wanted to make a side scroller with some type of dynamic fluid in it. I like the test with the odd emergent clumping behavior particularly (if not for its potential as a fluid).

I've also always been very interested in games with ecosystem-like relationships in them. I look forward to seeing more of your thoughts are on how to integrate this into gameplay.

[Nate Kling]

This sounds great arne and the mockups already sound awesome. Is the world that you drew up going to all be one large world or broken up into seperate levels?  And if So, while you are offscreen would the space barnacles be growing and reproducing?  This could be interesting as the longer you take fighting off the barnacles in one area, the more they will have time to reproduce and grow into a large hive in another area.

[Krumbs]

I just hope you follow through this time and actually make this. But I know you won't.

Prove me wrong Arne, prove be wrong.

[Arne]

Chevy> I have an older version of that sheet, and I may have shown it before. I updated it yesterday.

Sparky> I found my A4 with unintelligible notes and scribbles on. I think I can reconstruct my old ideas though. If I do, I'll post later. I have a lot of ideas for the 'life' of the environment, not just ecosystem, but also, commerce and history. History is interesting because you can suggest so much with so little. Like, placing an old skeleton and a mining robot/scaffold in a cave, then bam, it's an old mining colony. Poor guy died there... who was he, who killed him? Lot's of gain from very little.

Caliber> Yes, I'll simulate the entire world. IMO, It's actually easier than zoning and controlling player flow. Too bad no one really does it. Some designers are obsessed by forcing the player to have fun their way. I guess I am too, with my way being... letting the player do whatever he wants, like drowning the boss in lava by digging a long canal or whatever.

Yeah, destroying the enemies would be meaningful, but I've planned in some things which will allow the player/s to guard multiple areas.

Krumbs> Thanks for the love, but I've already derailed I'll see if I can pick myself up and at least post the sketches and remaining ideas, because I need to at least wrap up a design doc for this game.

[Krumbs]

Man oh man do you derail easily, Cortex Command is the only thing I know of that you have stuck to.

[nihilocrat]

You can get sloped / curved / whatever blocks by implementing them as normal solid tiles, but have a special flag which is picked up by the collision routine (if block_type == BLOCK_SLOPED or whatever) which then handles this new special behavior correctly instead of treating the tile as entirely solid. Based on the materials online, it seems that this is what the engine for N/N+ does.