The Bryte development demo. It is meant to introduce players to the game mechanics and give a sense of what the full game will be like.
This is a really nice game, and if it is only the beginning, I'm really interested in what else there will be.
1) Just a suggestion: Make the player be able to use the keyboard direction keys in addition to WASD. Since no mouse is required, I usually like to play such games with my right hand, and the cursor keys are better suited for that.
2) Just another personal preference: The game is tile based, objects can be moved only from tile to tile etc., but the protagonist can move fractures of a tile. Unless later levels make use of "half filled tiles", consider making the protagonist move one tile per key pressed.
3)Since light plays an important role, it is paramount to communicate to the player which tiles are in what state of lightness/darkness. I could figure out what the natural radius for the "sun" and "moon" tiles where, when there is no obstruction. But even after completing the demo I can not say for sure how exactly the obstruction mechanism works. Example
e: empty square
l: light source
m: moon square
considers the moon square "dark" and thus activated, but
considers it "lit" and thus not activated. Why is it possible for the light to travel first 2 squares down and 1 square left but not 1 square left first and then 2 squares down?
Thank you for playing ! I'd like to address some of the comments you had !
1) I'll absolutely do this, I always prefer wasd, but I definitely understand those that prefer the arrow keys !
2) Early versions of the game work this way. There is just something about the freedom of player movement along with the grid-aligned puzzle mechanics that I really like. However, there will definitely be changes in the future around how this plays and feels.
3) I can see what you mean by the scenario you mentioned, and I'll experiment around to see if I can get something that acts more like:
where the moon is dark, and where 'd' designates dark/empty squares
There is another scenario where the light doesn't make sense to me. If you put a non-light block directly to the left or right of a light block, it creates a different light pattern than if you put a non-light block directly above or below a light block. This and the behavior you observed is a direct consequence of our implementation. We use En.wikipedia.org's_line_algorithm to light a path from the light outward, and it seems to not always create an expected result. The algorithm, at one time, was used for line rasterization, so we thought it might be useful here. We'll have to change our implementation to get patterns that make more sense !
Thank you for your thoughts !
Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.