Many thanks for the review! I'll do my best to explain some of these
points.
> Concept: Draft a good prototype for a Roguelike, but fail to give it
> the bugfix it needs to be a good game.
Agreed! Unfortunately, this seems to be a chronic problem for buub0nik
and I. No matter if the competition is 7 days, 6 days, 48 hours,
whatever... we always seem to get to that point of "OK, the engine is
done, time to balance!" but we hit that point 30 minutes before deadline xD
I hate this because while I am happy about the technical nature of the
engine, the player doesn't care. The player wants a segfault-free and
balanced experience. I think the lesson to take from this is that we
need to feature-freeze 24 hours before submission and JUST work on
playtesting and bugfixes. I wanted to do that this time but we simply
didn't have our core features finished early enough.
> Graphics: Utilizes libtcod for a good-looking roguelike and an
> interesting visual effect between day and night. ****
libtcod is a wonderful little library, especially if you take full
advantage of its color functions. For example, we will eventually
implement fire and burning tiles. An easy way to represent this would
be to color a tile's background red, but if you want to get fancy you
can fade the red in and out to make it flicker like a flame. Also, jice
just added an SDL post-process render callback, meaning you can do stuff
like draw particles for an explosion, or animate environment effects
like rain. Very cool stuff!
> Controls: I wonder why SHIFT was chosen for help instead of ?. And
> why is the player able to attack his barriers without confirmation?
> At least the controls are intuitive and explained coherently. ****
I was having problems getting '?' to register for some reason! I spent
30 minutes trying to get it to work and just gave up, assigning SHIFT
instead. I have since figured out what I was doing wrong, and the next
version will use '?'.
As far as attacking your own barricades, I felt this was ok. One punch
against a barricade shouldn't screw you over too badly, and having a "Do
you really want to do this?" confirmation would be annoying if you
actually DO want to destroy something. I assume players will
accidentally hit a wall a few times and quickly get used to that fact
and be more careful. If you can think of a better way to handle this
I'd love to hear it!
> Difficulty: Zombies start out as wimps, lulling you into a false
> sense of security. Overnight, they eat steroids, suddenly becoming a
> much bigger threat. I didn't find too many problems beating them, but
> the game kept crashing before I could explore further. Some may be
> appaled at the sudden change in difficulty.
Ah, balance issues. Would you be disgusted to know we didn't even fully
play the game before submitting it? I know I am :P
> Strategy: The choice of four resources to build things seems odd,
> especially considering the few things there are to build. Strategy
> simply consists of surrounding your cellar with walls, as zombies will
> punch at them hopelessly. ***
Funny story -- buub0nik's girlfriend (who is an architect) was there
when we discussed some of the basic ideas for this game. She was
absolutely thrilled at being able to build stuff, and wanted us to
pretty much make Bob the Builder 7DRL. She was listing off all these
different building materials, multiple types of concrete, what to use in
different situations and for structural integrity, etc etc etc. We
obviously didn't go that far, and settled on four resources :)
I too feel like there is something lacking here. In my mind I wanted
complex interaction between different structures. For example, cement
walls would block sound better than wood. Wood walls would allow light
to shine through, but can catch fire (possibly a good thing for traps?).
Braces help absorb damage and can be repaired. Metal walls are hard
to break but can be toppled if too much weight is applied to one side.
I hope subtleties like this should make the building more interesting.
Also, more complex zombie behavior will hopefully put more focus on good
building strategy. They need to understand how to navigate gaps in
walls, rather than simply walking into them.
> Bugs: Prepare for an annoying search and destroy after the zombies
> suddenly stop moving for no apparent reason. Brace yourself for
> segmentation faults that will kill your game. **
Yeaaa, that is an embarrassingly game-breaking bug. That will
definitely be fixed in our next update.
> Other comments: My other annoyance was with handing out items, as you
> have to place them directly on the map. This is slightly annoying
> when you can't see what items you have, and you can't cancel the
> handout.
How would you improve the salvage system? I didn't want to put items
directly in inventory, since if the player's inventory is full it would
require a better item-management interface which would have taken too
much time. The idea was that placing directly on the map would allow
you to stash ammo in a certain spot if you wanted. There definitely
needs to be a 'discard' option so you don't clutter up the map with crap
you don't need.
Thanks again for the review.. I appreciate the testing of our entirely
unpolished game. With some tweaking I hope it'll actually be fun :)
