Gamedev Like it's 1977: CHIP-8

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Hey, quick question.

I'm new to this. How do I incrementally load through stuff from a memory block

Let's say I have

code:

: butt 1 2 3 4 5 6

And I first want to load the first 3 numbers into v0-2 and then do something, then load the other 3 numbers into v0-2

I thought this would be something like:

code:

i := butt
load v2

# do stuff

v1 := 3
i += v1
load v2

But this doesn't seem to work. What am I doing wrong, and which docs should I look more at.

# ¿ Dec 27, 2014 18:47

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 07:21

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Thanks, yeah I somehow missed that i got auto incremented on save/load.

Works now.

Working on a project for fun that should hopefully not take too long

CHIP-8 seems fun.

# ¿ Dec 28, 2014 14:22

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

So yeah, the octo debugger is pretty sweet.
Got bitten by this (but found it out while debugging):

Opcode Description
8XY4 Add the value of register VY to register VX
Set VF to 01 if a carry occurs
Set VF to 00 if a carry does not occur

8XY5 Subtract the value of register VY from register VX
Set VF to 00 if a borrow occurs
Set VF to 01 if a borrow does not occur

I assumed that VF would be 01 if a borrow occured, cause yeah, that would make more sense right?

Buffis fucked around with this message at 16:13 on Dec 30, 2014

# ¿ Dec 30, 2014 15:52

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Internet Janitor posted:

Oh yeah. I made the same mistake the first time I implemented those opcodes. It's one of several reasons I created the < > <= >= pseudo-ops.

To be fair, I also got bitten by compare-temp overriding ve for me when I didn't expect it to

That said, now that I realized that compare-temp is a thing, the pseudo-ops are pretty great.

# ¿ Dec 30, 2014 17:19

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Been playing around with Octo a bit more.

Have a pretty stable bullet engine going now, that I might turn into something cool.

Here's a quick demo of a pretty simple pattern:
http://johnearnest.github.io/Octo/index.html?gist=74f43dac16b313b60a25

Pattern above is only something like 12 bullets onscreen at the time max. Currently the engine can do 25 bullets on screen without any real issues. I'm in the process of cutting down the bullet structures to 8 bytes (from 10) though, which will allow me to address 32 bullets wit 8-bit addressing. If that's not enough, it shouldn't be super hard to extend it to 16 bit addresses for the bullets.

The implementation for acceleration is kindof lovely right now, but it's functional.

The pattern generation is pretty easy right now.

Essentially, bullets are spawn by doing

code:

		
dostuff x := 53 y := 16 vx := 244 vy := 168 ay := 0 ax := 1 pew_pew

# x,y are coordinates. vx,vy are velocity. ax,ay are acceleration (ay not implemented yet cause I've been lazy)

The example above is:

code:

: pattern4
	vc := random 0b00001111
	vc += 8
	
	v0 := 0b00011111
	v0 &= vd
	if v0 == 0b00011111 begin
		dostuff x := 60 y := vc vx := 240 vy := 0 ay := 0 ax := 0 pew_pew	
	end

	if vd == 30 begin
		dostuff x := 53 y := 0 vx := 244 vy := 5 ay := 0 ax := 1 pew_pew	
	end
	if vd == 35 begin
		dostuff x := 53 y := 2 vx := 244 vy := 12 ay := 0 ax := 1 pew_pew	
	end
	if vd == 40 begin
		dostuff x := 53 y := 4 vx := 244 vy := 19 ay := 0 ax := 1 pew_pew	
	end
	if vd == 45 begin
		dostuff x := 53 y := 6 vx := 244 vy := 26 ay := 0 ax := 1 pew_pew	
	end
	if vd == 50 begin
		dostuff x := 53 y := 8 vx := 244 vy := 33 ay := 0 ax := 1 pew_pew	
	end
	if vd == 55 begin
		dostuff x := 53 y := 10 vx := 244 vy := 40 ay := 0 ax := 1 pew_pew	
	end

	if vd == 160 begin
		dostuff x := 53 y := 26 vx := 244 vy := 133 ay := 0 ax := 1 pew_pew	
	end
	if vd == 165 begin
		dostuff x := 53 y := 24 vx := 244 vy := 140 ay := 0 ax := 1 pew_pew	
	end
	if vd == 170 begin
		dostuff x := 53 y := 22 vx := 244 vy := 147 ay := 0 ax := 1 pew_pew	
	end
	if vd == 175 begin
		dostuff x := 53 y := 20 vx := 244 vy := 154 ay := 0 ax := 1 pew_pew	
	end
	if vd == 180 begin
		dostuff x := 53 y := 18 vx := 244 vy := 161 ay := 0 ax := 1 pew_pew	
	end
	if vd == 185 begin
		dostuff x := 53 y := 16 vx := 244 vy := 168 ay := 0 ax := 1 pew_pew	
	end

