This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Logical quesiton for a puzzle game

Logical quesiton for a puzzle game
by on (#73290)
Hi I started considering writing a puzzle game for that compo, and I have a major dilema.
OK it's a compo so I'm supposed to do everything on my own :D
In fact I figured the existance of this dilema very long ago, but I never had to implement it until now.
Anyways the dilema is the following :

The piece of puzzles could be logically implemented in two ways :
1) The game have a list of objects, which contains information about their position, their state, etc...
2) The game have a list of background slots, and object are inserted into slots.

Each ones have strongs pros and cons, depending on what you want to do. Not that this not only applies to puzzle games, but also for tile-based strategy games for example (that I also wanted to do on NES).

1) Has the advantage that it's easier to maze objects to the screens as sprites for example. It's also easier for logic, you don't have to check for empty slots or anything you just executes all object in the order of the list. It's possible to place objects outside of "slots" easily just by changing their position.

2) Has the advantage that it's easier for game logic. You can immediately see which are the adjacent pieces just by looking for the adjacent slot. That would be a nighmare in method 1. However, the main problem is to move things between slots... you'd have to do an "offset" trick, where the object is a bit out of it's slot, until is reaches the next slot then it's logically moved to it.
This method would make it hard to draw objects out of slots as sprites, because you'd have to first look for every slot if there is an object in it, and if there is one if it is moving (if so it should be drawn as a sprite).

Finally this method mostly prevents logical nonsense, such as two pieces being in the same slot.

Personally I'd go with method 2 but if there is advantages of method 1 I missed, please share :D

by on (#73294)
Color Dreams' Boulder Dash clones (Crystal Mines, Exodus, and Joshua) appear to go with method 2, where anything in motion is temporarily removed from the background and becomes a sprite.

by on (#73307)
I think it's highly dependent on the game. GemVenture is closer to method 2, and another puzzle game I've considered would probably use something like method 1. GemVenture actually treats moving gems and non-moving gems in totally different ways, so you could consider it using both method 1 and 2.

by on (#73315)
What kind of puzzle game are you planning on making?

by on (#73323)
Quote:
I think it's highly dependent on the game. GemVenture is closer to method 2, and another puzzle game I've considered would probably use something like method 1. GemVenture actually treats moving gems and non-moving gems in totally different ways, so you could consider it using both method 1 and 2.

OK I guess I could go with method 2 + a list of objects that are moving, and that are handled as in method 1.

A way I think I could implement things is that when pieces of puzzles are falling (other than the main falling one that the player control), they are "logically" instantly moved to their new place, but are displayed on their old place and gradually move to their new place, where they stop being sprites.

Quote:
What kind of puzzle game are you planning on making?

I already mentionned it once, I'd like to have something similar to Super Puzzle Fighter but I don't want to reveal more.