A General Idea - The Concept of the "Code Painting"I've recently begun thinking about how to structure a game. I've stumbled on an idea that I like and that lends itself well to very simple games.
I took the name of this idea from my philosophical blog. I call this a "code painting."
The basic structure is simple:
- Game exists only in the play state
- No menu states
- Play state usually becomes idle when not playing, but some concepts may benefit from the game constantly running
- Menus are drop-down and triggered by the F* keys
- F1 is for the "help" menu
- F2 is for the "configuration" menu
- Game concept is very simple
- Keyboard input should be arrows plus no more than four other keys (ideally only one or two)
- Mouse input should only use left and right buttons
- Joystick input should only use the d-pad (aka "hat stick") and no more than four buttons (like for keys, ideally only one or two)
- Content is either very simple or procedurally generated (or a mixture of the two)
In developing these, I will try to focus on less violent concepts and more on concepts that have some kind of artistic quality. I'm not going to be pretentious about it (I hate pretentious art), but I will try to do something that could be considered art.
At the moment, I am working on a C++ library for these, but I am also planning to make a Pygame port. If I decide to enter the Pyggy Awards, I will use that to work on the Pygame port of this library. The PyWeek version of my game will not use that library, though.
I'm also working on a specification for this library, which I will post when it is reasonably complete. However, I am writing the specification as I implement the library rather than writing it up-front. I will use it to keep my ports of this library (I may also port to Flash and possibly Java) consistent.
Peace, love, and ambition,
(log in to comment)