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
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
OK it's a compo so I'm supposed to do everything on my own
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