Game Development

Oracle’s Eye Development: Gameplay Tweaks, Planning Next Steps

Oracle’s Eye is really shaping up as a game. I’m awfully close to the project, of course, so there could be lots of things wrong with it, but it’s definitely much more playable than when I called it “technically completed” a few weeks ago.

The links from December 9th still reflect the game’s current state, which means I haven’t done too much to update it. I made the Player’s sprite smaller and haven’t been able to walk through walls so far. Some of the small tweaks I’ve made with the code have made drastic changes in the resulting gameplay. For example, I combined two sections of code knowing that it wasn’t exactly what I wanted. I just wanted to get closer to whatever it was I was doing. The result: now instead of just pushing the Ball, you can push against the Walls, and depending on the direction you are facing, the Ball moves. Psychic powers?! Maybe I could make some Walls into switches that create a gravitational pull on the Ball? It might be an interesting gameplay development.

Of course, I haven’t exactly created or updated a detailed design, so how can I know when something is progress or the introduction of a bug? This project is starting to become a bit more concrete, so I think it is appropriate to list specific implementation goals. Since I’ve gotten this far, I really think it would be appropriate to turn it into a commercial quality game. Besides having a game to sell, it would also allow me to have the experience of finishing a game that doesn’t look and feel like a newbie’s first project.

It’s clear that Oracle’s Eye is becoming more like a puzzle game than anything else. The basic premise: maneuver the Ball through the Room to get to the Exit. Maybe that’s all a player needs to know, but what about me? I’m still making it!

  • The Player should not be able to occupy the same space as a Ball. If the Ball hits a Wall, the Player should find that he/she needs to push at the Ball from a direction that isn’t towards the Wall in question. The point is to force the Player to use the level layout to find the best way to move the Ball. Allowing the Player to move the Ball through him/her would break the game since the Player would not need to worry about where certain Walls are.
  • Graphics: the Ball should rotate when it is moving and in a way that implies rolling. As it stands,the Ball rotates in only one direction, and while it might not be too noticeable, it is incorrect. Similarly, the Player should have images from multiple angles and various key frames. The static Player image is fine for placeholder art, but it will need to be replaced by someone that looks alive and breathing. The Ball and the Wall and Floor tiles should also be updated with higher quality art. The graphic style should be cartoonish but not exaggerated.
  • Sound: the game is silent currently. I should work on getting at least one piece of music for the background. The music should be upbeat and fun. There should also be sound effects for the Player when he/she kicks the Ball or hits a Wall. There should also be sound effects for the Ball hitting a Wall or getting to the Exit.
  • Levels: each level will consist of a Room with Floor and Wall tiles, an Exit, and a starting location for the Ball and Player. Rooms should be able to have different dimensions. One Room might be 10×10, another might be 5×15, and another might have varying widths. The purpose is to allow vastly different level designs as well as varying visuals. The maximum limit is related to the screen dimensions and the Tile lengths. The Player should be able to choose levels from a menu, and finishing one level should allow him/her to continue to the next one. I imagine that the game would require the ability to restart a level if the Ball gets stuck in a corner or gets in some other situation that prevents Player progress.

I was about to add that I wanted extra items, like angled banks for the Ball to bounce in new directions, but I already decided to cut out such features. It’s a nice-to-have, and maybe I’ll find that it will be easy to add, but the above listing is what I want to concentrate on. I think that focusing on these things will greatly improve the game, and I can always write down the gameplay elements I come across that don’t fit this design but might be useful elsewhere. I will keep an offline version of what I have here. It should be easy to update as I gain more insight into the project and its needs. I already know that this isn’t nearly detailed enough, but it should be good enough to show you (and me!) what I’ll be working on.