;

Here is an example of the engine doing two patterns at once, making more than 25 bullets spawn at once, which makes things a bit unpredictable, but still "stable". Handling for this could be a lot better:

http://johnearnest.github.io/Octo/index.html?gist=005dc11e44cd16fee1b0

Buffis fucked around with this message at 14:35 on Jan 1, 2015

# ¿ Jan 1, 2015 14:30

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Yeah, I haven't bothered too much with optimization yet, since I just wrote the engine for 25 bullets to start with, and everything works mostly ok with that as long as I draw everything before the computation (at 1000 cycles per frame that is).

There's a lot of optimization to do for sure, but I'll try to mash this into something playable first.

The jump table idea sounds pretty nice. Might try that out!

# ¿ Jan 1, 2015 21:33

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Posting a work in progress, since Internet Janitor asked me to.

danm8ku.8o:
http://johnearnest.github.io/Octo/index.html?gist=425acca04b1f79e47eb4
Controls are : WASD

The engine for this is actually a lot more capable than for this simple pattern though. It supports 32 on screen bullets with individual x/y speed and acceleration.
The ROM is <500 bytes currently, but it allocates 256 bits of additional memory for the actual bullet engine on startup.

Basically, I wanted to see how small I could get the ROM cause I was bored. Might implement something a bit more advanced like a boss with multiple stages + a title screen at some point, making this a bit more than just the very simple bullet dodger that it is right now.

Still, I'm kindof pleased with this. Code is pretty easy to read, and the "API" for spawning bullets are easy as gently caress. Current pattern is just:

code:

: pattern2
    v0 := 0b00001111
    v0 &= vd
    if v0 == 0b00001111 then pattern2_shot1
;

: pattern2_shot1
    vc := random 31
    
    gogo_bullet x := 60 y := vc vx := 150 vy := 0 ax := 130 save v7 
    gogo_bullet x := 60 y := vc vx := 150 vy := 0 ax := 134 save v7 
    gogo_bullet x := 45 y := vc vx := 75 vy := 135 ax := 130 save v7    
    gogo_bullet x := 45 y := vc vx := 75 vy := 10 ax := 130 save v7 
;

Basically, pattern2 checks if the game timer (vd) matches a bitmask, and if it does, spawns the shots with the noted bullet positions, velocities and accelerations. The game engine main loop takes care of the rest.
Adding new more advanced patterns is very easy.

Buffis fucked around with this message at 08:16 on Jan 16, 2015

# ¿ Jan 16, 2015 07:54

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

I realized that I haven't actually posted Trucksimul8or in this thread so...

Here was my entry for SAGDC, written in Octo.
http://www.awfuljams.com/games/truck-simul8or
http://johnearnest.github.io/Octo/index.html?gist=a8a227e707cd138ba258

It's a truck simulator game without a truck, featuring customization and insane trucking action.

The gong show video showing it off was pretty cool:
https://www.youtube.com/watch?v=rXC5iCdDm8Q&t=3s

# ¿ Sep 20, 2015 09:34

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

UNDERTALE SPOILERS BELOW

http://johnearnest.github.io/Octo/index.html?gist=21d9b38ddb913e2e2ac8

(code is pretty hacky, quick and dirty prototype)

# ¿ Oct 1, 2015 21:44

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Buffis fucked around with this message at 08:23 on Oct 5, 2015

# ¿ Oct 4, 2015 09:59

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Making progress on my octojam game

Staying without superchip or XO chip for this jam, since I wont have time to make them justice. Limitations are good for me.

