Project Plan and Design

[ADobrzycki]

Hey Everyone,

Welcome to the GitHub repository for our first project. So, as you would have noticed by now, we are doing a simple maze puzzle game. What features do you want in it? How shall we implement the game? Do you have a less lame name for the repository? We should definitively answer these questions and finalize everything before Monday 22 July.

Adam

[DpEpsilon]

We need some weird core mechanic. People love weird core mechanics!

[ADobrzycki]

That's what I was thinking! I was thinking we could have "pressure plates" which when you go over weird stuff can happen. One thing could be that all your controls become reversed (up = down, left = right, etc.). Another thing could be that you get transported to another maze and once you solve that you return back to the original maze. Those are some things we could do. We could have a whole lot of weird pressure plates. Your imagination is the only limit!

[Blueblade11]

Throwing ideas out there.

• Portals
• Black Holes
• Traps
• Alternate dimensions
• Cake
• Escape the maze (pretty obvious)
• randomly generated mazes
  • sub program which checks randomly generated maze has a valid solution
• Main menu
  • new game
  • continue game
• side menus
• options
  • size of maze
  • number of levels in maze
  • 2d maze, with a staircase?
  • sound effects
  • bananas
  • cake
  • music
  • help
  • how to play
• texture packs
• noodles
• snakes and ladders
• buckets
• arrow keys/WASD
• toilets to another level

First of all though, we need to figure out how to actually code the damn thing. I think the first thing to do would be making the world of the game, then populating it later.

[DpEpsilon]

I think we have to know what we're coding before we code it.

How about something trippy like quantum superposition (sorry, just got back from science camp).

[ADobrzycki]

We should do two things to start with. Firstly, we should get someone to design all the graphics we will be using. Secondly, the rest of us should design the game engine which we will use for the game. After that we can then start designing a few initial levels and keep adding features to our engine where we see fit. Does that sound good to you all?

[DpEpsilon]

An engine is more important. Dummy graphics should be sufficient for early development.

[Blueblade11]

Red Square, Blue Square, Black Square, All The Colours Squares. Done. :D

[ADobrzycki]

So, how shall we go about implementing the engine?

[DpEpsilon]

I still think we need to have a relatively clear, established idea of what the game will be before we do any engine work. Firstly, are we doing a top-down graphical view or a side-scrolling view (i.e. a platformer)?

[ADobrzycki]

Sorry for the late reply, I had English Advanced and Physics Trials at school. Now, I think we'll go for a top-down graphical view (like a typical maze).

[DpEpsilon]

Cool. Now we decide things like whether we're free moving with various obstacles or just going through a strict maze, what kind of mechanics we should have...

[alvinwp]

Just got github, what's the plan for this so far?

[ADobrzycki]

Hey coolmanguy11. So far we have decided we are going to do a birds-eye-view maze game. Now, DpEpsilon, I was thinking that our "template" would be a strict maze. The icing on the cake would be the weird core mechanics we could add on top of the maze. Blueblade11 had proposed quite a few good ideas with regards to mechanics.

[DpEpsilon]

Idea for a trap. Something triggers a trap, the maze reconstructs itself to make the path to the end much longer.

[ADobrzycki]

Ok, I think we have enough ideas for now. Let's now figure out how exactly we'll go about implementing it.

[ADobrzycki]

Sorry for being away for a while. I had trial HSC exams. Now, let's start coding. Who should code what?

[alvinwp]

How about documentation on how the game is going to work? That way we will then know what needs to be coded.

[ADobrzycki]

I don't think we need to write the complete documentation for the game yet. We already have come up with quite a few good ideas. So, first up, we should figure out how to display a simple black and white maze on the screen. Then we can build on that a gradually more complex game engine. Along the way, we should write down the features we put in on the "documentation". Does that sound good to you all?

[ADobrzycki]

So, should I take that as a yes?

[alvinwp]

Yes for me.

[ADobrzycki]

Ok, lets start coding the black and white maze on the screen. How shall we do it? A method which I can think off the top of my head is to display it using a BMP file (like the HS1917 checkerboard). Shall we do that or does anyone have a better way?

[alvinwp]

Seems to complicated, how will it be refreshed?

[ADobrzycki]

I think it would be refreshed probably 24 times/second by updating the hex code. Although, if there is an easier way I am all for it. DpEpsilon or Blueblade11, do you have any ideas?

[alvinwp]

Assuming it is a bmp file, how will the user interact with it? When we did our Mandelbrot Sets javascript was used I think to provide an interface, so I guess it could be done that way. Why not use something like pygame?

[ADobrzycki]

What's pygame and how will that help?

[alvinwp]

Module for python allowing for graphics

[ADobrzycki]

Ok. Is there a way to combine the module to a program in C?

[alvinwp]

Not that I know of