Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

What are you making?

A topic by Tobias V. Langhoff created Oct 01, 2020 Views: 1,110 Replies: 44
Viewing posts 1 to 14
Submitted(+1)

The jam has started! Has anyone started? Do you have any ideas?

I have a few ideas. This year my goal is to make on CHIP-8 game targeted at the COSMAC VIP, one SUPER-CHIP game targeted at the HP48 calculators, and one XO-CHIP game. I made two CHIP-8 games that ran on original COSMAC VIP hardware last year, and that was great fun. (I also like turn-based stuff and puzzle games anyway, which is well suited for that.)

Submitted(+1)

I've settled on the idea of making a microgame collection (i.e. Warioware).

My biggest worry is that I don't know exactly how much I can fit in, especially since this is my first time working with the CHIP-8 and its extensions. Guess we'll just see how that goes...

Submitted(+1)

Cool! Usually CHIP-8 games have the scope of a single micrograme, hehe. But it's definitely possible to cram a bunch of stuff into one game, especially if they don't need a lot of graphical assets. Even then, XO-CHIP gives you a lot of space for assets (just not code, easily at least).

Wait, why does XO-CHIP not give you space for code?

Submitted(+3)

Well, there's nothing stopping you from putting code beyond the "regular" 4K of CHIP-8 memory, but XO-CHIP doesn't provide a way to jump or call code there. You can set the `i` index register to anywhere in the 64K memory space, however, so it's easy to use for graphics or audio.

HostSubmitted (4 edits) (+2)

Right. It's a product of the instruction encoding. The "jump", "jump0", "call" and "i:=NNN" CHIP-8 instructions only have space for a 12-bit immediate address. XO-CHIP expands the RAM available, and provides "i:=long NNNN", which can point to a 16-bit immediate address (and which is 4 bytes long instead of 2). Since jump/jump0/call don't have a "wide" flavor, you can't as easily place code outside the low 4k.

In practice this is still enough for quite elaborate games. It does, however, mean that XO-CHIP programmers should be more aware of where they're locating code and data in the address space.

Low ram is best used for code, high ram can be used for graphics, sound, or working memory. If you're running out of "code ram" for an elaborate game, you could write a small interpreter that executes bytecode from "data ram", at the cost of some speed. My game Business is Contagious used this strategy for most of the game logic, since only a few parts of the UI code were at all performance-sensitive.

(1 edit) (+1)

Oh yikes, how did I miss that? No indirect jump from I (which would make long jumps trivial)… hmmm… :-/ I think that deflates my plans for something really ambitious just a bit. :|

(+4)

I'm making a minimal RPG, squeezed into VIP memory constraints. Today's progress: working health and energy display, and a rudimentary text system with a 5x3 font. Up to 574 bytes already, which is just a bit worrying. We'll see!

Submitted(+1)

Oooh! That looks cool! Good luck with the text system!

I keep staring at this idea but I don’t know that I’ll have the inclination/time/design skills to finish a platformer like what I have in mind.

(+3)

Much progress today. Text systems are *fiddly*. I ended up writing a basic string concatenation routine, as otherwise erasing the full line of text when it's built out of so many small parts was a state tracking nightmare.

I want to generalize the player / enemy structures a bit so that attacks can swing in either direction, and therefore share most of their code. Then enemies can respond with attacks of their own, and that should close the interaction loop for battles. Then onward to magic!

(+1)

Huzzah! Loop closed!! Here's my poor brave adventurer, taking on a party of helpless slimes, and ... wait, what are these slimes eating!?

https://rusticnes.reploid.cafe/images/overpowered_slimes.mp4

Submitted

That looks really cute! I love it. Can't wait to see how it turns out!

Submitted(+2)

I had a few ideas, but the morning of the jam I had a vision of a Chip-8 AKIRA game. I went with XO-Chip mostly for graphics reasons. I wanted the extra resolution and space, plus the two drawing planes was very helpful. I'm still working on it, but I submitted it already for easy sharing.

https://atomr.itch.io/akir8

I'll probably make a few more things before the end of the month too.

(+1)

More progress! The battle system is basically complete, it has physical attacks, magic spells, and a type advantage system:

https://workshop.reploid.cafe/images/magic_types_battle.mp4