Buffis fucked around with this message at 21:30 on Oct 7, 2015

# ¿ Oct 7, 2015 21:24

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Making progress on danm8ku

Playable work-in-progress here:
http://octojam.com/octojam-ii/games/danm8ku

# ¿ Oct 19, 2015 21:11

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

I made a quick thing yesterday, it looks pretty sweet.
http://johnearnest.github.io/Octo/index.html?gist=2b767e2162f73f6e7652
( https://github.com/buffis/misc-samples/blob/master/Octo/patterns.8o )

# ¿ Oct 26, 2015 09:34

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Danm8ku postmortem / devlog

I started off writing danm8ku as a bullet hell engine for chip-8 danm8ku games, and i built it upon this pretty simplistic game which shows off some of the features.
I tried to keep the difficulty reasonable, but looking at the octojam twitch stream, I guess people without much bullet hell game experience just can't play these games very well anyways, so I might as well have made some patterns a bit harder.

Writing this up with quite a lot of detail, but someone might find some stuff in here interesting.

First off, here's what the game looks like when played through:

== Title screen ==

The title screen is actually pretty neat.
Here is everything but the title screen removed, running at a slower pace to show off how it works:
http://johnearnest.github.io/Octo/index.html?gist=de467a09480be597df33

It first draws the text, and then increments a 8 bit binary counter for a random line.
Basically, algorithm is (for one side of the screen):

Get a random line
Set the X position to 0
Draw a sprite at position X
If I drew over an existing sprite, increment X by 4 and go to step 3
Repeat

Removing the text drawing part makes it even easier to follow (less than 50 bytes):
http://johnearnest.github.io/Octo/index.html?gist=586e37d76decd37fc78f

== Bullet engine ==

Most of the effort is put into the bullet engine, which is actually rather complex, since it requires allocating and moving up to 32 bullets on screen at the same time, which gets awkward even when running the game at 1000 cycles (Octo games generally have very few moving sprites).

Each bullet takes up 8 bytes of space, containing:

x position (two bytes)
y position (two bytes)
x velocity (one byte)
y velocity (one byte)
x acceleration (one byte)
sprite offset (one byte)

In practice, very few bits of x acceleration are actually needed, and it should be possible to merge it with sprite offset, although it would require a bit more computations, and the engine is already running very close to the cpu limit, so this seemed fine.

The bullets are stored in a 256byte dedicated area (memory address 3000), and should essentially be considered an array. Un-allocated bullets will have the x velocity set to 255, which is a magic value saying that its address is free for allocation. This should probably live in sprite offset instead, but whatever.

Whenever a tick in the engine occurs, move_bullet will be done on each active bullet. This updates bullets positions, and sets a sprite offset based on the current direction. This method is heavily optimized in some non-obvious ways. One interesting difference is that x and y velocities are signed values, but they are not using ones compliment.

Position is then updated based on velocity using the following logic

code:

	
    vc := vx       # store velocity in a temp variable for later
    vx <<= vx      # multiply by two, check for neg bit             
    va := vf       # va will be 1 here if the velocity is negative
    x_f += vx      # add the velocity to the one byte fractional counter of x,
                   # if this overflows, we should move the bullet one step
    vx := vc       # restore velocity

    # Hack to avoid jumps/comparisons to do:
    # if vf != 0 begin
    #   if va == 0 then x += 1
    #   if va == 1 then x -= 1
    # end
    va &= vf
    v8 := vf
    v8 -= va
    v8 -= va
    x += v8

I tried doing something like this with "regular" signed arithmetic, but couldn't get it this fast.
One nice thing here, is that v8 will be set to 1 if x velocity is positive, -1 if negative, and 0 if not moving.
This means that we can do this for both X and Y, and then use these values to setup the sprite_offset byte to a unique value for all 9 possible movements:

code:

   # Set sprite_offset to values used to get movement sprites.
   # v8 is X direction
   # vd is Y direcation
   so := v8 
   if v8 > 1 then
     so := 2
   if vd > 1 then
     vd := 2
   vd <<= vd
   vd <<= vd
   so |= vd

Then when drawing the bullet, I do:

code:

	i := bul_nop
	so <<= so   # multiply by four, since each sprite is four bytes
	so <<= so 
	i += so
	sprite x y 4

This then fetches the next sprite data to XOR to the bullet, to make it look like its moving in that direction, without having to call clear.
Data is:

code:

    # Sprite movement data
    # ORDER OF THESE ARE IMPORTANT. DON'T REORDER.
    : bul_nop 0x00 0x00 0x00 0x00   # 0
    : bul_r 0x00 0xA0 0xA0 0x00     # 1
    : bul_l 0x00 0x50 0x50 0x00     # 2
    : bul   0x00 0x60 0x60 0x00     # 3 (not used for movement?)
    : bul_d 0x60 0x00 0x60 0x00     # 4
    : bul_dr 0xC0 0xA0 0x60 0x00    # 5
    : bul_dl 0x30 0x50 0x60 0x00    # 6
    : bullet_count 0                # 7 (unused so storing other stuff here)
    : player_position 5 15
    : UNUSED1 0
    : bul_u 0x00 0x60 0x00 0x60     # 8
    : bul_ur 0x00 0x60 0xA0 0xC0    # 9
    : bul_ul 0x00 0x60 0x50 0x30    # 10

Note that the sprite_offset can't map to values 3 or 7, so it's possible to store some other data there, as long as it's four bytes to keep the offsets correct. Here, I actually store the initial bullet sprite "bul" + some unrelated variables, just to save ROM storage.

Clear data works the same (see clr_nop and onwards). Most other stuff with the handling is pretty straight forward.

Spawrning a bullet is done by doing something like:

code:

    gogo_bullet x := 35 y := vc vx := 66 vy := 12 ax := 2 pew_pew

Subsequent bullets that should use similar attributes, with just a few changes, can just modify whats needed, like:

code:

    gogo_bullet x := 50 y := vc vx := 230 vy := 0 pew_pew
    gogo_bullet x := 54 pew_pew  # everything but X start position is the same as the first
    gogo_bullet x := 58 pew_pew  # everything but X start position is the same as the first

Technically, the lines above will only work assuming that the currently active pattern wont reach the max limit of bullets.
If the pattern should spawn lots of bullets (like pattern 2), the pattern will need to check that v8 is non-zero, after calling gogo_bullet, example:

code:

    gogo_bullet   # will set v8 to 1 if a bullet can be spawned
    if v8 == 1 begin
        vx := random 127
        vx += 127
        x := 57 y := vc  vy := 35 ax := 0 pew_pew
    end

== Pattern engine ==

Since the bullet engine has this nice interface described above for spawning bullets, the pattern engine can be pretty simple.
Each pattern is just a memoryblock, ending with a jump to "pattern_done", these patterns are then store after eachother and accessed through a jump0 call.

code:

: pattern1  # example pattern
    v0 := 0b00000111
    v0 &= vd
    if v0 == 0b00000111 begin
        vc := random 31
        gogo_bullet
        ax := 2
        vx := random 63
        vx += 170
        x := 55 y := vc pew_pew
    end
    jump pattern_done

: pattern
    jump pattern1
    jump pattern2
    jump pattern3
    jump pattern4
    jump pattern5
    jump pattern6
    jump pattern7
    jump pattern8
    jump youwin

The main game loop keep track of the number of ticks, and when a counter is reached, will increment the pattern_state by 2, and each tick, the following logic will make sure that the pattern is executed:

code:

    i := pattern_state
    load v0
    jump0 patterns

Each pattern then has a register "vd" set to the number of ticks that has triggered inside the pattern, making it possible to make certain bullets spawn at certain times, allowing for complex things!

== Ending screen ==

The ending screen is also pretty neat, although less minimalistic (and not really optimized) compared to the startup screen:
http://johnearnest.github.io/Octo/index.html?gist=d315690f033bde3188e4

Drawing it slowly should make it pretty visible that the algorithm for this is extremely simple:
http://johnearnest.github.io/Octo/index.html?gist=20c8e5265cedf41265cc

The data being drawn is the first 4 lines of the Zero in the built in Octo font.

== Retrospective ==

Looking at the jonterp twitch stream of this game, where they were unable to get past the second level, I guess this game isn't really for everyone, but I only really wrote it for myself, and I'm pretty pleased with it.

Some patterns are not very thought through, since I found the main engine the most exciting part, so I might come back to the engine later, and produce something new. We'll see.

# ¿ Nov 7, 2015 15:01

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Instead of polishing my game for awful jams, I golfed down a flappy bird game to 87 bytes.
http://johnearnest.github.io/Octo/index.html?gist=fcd9c1ca2e0365f423b6ad56225377f5 (fl8ppy mouse)
Jump with W

First game using the clipping quirks mode perhaps?

Possible to get it down to 64 bytes and running it with flickering on 7cycles without delay loop and using builtins as sprites:
http://johnearnest.github.io/Octo/index.html?gist=66659f6bf7a8a422043a90f4c3c41cb9

Buffis fucked around with this message at 21:56 on Jul 27, 2016

# ¿ Jul 27, 2016 20:26

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

48 bytes

http://johnearnest.github.io/Octo/index.html?gist=ec9f2c2303a1144aafcca587725e06d7

44 bytes, no quirks mode

http://johnearnest.github.io/Octo/index.html?gist=9952e56f1b163bc0ac1b6e739531c76f

40 seems easily doable, but I'll leave that for someone else or another time.

Shaving off 2 bytes from v0 usage was simple, but had to take some sprite liberties to get to 40. The game is now a flappy plane navigating a cavern of letters.
It's like frog fractions but for writing.

http://johnearnest.github.io/Octo/index.html?gist=a82d46b6cbad52bbf1eea89d1cae5e66

Getting it down to 37 bytes is doable if changing the jump button to E and having one of the openings be a bit iffy.
http://johnearnest.github.io/Octo/index.html?gist=1bdbe2e0a7d4df8f44ead0b4ea2198bd

Buffis fucked around with this message at 20:53 on Jul 28, 2016

# ¿ Jul 28, 2016 17:45

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

Oh, I missed the v0 incrementing thing. That should have been obvious.

Here's 35 bytes. It's shaving the 4 bytes I was thinking of, plus another one I just found now. press e to fly.

http://johnearnest.github.io/Octo/index.html?gist=20292b2d6200aa515ddf43631605c816

gently caress. I had this page open and was golfing without refreshing it and got it down to 37 (I also figured out the thing with using the 06 from the jump for the button and so on), but you still beat me by 2 bytes

I updated my message above to include my thing.

edit: Haha, using 0x12 for a jump to main due to zero padding is genius.

Buffis fucked around with this message at 21:00 on Jul 28, 2016

# ¿ Jul 28, 2016 20:55

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

Oh, I missed the v0 incrementing thing. That should have been obvious.

Here's 35 bytes. It's shaving the 4 bytes I was thinking of, plus another one I just found now. press e to fly.

http://johnearnest.github.io/Octo/index.html?gist=20292b2d6200aa515ddf43631605c816

33 bytes (drawing one pipe per cycle)
http://johnearnest.github.io/Octo/index.html?gist=b372df719fecfc82e7f96315078b69a2

Removing v4 += 16 shaves off two more bytes, but then the pipe openings are always the same.

Not seeing any way to golf this further without messing up the gameplay.

# ¿ Jul 29, 2016 08:11

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Lime posted:

31 bytes based off Buffis's one pipe per iteration
http://johnearnest.github.io/Octo/index.html?gist=449ca18529419160d9bae705bc7d5538

I changed how the physics work: instead of increasing velocity every iteration and then dividing by 4 before adding to position, I overflow a different register roughly once every 4 iterations and then simply add the overflow flag vF to velocity and velocity directly to position. This eliminates one shift-right, saving 2 bytes. The old bounce velocity of -6 doesn't divide by 4 so I had to round up for this new scheme. This makes the bounce roughly the same as using -8 instead of -6 in previous versions. This maybe doesn't feel as good to play and it's harder to break out of the initial death loop, so it's arguable that this qualifies.

I mean, this physics is sortof unplayable, and if that's ok you can just remove one shift from the acceleration of the code I pasted and get this 31 byte one as well.
http://johnearnest.github.io/Octo/index.html?gist=9560fb7e7c4d7c4ca82173121e5cb5ba

Getting below 33 bytes while being able to play this thing seems somewhat hard. The 29 byte one is fun though.

# ¿ Jul 30, 2016 11:29

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Played around a bit with pseudorandomness and superchip scrolling.

http://johnearnest.github.io/Octo/index.html?gist=11487e18e55d56b08af43b60f871a8d0

Steer with W and S

# ¿ Aug 6, 2016 22:14

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Is Octo-ber happening this year?
It's pretty quiet considering it's like a week til October.

# ¿ Sep 24, 2016 20:08

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

taqueso posted:

Awesome work Mastigophoran!

I wanted a PRNG so I could save state and 'replay' earlier sequences of numbers, so I implemented a 64-bit LFSR based PRNG:
https://github.com/jdeeny/octo-lfsr64

I'm sure this could be better, I would love comments or tips on improving the quality of the output. It does OK with ENT but it doesn't pass everything from CAcert's test

For a simpler LFSR PRNG, I implemented the naive implementation of
http://codebase64.org/doku.php?id=base:small_fast_8-bit_prng
in Octo a while back. It's like 4 lines of code.

https://johnearnest.github.io/Octo/index.html?gist=d63c4305a0e2d079f6a0186bfe15706d
(Look at getrand. reserves the registry vd for the random number generation target)

# ¿ Oct 4, 2016 06:38

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

Dr. Stab posted:

I'm having a bit of a problem with audio sync.

http://johnearnest.github.io/Octo/index.html?gist=e5626b6bfc50473d98ff8d13824e0419

For me, this stays in sync as long as it never lags or pauses. If I wait 1 minute, then pause, a whole bunch of sound will play while it is paused. It seems like as long as sound is continuous, the time at which I tell a sound to play and the time at which it actually gets played drift further and further apart as more sounds are queued to play.

Is that a jubeat clone playing PONPONPON?
Thats pretty drat nice

# ¿ Oct 8, 2016 14:25

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

I think I'm pretty done with my entry this year.
There's a few minor tweaks that I may end up doing, but overall, this should be done now.

I present:

Binding of COSMAC: Octoberth
https://johnearnest.github.io/Octo/index.html?gist=d3d2ecb2f0ac2075f636e7d3ec60e786

WASD to move. F to shoot.

Sortof a very simplified Isaac demake for SCHIP. Wont run on any hardware or anything (needs to run at 1000 cycles), but plays pretty alright.

42 screens across three floors with an exciting boss battle at the end!

Gonna make a more thorough tech writeup at some point as well, but there's honestly nothing insane going on or anything.

The section starting at ": room" is where the levels are stored. There's 42 levels that are 6 bytes each. Two of these bytes needs to be reset each time the game is restarted, so these get copied over the title screen on game startup, so that restoring is possible.

Pretty happy that I managed to squeeze quit a lot of stuff in there. A big 300b or so title screen, semidecent animations for ending and death. Hats, scorekeeping, multiple floors, a continue system (restart on current floor), and a bunch of other small things.

It's probably still possible to get this maybe 200b smaller or so and squeeze in more stuff, but at this point I'm feeling pretty OK with the game as is.

Try it out, and report any bugs found!

# ¿ Oct 21, 2016 19:28

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

I added the game to the octojam page and added a cover image.
Everything looks alright at the edit screen, but nothing seems to work in the submissions list.
http://www.awfuljams.com/octojam-iii/games

Maybe worth looking at?

# ¿ Oct 21, 2016 19:39

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

taqueso posted:

Finally got around to trying this out. It works really well and the player movement feels good. I managed to get through one locked door and I was feeling pretty good about that until I saw that their are 40 or so rooms in the game.

42 rooms across three floors, with an endboss.

Therese a godmode constant you can toggle in the top of the source code if you arent a cool enough dude to finish it without it!

# ¿ Oct 28, 2016 19:56

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 07:21

Buffis: Apr 29, 2006; I paid for this; Fallen Rib

I just realized that I'll be traveling in Asia for over two weeks in October, which means I'll miss most of Octojam

I'll still probably participate, but will probably end up with something more limited this year. Spent quite a lot of time on Binding of Cosmac last year...

# ¿ Sep 18, 2017 20:43

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Gamedev Like it's 1977: CHIP-8