My game WIP: NGCS

Hey guys! Work on my NES game has slowed for various reasons, so I thought I'd share some screenshots and info with you guys since I won't be releasing it soon. It's a two part project: a ZZT/MZX like GCS with simple scripting language, and a game written using said GCS. The GCS is essentially just a custom tool for creating data for an NES game like the custom tools that most of you have made except that it's more in the style of ZZT and I was planning on releasing the tool along with the game. The tool works like this: you create a little game in it and then click compile and it spits out an NES rom.


Here are the "post-mortem" problems I ran into that have caused me to slow development:

1. The world is made of ZZT style robots that run ZZT style scripts. Despite my best efforts, these scripts are relatively slow: I can only have about 8-12 robots on screen before there is noticable slowdown. This sounds like a lot, but my engine consists only of robots and the map. Robots must be used to represent everything on the map, and 12 is far too little to represent everything on a given screen. This requires the addition of non-robot objects or "builtins" as they would be called in ZZT:

2. Because robots are slow, I need "builtins," but because the engine is currently designed around only having robots, sprite allocation and a couple of other systems would need to be redesigned.

3. I transitioned from ZZT style graphics (1x1 sprites, text based graphics) to going all out exploiting NES hardware for graphics (metasprites composed of 1x2 sprites of custom graphics etc) due to wanting to impress people (and prevent criticism of my graphics) on this forum. This was a mistake. I successfully implemented all sorts of awesome graphics stuff, and it works, but I enjoy it less. I liked working on a ZZT style game for the NES. It had a certain amount of novelty and specialness to it that I lost when I went full graphics. Further, this focused the game itself much more on graphics which is a loss.

4. Because of the limitations of the original design (ZZT style tile based game composed only of robots) combined with the new graphical style limited my gameplay options, and I ended up designing a game that isn't any fun:

5. I designed a game called Siren's Melody, which is essentially an overhead stuck in tiles Dizzy-like object collection game with Final Fantasy style graphics. The entire game is just you collecting objects and talking to people, and using the correct objects/talking to the correct people with the correct objects etc. So you collect items and talk to people, and that's the game. I don't find this game any fun. It's just a walking simulator, and it doesn't fit into any well defined genre. I just don't think it's fun or that people will enjoy it.


My current plan forward is to go back to ZZT style graphics, and rewrite the sprite allocation to handle ZZT style builtins after which I will produce a game in the style of ZZT. What do you guys think about this plan? Is it a good plan?



Here are screenshots of NGCS and the game in its current state:

The editor:


The graphics editing section of the editor:


In game:

I like that!

You'll note that the original 4 commercial ZZT worlds are really light on robots. I've used ZZT on a plain Tandy 1000 (no letters); slowdown became noticeable with some of the later worlds created by that community.

Thank you! I'm hoping to go in this direction in the future of this project.

Well, I'm always in favor of more, so…keeping the current/sprite version somewhere (code and binary) just so you can revisit it (or release it), or have as a separate framework…but if it's not what you like, you don't have to keep working on that end. I think it's a good idea to get to where you enjoy the thing you're working on, though.

I always liked MZX. The color paradigm would have to change, of course…

You ever tried Zelda Classic?

Looks cool since I used ZZT/MZX before, but there's Problems with your current concept for BG/Sprite Splitting, depending on your mapper and sprite mode usage:

Sprites:

- [8x8] Sprite tiles use 256 tiles if using normal NES mappers
- [8x16] Sprites uses 128 from BG and 128 from Sprites
- [8x16, MMC3] Sprites can only use 128 tiles from $1000 area if IRQ is used
- [8x16, MMC5] Sprites can use 256 tiles

Backgrounds:

- Background Tiles use 256 tiles if using normal NES mappers
- [MMC5] Background Tiles has 8x8 attributes and extended CHR bank selection in ExRAM mode 3, or ExAttribute mode

if you're using MMC5: no flash cart other than a powerpak or the original MMC5 cartridges can run it

I'm currently using 8x16 mode with UNROM 512, but this was an upgrade. Originally it was 8x8. I have 2 frame animation implemented, but I'm probably going to be disabling it or taking it out. Since I'm using 8x16, I have to be careful about sprite layout because NES 8x16 mode is a bit strange (the tile is displayed vertically, but loaded sequentially). The 8x16 mode despite only being able to address 128 only needs to address 128 to display all of the tileset because each sprite contains 2 tiles. Again though, layout is important, and the editor handles layout automatically.

The color is a bit of an issue for a ZZT like game, but it's more an annoyance than a major concern. It's actually kind of cool how minimalist the color has to be. It's even more constrained than ZZT in some ways which has a unique look.

My current plan is this: I'm going to cut out all the new graphics stuff (including the 8x16 sprites, returning to 8x8), and essentially do a game as close to ZZT/MZX as possible. I DO plan to keep this copy for later just in case I decide to reimplement these features I'll be tearing out now. For right now though, this ZZT thing really inspires me.

I'm really glad you guys are responding so positively to the ZZT/MZX idea. I didn't think there would be as much interest as you guys have shown, and it's really inspired me.

Thank you guys so much for all your great feedback, and keep it coming! Any suggestions/feature ideas/etc. are welcome!

Why is there an ad for ZZT in the middle of the loading screen of Zombies in Call of Duty: Black Ops?

1. Maybe compile scripts rather than interpreting while running? just a thought.
2. have some precompiled move patterns/speeds that can be shortly set by a single command. A loooot of robots I'd written in MZX had to have a GO [CW/CCW/ANTI] SEEK WAIT N loop, dependingo n what they were doing at the time.
Recommended: go toward player, "snake" (like in Startropics: when lined up with player, begin to move in straight line that direction), "trap" (like in Zelda: see above, but then slowly reset to original) run away, walk-then-turn (left), walk-then-turn (right), walk-then-turn (around), randomwalk (either per-pixel or per-tile), follow-right-hand-wall, follow-left-hand-wall…
3. Have a function that determines distance to player from robot.
4. If lava/water are things, have them in the same bitmask byte of a tile as solidity. Then a robot or builtin can go and treat lava, water (or their opposites, with some clever logic) as solid, to make cannot-swim or aquatic creatures.
5. IF you're doing something akin to MZX's ZAPpable labels, then keep a current pointer (or similar) into the script for each, rather than scanning each time.

Very nice Idea! It's Always nice to see someone else making a GCS for retro platforms.
BTW, is your ZZT-OOP implementation compiled or interpreted?

Zoo of Zero Tolerance Object Programming?


Everybody's crazy 'bout a sharp dressed man