The defender's type advantage is determined by the equipment and spells they are carrying, and this affects the player too. If you equip a lot of FIRE spells, you'll have an easy time with ICE type enemies (enemies who, themselves, have equipped ICE spells or frost-aligned equipment) but you'll be weaker to AQUA in return. These water-ice slimes won't exist in the final game, but their spell assortment demonstrates the concept well. The player can easily lose this fight by managing their spells poorly, even with such a large health pool.

The player, and enemies, can hold one weapon with an optional type alignment, one armor with base defense and optional type alignment, and three spells, which always have a type alignment and have varying power from 1-3 (technically 255, practically 3). At the highest attunement, one *absorbs* damage, which is the only way to heal during battle.

Your weapon always attacks a single target, and refills your energy by 1. Magic always hits the entire field, but costs energy according to its base power.

2273 bytes! Worryingly large at this point, as there's just the one enemy coded. I need to squeeze in room for a proper encounter table, additional enemy sprites, and the dungeon-exploring scaffolding that will actually contain these battles. This may require some dirty tricks after all...

HostSubmitted(+2)

I've been tinkering with a little K/APL interpreter that runs on SCHIP. No practical purpose, but it's kinda a neat tech demo:


Annoyingly, SCHIP doesn't scroll in the direction I'd need for terminal output, so I had to implement my own text-framebuffer and scrolling routine. I have room for 32 characters by 10 lines with this font, but I spaced the lines out to 32x8 so my entire output buffer fits in one 256 byte "page".

I have about 100 bytes left over, so I may try to squeeze in a few more features...

Anyway, with all that out of my system I'm ready to start work on an actual game.

Submitted

You gonna make a game that runs in your APL interpreter? lol 

HostSubmitted(+1)

Haha; not likely. As it is, it's more like a very fancy calculator than a programming language.

I may use some ideas I learned in the process of writing it, though!

Submitted(+3)

I'm working on a game that's roughly like the old Windows 3.1 game "Jezzball".  


I've never written a game for Chip8 before, despite having implemented an emulator for it a few times. I never tried very hard to find a reasonable assembler, and hand-rolling opcodes got tedious fast. I only discovered Octo a few months ago, and it's been an exciting find. The whole project is so cool and well done, I'm glad I found it! Not sure how I missed it for this long.

I started with a few tech demos to start to get the feel for how to do things: bouncing some balls, writing some fill routines, and animated line drawing. 

I'm making decent progress, but I sometimes get distracted by related projects: I'm assembling my code using a re-implementation of the Octo assembler I have written in Python (not out of any particular need... just as an exercise for myself), and running it on an "Arduboy" with an emulator I wrote for Arduino-based platforms with the ability to target different rendering platforms (it started with just Arduboy support, but now I can also run it on M5Stack). So often I get distracted fixing bugs in those things.

Hopefully, I'll have *something* reasonable to submit before October ends.

HostSubmitted(+1)

Your Jezzball clone looks great so far! Glad to hear you're having fun!

Submitted(+1)

Looks great! Haven't heard about that game before, but it seems similar to Qix?

Submitted(+1)

Yes! I'm pretty sure it was heavily inspired by Qix. The mechanics are slightly different, but the overall idea is the same.

Bouncing balls seemed a little easier to manage than that crazy dancing line thing.

Submitted

That's awesome! I used to play Jezzball when I was a kid, great fun. Please finish because I would love to play it! :)

Your other projects sound interesting too. I've been thinking for a long time that a Chip-8 "gameboy" should be possible for a very low cost.

Submitted(+2)

Well, things have progressed nicely... better than I was expecting! I have a name and a title screen, game flow with levels, a lose screen, and a win screen. Just working on polishing up some transition screens and trying to fix a few glitches, and I think I'll be ready to share something!

Submitted(+2)

Hey there!

I'm pretty new to Chip-8. I only discovered it about a year ago and had a lot of fun last winter writing an interpreter, an assembler and finally a compiled higher level language that I didn't finish. All in Javascript, and running in the browser. At some point I discovered that Octo is a thing that exists, and that Octojam exists, and because implementing the Chip-8 tools gave me so much joy decided to join the jam and see if writing software for the platform is equally enjoyable :)

I've been able to put a couple of evenings' time into my idea, and it's starting to look like something, so I thought I'd share what I'm working on.

The concept is loosely based on the 1981 game "3D Monster Maze". I really enjoy playing with retro 3D and pseudo 3D stuff, and as far as I could find there are no games or demos that do anything related to the third dimension for Chip-8. (Did I miss anything..?) Also, I like that the original game is almost as old as Chip-8 is, so that makes it a great match, I think. Probably no dinosaurs in my version though, I have some other ideas ;)

