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:
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)


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? :)
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?
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. 
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... :(
Well I'm curious to see what you can do with it :) When are you aiming to finish the c++ version?
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.
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.
Sounds moderately interesting also @bitcraft it sounds like you have no love for dwarf fortress
yeah, thats probably true, though i've never played it.  i'm a casual gamer, at best.
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.
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.