A General Idea - The Concept of the "Code Painting"

Akake on 2011/09/06 18:10 of LandFish: Foxer Delta

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)

This lends itself, again, to very simple games that may not benefit from a menu state. Also, because the play state becomes idle when the game is not being played (unless the game works better running constantly, such as some "indirect interaction" games), the game can be picked up and played, then put down for a while.

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,

--- Akake

(log in to comment)

Comments

Cosmologicon on 2011/09/06 19:29:

Cool, thanks for posting this!

I admit I don't really "get" the concept of a code painting that you're explaining here. You have a set of features a code painting has (or doesn't have), but I don't see any sort of coherent unifying theme behind them. Also, none of the features seems really distinctive (except for the exact key bindings of the menus). I would say that many pyweek and casual games fit most or all of your other criteria.

I guess it's not clear to me what this library of yours is going to do that pygame and pyglet don't already do. You want to give some more details about it? :)

Akake on 2011/09/06 19:49:

It provides boilerplate for things like collision detection and a simple gui system. It also provides a graphics system on top of the underlying library. It provides a ready-made world structure and entity classes.

The unifying concept of it is supposed to be the overall simplicity of the interface. The lack of a distinct menu state means that the game can be played immediately when it is loaded. I admit, the name is probably not that great, and I might think of a new one.

I admit, I'm kind of discouraged now... :( Is this a bad idea?

Mat on 2011/09/07 19:07:

I don't think its a bad idea, but you need to narrow the scope a bit, otherwise the library won't be able offer much more than pygame or pyglet. I would consider using it if it made it ridiculously easy to make a certain type of game, like top-down tile based games or something.

The only thing really limiting the gameplay atm is the requirement for the game to revert to an idle state when you don't do anything, which could cover so many different types of games, and the interface would be different depending on which type you want to make. 

Akake on 2011/09/07 20:08:

The point isn't to make a specific genre of game, though. The point is to have this format of single-state with drop-down menus. It will provide classes for top-down and side-scrolling, tile-based and not, and probably other things.

I'm not sure how to make it more clear, but it'll make sense when I have one to show you folks.

It's not about the library necessarily (though the library is part of it) but instead it's about the way the game is presented. I know that probably doesn't make sense right now, but it will when I have one to demonstrate the concept.

I'm sorry for making it sound like the library was the focus. The library isn't supposed to be the focus. The format of presentation is supposed to be the focus.

I really do want to make that clear. I'm not sure I'm communicating that part well, though... :(

Mat on 2011/09/07 20:46:

Well I'm curious to see what you can do with it :) When are you aiming to finish the c++ version?

Akake on 2011/09/08 15:15:

The C++ version of the library will probably take a while, but I'm hoping to have my proof-of-concept complete within a couple weeks of the end of PyWeek. The library being complete will take a long time, though, because of how much I want to include.

PyWeek is really going to be proof of concept for the format, though. I'm excited about that.

bitcraft on 2011/09/08 23:19:

what i got out of your post is that you want to design games to be more simple, more casual.  the fact that the game pauses itself when losing focus means that you will not be penalized while you multitask, and the simple menu structure means that users won't have to navigate a "maze" of menus.  in practice though, i personally don't like drop down menus because it either requires a mouse to manipulate, or requires ambiguous control using the keyboard.

i am 100% behind you in simplifying games.  it can be annoying when playing new games, only to have to relearn just how to navigate the menus and learn the buttons, on top of learning the concepts of the game itself.

it will be interesting to see what you come up with.

Hugoagogo on 2011/09/09 04:18:

Sounds moderately interesting also @bitcraft it sounds like you have no love for dwarf fortress

bitcraft on 2011/09/09 04:37:

yeah, thats probably true, though i've never played it.  i'm a casual gamer, at best.

richard on 2011/09/09 04:42:

Sorry Hugo, but I consider myself a pretty serious gamer and Dwarf Fortress is too much for me. It's just too damned opaque and the user interface is truly horrible. Only the very devoted players can really get into it.

Hugoagogo on 2011/09/09 07:40:

Opaque? also after a few hours of playing and going WTF you just remember the controls and it all makes an odd kind of efficient sense. And the amazing levels of fortress defenses that can be constructed compared to the majority of games where one just spams turrets everywhere.