I can currently walk around the map in "3D" and I can also bring up a top-down mini-map to see where I am. I'm not sure if the mini-map is going to stay, or if it will mess with the gameplay. This screen capture is running at 30 cycles per frame:

These flat, boring images are just for testing the "engine". The intention is to get it to look more like this:


As you can see I'm still playing with shading the stones, making them dirty in some places? Maybe the ceiling needs some love too..? This project is going to be a lot of work, even in pixel art alone... ^_^'

As you can see I chose to use Octo's XO-Chip extension for drawing four colours and SCHIP's extension for drawing 16x16 sprites. That's all though, so another idea I'm playing with is to make a very bare-bones black-and-white version of this game that is actually Chip-8 only, and should run on the hardware from the period. It'll be slow, but it should just be playable, I guess..? We'll see! One step at a time.

If you're interested, my code is on Github, under a GPL license.

Submitted(+1)

That's awesome :)

Submitted

Thanks Tom :)

Submitted(+1)

Ah, I'm not as original as I hoped after all  :D

https://www.youtube.com/watch?v=5bVR5m_knWg

Can't find that game anywhere other than YouTube yet.

HostSubmitted(+2)

A long time ago I did a crude PoC for a raycaster engine. It needed to run at very high speed, and the concept of PWM-ing the display to achieve distinct colors was visually quite painful:

https://github.com/JohnEarnest/Octo/blob/gh-pages/examples/demos/chipenstein.8o

Your progress so far looks rad, Timendus! Really excited to see how it turns out.

Submitted(+2)

Impressive endeavour! :O

I don't hope to be able to achieve more than faux 3D. Especially if it needs to be finished in two weeks ;P

Submitted(+2)

Making good progress imho! Just a few more gameplay elements, some pixel art and much level & music design to go...


Submitted(+1)

Wow! That's looking fantastic.

Submitted(+2)

Wow, I actually managed to release (a version of) this before the deadline! ;P

https://timendus.itch.io/3d-viper-maze

I don't think I'll have time for the pure Chip-8 version in the next four days. Maybe next year?

HostSubmitted(+2)

This came out fantastic; well done!

I also greatly enjoyed reading the postmortem on your GitHub repo.

Submitted(+1)

Haha! Thanks a lot :)

Submitted(+1)

I started working on another game: https://atomr.itch.io/8min
It's like a version of pong I guess. The goal is to keep the balls out of your corner.

Submitted(+3)

First, let me thank you here, Tobias, for contacting me and making me aware of OctoJam. The enthusiasm here is awesome and I hope that I can contribute something worthwhile (or maybe just fun) to the mix! In recent months I wrote a Chip-8 interpreter "MyChip8" in Qt and C++ and, that done, I am now revising "Surround," from Pips for VIPS I. Reading that code and text has really taken me back to my origins! The original code runs, but not perfectly (perhaps due to its MLS calls, which I had to strip out of course). I considered perhaps fixing the bug, but it's not really in Octo; it's just the Chip8 byte codes in 0xff format. I wanted to write a new game in Octo, so that's what I'm doing for the Jam. The revised game, which is close to working, is called "Snake Surround" (I see there is a Snake entry already and it's really good! Mine is similar but different -- but the more the merrier, right?!) Cheers to all. -- Tom

HostSubmitted(+1)

Great to have you here, Tom!

Submitted(+2)

Thanks -- I really admire Octo, by the way. -- Tom

Submitted

Welcome, you can never have too many snakes!

Submitted(+1)

Indiana Jones notwithstanding <g> I agree

(1 edit) (+3)

Hey! I've been working on a Yahtzee implementation. I've restarted a couple times this month, and I think I've settled on a good format for it. It'll be taking advantage of the screen rotate to present a vertical screen, and it'll look like a score card.

My first drafts included help text, but it might be too much memory.

I'm using vanilla CHIP-8.

HostSubmitted(+2)

I've been doing some tinkering with a tile engine that can handle scrolling a large map and dynamically repainting the edges.

I think I have some ideas for turning this into an actual game. We'll see, I suppose...

Submitted(+1)

Cool! Impressive animation on the chicken! I'm guessing we're looking at quite a few cycles per frame here?

HostSubmitted(+2)

Currently I'm running at 500, and it's written in a pretty sloppy fashion. I think something like this could be made to work at 200 or less with more care.