---Designing based on the requirements--- 9/27

1. create a game
2. prepare a presentation of the game by the geeq kickoff party (nov 23-27)
3. game must be modeled after an existing and reasonably well-known game
4. game must be fun to play
5. game must be a different genre than the other geeqs' game
6. game must be easy to review and compare development process with
7. game must include design, code, animation, and audio
8. game must be kept secret until the presentation

---general response to each requirement--- 9/27

1. doing it.
2. will design this after game is complete. be sure to schedule time for it.
3. thinking pac-man here, for reasons I'll get into later
4. keeping this in mind throughout the entire design, creation, and testing process should be sufficient.
5. they are talking about board games (othello, checkers, scrabble), this is an arcade-style game. If they switch, I might have to change.
6. copious documentation of game and process should provide this
7. will be designed into the system.
8. will do.

---general design draft--- 9/27

A pac-man themed game seems like a pretty good choice. All the elements exist in simple forms - the codebase is pretty easy to conceptualize, it lends itself well to music and sound effects, and the animations are mind-bogglingly simple. I can always spice it up once the basic elements are in place. A few spicy thoughts : intro movie, ability to play any midi/mp3 as background, selecting different sound effects etc (kind of a demo of what is possible in a game), different characters, random and/or custom levels, and so forth.

As a backup, I could try to create the rubick's cube game that's been going around in my head for a few months, maybe if the other geeqs switch to an arcade game I'll do that. Or I can just save it for another time - it's certainly more work than this would be, or at least more 3d-intensive.

---brainstorming--- 9/27

what about network features? a high-score website or multiplayer capability?

java or c? I'd like to do it in c, but given the short timeline, I'd have to rely too heavily on sample code for the animations, and if (when) something went wrong, I wouldn't understand the code well enough to fix it. So...java is best this time.

