Game Development Community

A New Development Process - Big Pixel Games

by Bryan Edds · in General Discussion · 02/01/2006 (5:12 am) · 7 replies

I have an idea for a game dev process I call Big Pixel Game Development.

What are Big Pixel Games?

Maybe a catch phrase will get us started -

Big Pixel Games
Big Pixels, Bigger Fun

Big Pixel Games (BPGs) are 2D.
BPGs are games where all art is done as pixel art using a screen resolution of 320x240.
BPGs are games that use just enough animation to bring the game to life.
BPGs have simple and catchy music, and minimal but effective sounds effects.
BPGs are all about FUN gameplay (simplicity can also be a huge virtue).
BPGs are games each developer wants to make.
BPGs are not remakes.
BPGs are game that can be feasably completed by one person in a moderately short amount of time (which is the reasoning behind all of the above).

Now, I have no idea whether BPGs are marketable individually. It's possible if a few teams decided to get together to make a few BPGs then sell them as one game package some money could be made. BPGs are specifically designed so that one person can completely finish an entire game by himself in a reasonable amount of time. I'd like to see a side-scrolling space shooter game, and side-scrolling human shooting game, a platforming game, and maybe a strategy game.

What might be even more interesting is this arrangement - Okay, let's say there are three individuals who each have a good idea for their own game. The thing that motivates a person is seeing their own game idea get done, so they'll work harder for that. But let's say that each person is a specialist in a certain area - 1 specializes in programming, 1 specializes in music and programming, and one specializes in art. Those inviduals could all agree to work on the 3 game ideas simultaneously, with each handling the part that they specialize in for all of the game. So the programmer programs all three games, the artist does art for all three games, and the musician writes music and programs for all three games. They all do what they specialize in, making them most efficient, but they also get to work towards their own game idea, making them most motivated.

This specialization model might work for games bigger than BPGs, but the reason I would only think it proper for a BPG is because of this potential situation -

Imagine if the musician quit the group. The other developers are not screwed, nor do they have to find another musician. Instead they just make their own music for their own individual game, but still collaborate on the remaining two games. Because it's a BPG, any properly skilled indie should be able to wear all the necessary hats for his project. This is the main reasoning behind using pixel-art - anyone can do it well enough with just a small learning curve. BPGs are supposed to be small and simple enough to allow one person to finish them. There is no team more reliable than a one-man team.

So anyways, assuming that such a things worked out somewhat smoothly, the end result would be three games, which would be more marketable as a package than each game by itself (I figure). Then some crazy company could publish the game, and each developer might see some money, even if it's only a very small amount. At least it's something and it looks good on a resume.

Worst case, of course, is that all but one person quits the project. That would be fine because the remaining person just finishes his one game and tries to get it published, or tries to make a couple more to go with it to make his own package, or finds another BPG group to collaborate with.

Heh, well?

#1
02/01/2006 (6:12 am)
Why not just make T2D games?
#2
02/01/2006 (6:16 am)
T2D would be a great thing to use, but I'd hate to limit it to a certain platform. I would use T2D if I were to make a BPG, certainly.
#3
02/01/2006 (1:01 pm)
A lot of the stuff your talking about is already going on with the development processes. I don't know if your going to find skilled personnel to work on a 320x240 low resolution, minimal animation project.

I don't get it?
#4
02/01/2006 (11:55 pm)
Perhaps I need to rethink some of these things...
#5
02/02/2006 (12:07 am)
Okay, I rethought it. Let's scrap the 320x240 resolution constraint, but put emphasis on the team effort.

Let's make it even simpler! Let's say we have 1 programmer who does music and sound well, and 1 artist. Each come up with 1 game idea of a small, reasonable scope that they are individually %100 commited to. That's hurdle #1.

So you have two game ideas from two different people. Together they begin development on both games, and finish them roughly simultaneously. That's hurdle #2.

Then they can publish the games individually, each taking %50 of the profit from each game, or each taking %100 profit from the game they invented. Hurdle #3.

How about that? Does that make a bit more sense?
#6
02/02/2006 (9:00 am)
Goto post 2. :)

Edit: It just sounds wierd. I guess it's like a concurrent development (sharing tech and resources) between projects. This is nothing new at all.

As far as splitting workload and pay. That's all up to contracts / agreements between parties.
#7
02/08/2006 (6:00 pm)
I think this sounds cool. 3 people working on 3 games simultaneously so that everyone pulls their weight and gets their game made.

I'd probably volunteer as a pixel artist for a try at this. Though, I think for this being a first try for this method, this should be freeware games. Open-source would be neat but thats up to the programmer.