Game Development

Simple Game Project for August: Oracle’s Eye

I am going to use this post to describe a game design I’ve been working on for about a week. I’ve given this project the codename Oracle’s Eye. Just because, really.

Why a codename? After working on FuseGB for June’s Game in a Day, I realized that sometimes the game doesn’t end up the way you planned. The game in the end didn’t have anything to do with Fusion, so the name was weird. Unfortunately, my project folder and Subversion repository was already using the name, and I didn’t want to mess around with it. If I use a codename, however, I can change the name of the actual game and not worry about how it will affect my development environment. The real name only matters when I publish it.

Anyway, Oracle’s Eye won’t be anything special. I am purposely trying to design a small game that can be completed within a month. In fact, it may be that what I’ve come up with will have to be reduced in scope even further. I need more experience and shouldn’t stop just because the game might not be very original or fun. I can concentrate on innovation and fun when I know more about how to make a game.

Basically, I am thinking about making a game like The Adventures of Lolo and Boxxel. The player will have to move about the screen, pushing objects around, and trying to get a Ball into the exit. Some objects are moveable, some are destroyable, and others can be activated.

The main object will be a Ball. The Ball will sit until acted upon. Then it will continue until redirected or stopped by a wall. To make the Ball move, the player can “kick” it by walking into it. A Ball can also be shot out of a cannon if the player walks into it to activate it.

To maneuver the Ball, the player can manipulate different objects in the level.

Some basic objects I plan to have in the game:

  • PIPES can redirect balls (wow, does this look bad)
  • GRINDERS can split ball into multiple balls and shoot them in multiple directions
  • WALLS can act as angled banks to bounce balls
  • PITS will steal balls
  • ENEMIES will fire upon player along straight lines and can be destroyed by balls
  • WARPS will transport an object to another spot
  • ARROW blocks will force objects in one direction

I can already see that a number of these will not likely make it by the end of August, but having more ideas than can be used doesn’t hurt.

The player won’t be able to do more than walk around. No shooting or button presses are needed to do actions as everything will be based on contact. If the player touches an object, the object gets moved or turns on or gets activated or whatever. I’ll probably track input to reset the level and to pause the game, but otherwise the controls will just move the player in four directions.

For simplicity, the levels will be “rooms” that can fit entirely on the screen. Rooms will be made up of permanent walls, an exit, and various objects.

Obviously the above is a bit too general, so it would be quite a stretch to call it a design document. I think calling it a guideline should be accurate, though.

6 replies on “Simple Game Project for August: Oracle’s Eye”

Sounds like a good plan. Nothing gets you working better than a deadline. 1 Month sounds like a good time frame because it forces you to really trim down your design to the essence of the game, but still gives you enough time to put some spit and polish into it. Good luck and I look forward to seeing the results.

I had started something similar but got stopped because of some problems. I do have some beginner design docs though if you or anyone cares to look –

By the way TilesDDV02.html is actually the third document but only the second version of the game, it doesn’t have as much detail as the first as I was going to start with a basic functionality and then add more as I got more of it done.

I was plagued by programming problems, not design ones

Keith Weatherby II
aka Uhfgood

Well actually I should have said I had a problem implementing parts of the design. Essentially the big problems were with the “Directional” tiles. See the ball is supposed to be able to move over it in only one direction and do it smoothly (not tile by tile). Now normally this would be easy except I had the bright idea that the ball could not enter on any of the 3 sides except the one with the wide area of the arrow.

I wanted the ball to stop when it hit the edges, however if I had put two of the same together then the shared edge should be passable. I finally got that working somewhat with a bunch of if statements. The ball would have this funny habit of moving over the tile and then instead of moving smoothly off the other side it would “pop” over to the other side and stick there.

I also had setup this system where there were attributes that i would set on the tiles so they would do the various things (would work out later when making a level you simply set tile attributes and build a level from that). This ended up being pretty unweildly. The fact you could assign one edge as stoppable one one side and passable on another just made for more “sticking” problems. Or problems where the ball would stick to the opposite side, or whatever.

There were also some problems when I set the attributes to
So those two in combination – the collision problems and the attribute system sort of “halted” development. The last design doc up there is the one without much of anything in it, because I was thinking of starting over. But I couldn’t get around those collision problems in my head.

If I were going to do it now I probably wouldn’t deal with tile edges at all. It would make it much easier.

So in actuality they weren’t necesserily programming problems as design problems that manifested themselves as programming problems. (This is why you see the last design doc being bare, i was going to redesign it to make it more accessible to code).

Actually this is interesting though, the ball moving smoothly and pretty much anywhere on the board — which caused some of the afformentioned problems, i’m working on a game right now where you’re essentially moving a game piece over a board from tile to tile instead of anywhere on the board willy-nilly. However it smoothly moves from tile to tile (instead of a jolt). Now if I had thought this way I would probably had a decent working version of the game. Of course then it wouldn’t be the “exciting game of quick thinking and fast reflexes” would it?

Sorry to make such a long comment.
All the best
Keith Weatherby II
aka Uhfgood

Comments are closed.