reverse of roles? player is a "ghost" (or all 4, switching between them at will?), and the computer is pac-man? Possible restriction of movement (can't reverse), switching between them with 1-2-3-4 keys (numbers show on ghost bodies), uncontrolled ghosts revert to AI?

ability to rotate game board, 90 degree increments? Gravity effects "stun" ghosts?

---breakdown--- 9/29

Conceptually, the game design itself can (should) be broken down into components:

X AI (for automatically moving characters)
X sound system
X user input processing
X game state (board, characters, etc)
X graphics
X game control logic
add-on features (new boards, audio options, different characters/modes, etc)

Each of these will end up being broken down further.

Ex. graphics :

characters
board elements
main display frame

---game state--- 9/29

Ok, I'm thinking that the game state can probably, in its simplest conceptual form, be represented as a 2-dimensional array of bytes, with values that correspond to various possible elements in the game. For example:

0x01 - blank
0x02 - wall
0x03 - pellet
0x04 - super pellet
0x05 - warp
0x06 - bonus fruit

Warp kind of breaks this model though, since it needs to have more information than just its existence. It should have an endpoint. But really, that's at most just another byte or so of data.

This model of course limits itself to a 2-dimensional board. Which is probably reasonable considering the small scale of this project.

The graphical representations of these items are irrelevant to the game state, of course. But the location of the characters is a little more fuzzy. It could be a function of the characters themselves, or a function of the game state. If it is not part of the game state, then perhaps it should be called "board state" instead.

pondering...

The problem with including character locations, directions, speed, etc in the game/board state is that they don't fit nicely into the 2d byte array model. True, they *could* be officially present in only a single coordinate at any given time. I guess it wouldn't be up to the game itself to determine the direction, speed, etc of the characters, certainly not where to draw them WITHIN the board. But it could handle things like determining what is on the same square as the character, and prompt the character to, say "consume" a pellet or "die" if on the same square as an inedible ghost.

Ah, but if it is represented as a 2D array, with each coordinate being a place on the board, there's no way to represent multiple items in a single place. That could be a problem. I could always change the representation of course, but...is there a better solution?

Maybe it's just best for each character to do its own state handling. Each time they move from one position to another, they can check the game state to see what's there, and interact with it appropriately.

So what triggers the completion of a level? Obviously the character itself can trigger end-of-game if it dies with no lives left. But when a board is complete, who checks that? Does it make sense to have the game state check itself whenever a pellet is eaten etc? Or should the pac-man character do that check whenever it eats a pellet? What gets notified to finish the level - the game state, the game control logic, or something else?

Probably the game control logic. The state doesn't *do* anything, it just tracks stuff. So pac-man can check to see if the board is empty whenever he eats a pellet. If the board is empty, he notifies game control logic that he's completed the level. It handles whatever transitions are necessary between levels (score updating, bonus counts, cutscenes, whatever), then generates (or causes game state to generate?) the next level.

Tough call on that one. The game state really *knows* what its size etc is, but it's not really in scope for it to create itself. So maybe the game control logic can determine the correct size of the next level, use whatever parameters exist to generate it, then cause game state to initialize itself with those parameters. Seems to be the cleanest solution.

I still haven't solved the warp problem though. It could just be a 2d array of object references I suppose, but that would require (in Java) checking the type of an object whenever it was loaded, and then it could be confusing to have a "pellet" object in the game state and another "pellet" object to be represented graphically....etc etc.

(9/30)

Ok, I think it's reasonable to just have it be a 2d array of objects, or possibly a superclass of all the objects that could exist on the board (rather than generic object). The superclass could contain some kind of type variable, defined in each subclass...actually it is probably best as an interface or abstract class. I'll have to check on the differences between the two, I'm not clear on it. But the point is, the superclass/interface can specify a data item which will hold the type of element it's implementor is. Each implementation of the class has a hardcoded value for that data type, which can be checked by the game logic/graphics code where necessary. If properly written, it might not even be necessary to cast the elements to their own data types, most elements on the game board seem to have similar characteristics - a graphical representation (static and/or animated), a passable/not passable flag, consumable/not consumable, or just a move_onto() function...anyway, this is out of the scope of the game status part of the document, so I'll save it for later.

So, game state, in summary, is:

2d array, containing elements currently in the game (not including characters)
functions allowing removal/addition of elements individually or en masse.
elements are a superclass/interface with TBD elements but must include a value indicating what kind of element they are.

hmm...I guess that's it. Everything else goes somewhere else.

---graphics--- 10/3

After working out 16 possible wall segments based on points (each point IS a wall segment and can connect to others or none - see graphic), and comparing my results with the original game board, I realized that namco used a smaller set of possible segments by making them intersection-based instead of point-based. I think that gives a total of 6 possible segment types instead of 16. If I'm to include an "original map mode", I should copy this design.

10/10

General graphics thoughts. Modeling after an existing game lets me avoid the majority of the graphic design work by simply declaring that they will more or less match the original. They shouldn't be identical, but that kind of detailed imagery can be worked out during implementation.

A few things that aren't covered in the original game are special features of this version. Scaling, for example - we need to take into account screen resolution and possibly allow the user to resize the game window. Also, rotating the screen, if implemented, would be done from scratch.

But basically, I'm comfortable at this point simply saying that the graphics will be based on those of the original pac-man game, with enough creative license to tweak them as necessary.

Additionally, the graphics component should be implemented in such a way as to allow features like scaling, rotation, and substitution of all graphical game elements with custom ones, if possible.

---sound system--- 10/10

In the spirit of *design* rather than implementation (learning as I go), I'm going to refrain from looking up packages or add-ons or really anything that will tell me what is feasible and what isn't. This is the design document and I'm just going to say what I want the system to do. Implementation is not my problem....yet. I have a feeling I'll be cursing myself later for setting the bar so high, but whatever. I can't come back in time and kick my own ass, so I'm safe for now.

Uh, ok. So...back to sanity.

This seems like the easiest part to design, which might be misleading. Let's find out.

At a bare minimum, the sound system needs to support playing 2 audio channels (if that's the right word) at once, including the ability to either stop one mid-play or silence it and start playing another. I'm thinking specifically of the ambient sounds or music as background, and the sound effects of the game as foreground. One event might be interrupted by another, and the sounds should be able to "react" to this (as opposed to having to wait for one sound to finish before starting another). Although I don't have any experience with them, I suspect these features are common to all modern audio libraries/utilities/whatevers.

The other significant feature is the ability to use different types of audio files. A few possibilities include wav, ogg, mp3, some kind of internet audio stream, CD player, sound from a movie file or DVD....etc. It would be nice to allow players to specify their own sounds in any reasonable format, either individually or as a sound "package" for the game. Restrictions might be placed on the length and/or volume of certain sounds, or they might not. Matter of fact, probably best to let the players/modders decide what works.

---user input processing--- 10/10

This is an interesting one. The original game was played with a 4-directional joystick. The obvious design decision here is to allow the use of the arrow keys (or let a player map their own keys). However, the presence of the mouse makes me wonder if there's a good way to use it as well. Possibly either allow the player to switch between them or have additional features available with mouse input.

This is particularly interesting with regard to rotating game boards. Instead of instant 90-degree rotation, what if the board could rotate more slowly, or maybe even constantly? A mouse would almost certainly be a boon in such a situation.

Short answer : Design for arrow keys. Expand to player-option key mapping. Implement mouse control after everything works as a glam feature.

---AI--- 10/10

Geez. I know so little about AI. This is going to be a bear to implement. But, I guess, if I design it in a modular fashion, I could experiment and *plug* different AIs into the characters to see how they act.

This is a little outside the scope of the design document, but I'm struck with the notion of an AI *interface* (Java definition) that each character would have access to an instance of, and would simply...I dunno...pass it the game state including character locations and the AI would return a value telling the character what to do next?

Seems simple enough.

Anyway, on the topic of design though:

I think the trick is to experiment with different AI types. Allowing the players to make their own would be pretty damned cool too, possibly allowing a sort of "robot battle" competition...could be very addictive. Anyway, point is, experiment with different AI types, see how they work, and pick the ones that make it difficult, but not impossible, to clear a level.

Speaking of which...the original pac-man increased difficulty by using speed. Should I do the same? Should I stick with the theme of customization and allow different difficulty features? What if the player had some input over what would be made more difficult in the next level? They could work towards a particular set of "difficulty" features that made the game more enjoyable for them.

For example...

Little challenges like, if you manage to eat each ghost at least once, you get an extra super pellet next level.

Or things that stick with you, like character or game development. The game gets faster (or not). The ghosts / protagonist gets faster/slower (or not). The music gets faster/slower. The color changes. You unlock different bonuses. Ad nauseum. Lots of potential things to change...heck, the game customizations might be unlockable...start with your basic pac-man and add hidden secret after secret after secret until the end result is this amazing customizable game that everyone is addicted to because they worked so hard to achieve it.

Then add in some networked play and/or ranking system, a place to distribute and download customizations, discussion forums....you've got a potential hit on your hands.

I love it when my brain works.

So...totally off topic, but I think I settled the AI design question. Moving right along.

---game control logic--- 10/10

I'm not sure what parts of this I haven't covered.

I guess things like, how to tell if you can move in a direction or not, what happens when you do this, when you do that....ok. So basic game flow and how it works. I can do that.

10/11

At it's core, the logic is simple. You have a game board, regular and super pellets, a protagonist, and some antagonists. Occasionally some bonus items might appear. The game board consists of barriers, spaces between them, and warps. The protagonist can move in any of the 4 cardinal directions (is it possible to reverse? I think so. Check the original game) if there is room, the character moves in that direction. picking up pellets earns points and causes pellets to disappear. Picking up super pellets causes the antagonists to change AI (flee) and become vulnurable to the protagonist for a short time.

This is all quite boring because it already exists. Perhaps I can simply say : "act almost exactly like original pac-man by default, possible addons, specials etc.

Speaking of which, potential special could be the ability to change direction or not...maybe a downgrade? Also switching roles if I didn't mention that before...playing a ghost?

10/17

Thinking of the logical flow of the program, I came up with this:

game control object updates all of the "living" elements. They change locations, modify game state, do whatever they do in the normal process of their existence. None of this is apparent on the screen at this point.

game control object sleeps until the next "tick", then triggers the actual UI update.

potential problem here - what if it takes too long and a tick is skipped?

Well, the problem in general exists - what do I WANT to do if it's taking too long to process data? Granted, this should not happen, but if it does, undefined operation is not the answer. So...in the "unlikely event" that the tick processing is taking longer than a tick, do I want the game to slow down? Do I want the interface to "skip"?

Easy answer - the prime tenet of a game is that it be fun. It's no fun for a player not to be able to see what's happening. If they want to play the game using mo'slo or on a PC XT, that's up to them. So, should I attempt to slow the game down in general, or just skip ticks as required?

I'm thinking that skipped ticks should be accounted for somehow, maybe logged or indicated on screen in such a way that if they are a considerable problem, it will be apparent. A potential advanced feature for later could be a speed bar for the user to manipulate and/or general game adaptability, trying to even out the play of a jerky game if necessary.

---notes--- 10/12

I can solidify this into a presentable document later. For now, I'm ready to start implementation. It'll help me stay focused too.
---add-on features--- 10/11

I think I pretty much covered all these in the previous sections as I thought of them.

10/17

kinda lame, but what about a special "jump" ability? Make the paku bigger, jump over a wall?

what about the ability to affect game speed? bullet time pac-man? heheheh

11/10

possible text file Motivation setup - user can define a series of "states", along with different commands for each state and possibly
a percent chance each command will be selected. Commands might include changing states. Input would be things like relative location
of other things on the game board, walls, maybe some kind of pathfinding feature?

Odd thought - adding the ability to "shoot" wall segments?

Another special - ghost can, sometimes, pass through walls? Maybe at a slower pace?

And another - pellets can only be eaten for x seconds after eating a ghost? super pellets would have to respawn or just have lots and
lots of them.