#113816 - ryumaru - Sun Dec 31, 2006 12:25 am
Hello, im a young pixelartist. me and a friend of mine have been building up ideas, concepts and such for a game project. we are also interested in selling some copies once finished. just a little homebrew project i guess :P
We are looking for a gba programmer to help us with this little project. Neither of us are experienved at all in gba development, but we are committed to the project and would like to see it through. i dont know how good notebooks of character drawings and various folders of sprites will do without somebody pulling everything together :P
My friend could talk alot more of the game, but its an rpg entitled "Enigma". we are really interested in oldschool rpg's( we were just playing final fantasy legends on his gamecube recently :P) and so there would probably be some oldschool roots in it. of course theres a big plot, full of memory conspiracy and world domination, and oh you cant forget the various arrays of enemies, as well as huge endbosses!
you can contact me on aol instant messenger at : chrispykkrem101 and my email is chrispariano@panelmonkey.org
#113847 - Miked0801 - Sun Dec 31, 2006 9:09 am
Awfully ambitious for a first project. RPGs are the hardest type of games to make and NEVER get completed homebrew...
#113873 - tepples - Sun Dec 31, 2006 5:51 pm
Make an RPG that can be played through in less than 1 hour. The episodic approach might be better for homebrew.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#113923 - sgeos - Mon Jan 01, 2007 5:46 am
Time to completion won't save you (although it will help). You'll need a bare minimum feature set to make something completable with a small team. Scrap events. Keep story to a minimum. Keep graphics to a minimum. Keep everything to a minimum. You could probably put extra effort into one category, but not all of them. Not with a small team.
You want about 10 people and 18 months to properly complete an RPG, depending on what you are going for. That is 180 man-months, although time and people scale differently. At least a couple of those 10 people need to have some experience or you'll hit a lot of bumps. At 4 people you are looking at about four years. Keep in mind that some commercial RPGs take longer than that with large teams.
You might want to check out Aveyond. It's not homebrew, but it is independant. I believe it was completed in about a year... nope, 1.5 years (18 months =). I don't know what the team size is. They appeared to use an RPG construction kit to complete the game. They also had an experienced project lead.
Good luck,
-Brendan
#113939 - Peter - Mon Jan 01, 2007 2:07 pm
| Miked0801 wrote: |
| RPGs are the hardest type of games to make and NEVER get completed homebrew... |
I remember Broken Circle which started as a homebrew project afaik. It seems pretty complete now and is even announced to be released in 2007 on GameSpot.
But I totally agree with you and I think it's not only bound to RPG's. Most homebrew games, no matter what genre, get not finished. It's a pity.
#113946 - tepples - Mon Jan 01, 2007 6:25 pm
| Peter wrote: |
| Most homebrew games, no matter what genre, get not finished. It's a pity. |
Even commercial products often don't get "finished" either, even when they are first distributed to the public. Microsoft's Windows XP operating system took two service packs to get to a "finished" state, and there are still security updates. Did you have a specific definition of "finished" in mind?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#113949 - keldon - Mon Jan 01, 2007 7:04 pm
You could consider a project finished when all requirements are met.
#113966 - poslundc - Mon Jan 01, 2007 11:41 pm
| keldon wrote: |
| You could consider a project finished when all requirements are met. |
Except very few projects ever define their requirements correctly.
Dan.
#113967 - sgeos - Mon Jan 01, 2007 11:52 pm
| poslundc wrote: |
| keldon wrote: | | You could consider a project finished when all requirements are met. |
Except very few projects ever define their requirements correctly. |
Correctly? I have a different take on this.
The people with the money define the requirements and retail ready without backlash is usually the only real requirement. Saleable is a better way of putting it; retail isn't how everyone gets to customers. "Marketable" and "likely to generate a profit" are other requirements, but they are poorly defined.
The first XP distribution met the saleable requirement. The service packs prevented backlash from knowledgeable users.
-Brendan
#113970 - poslundc - Tue Jan 02, 2007 12:51 am
| sgeos wrote: |
| poslundc wrote: | | keldon wrote: | | You could consider a project finished when all requirements are met. |
Except very few projects ever define their requirements correctly. |
Correctly? I have a different take on this.
The people with the money define the requirements and retail ready without backlash is usually the only real requirement. Saleable is a better way of putting it; retail isn't how everyone gets to customers. "Marketable" and "likely to generate a profit" are other requirements, but they are poorly defined. |
None of those requirements are at all meaningful to a software engineer. They may as well make the requirements that it be "fun" or "pretty" or "street".
Real requirements are usually objective and at least testable, like most of the Nintendo lot check requirements.
Most companies do not bother to define their requirements in such measurable terms. Those that do, rarely do a complete or correct job of it.
Dan.
#113971 - keldon - Tue Jan 02, 2007 1:02 am
A bug free product is a must have requirement for any chemotherapy software!
#113976 - poslundc - Tue Jan 02, 2007 1:59 am
| keldon wrote: |
| A bug free product is a must have requirement for any chemotherapy software! |
Replace "bug" with "error" and you can say the same for any building or bridge or airplane or nuclear reactor. And if you give the engineer that as a requirement they'll shrug their shoulders and say "gee whiz, thanks for the useful and meaningful specification there".
Dan.
#113981 - keldon - Tue Jan 02, 2007 3:43 am
A bug is never expected, but there are some systems where you are paying for an error free system. A system can be proved to be completely error free - apart from the result of free radicals and tampering ^_^ Verification is used to prove that a 'bad' state can never be reached in life critical systems.
#113982 - sgeos - Tue Jan 02, 2007 3:48 am
| keldon wrote: |
| A bug free product is a must have requirement for any chemotherapy software! |
This is true of anything that is life critical. Bug "free" more or less amounts to putting a bunch of time into testing. Ie, time and money. Mature "bug free" libraries can also be used to avoid reduce the number of bugs. Under normal circumstances, new code has more bugs than tested code. =)
| poslundc wrote: |
| None of those requirements are at all meaningful to a software engineer. They may as well make the requirements that it be "fun" or "pretty" or "street". |
Right. The SE's job is not to market the product (marketing), or come up with fun ideas (game/level designer), or make the product pretty (artist). The SE's job is just to buld a program that runs. Business objectives always outweigh technical objectives. At times this may mean doing something technically goofy for whatever reason. (We have a contract with company X, and they want a crippled product. No, they don't realize it's crippled but fixing it is a deal breaker.)
| poslundc wrote: |
| Real requirements are usually objective and at least testable, like most of the Nintendo lot check requirements. |
Don't you mean real technical requirements? Business requirements are very real even if they exist in a world the SE doesn't care to think about. The test for marketability is actually getting the product in stores and selling it.
That's not to say techical requirements an objectives should be ignored. They are important because they save money in the long run. They make life easier for SEs. They make developement take less time as long as there are no major mid-project changes.
| poslundc wrote: |
| Most companies do not bother to define their requirements in such measurable terms. Those that do, rarely do a complete or correct job of it. |
As far as I can tell, most companies don't know what they want. Figuring that out is your job. Clearly you need to work on your mind reading abilities. =) (I forget where I first read something to that effect, but scary as it is, it seems to be true.)
Honestly, most companies operate in ways that strike me as insane. But it's their (shareholder's) money, not mine, so I guess I don't care if they operate in insane or clueless ways. ...unless they demand that I operate in insane or clueless way without paying me. This I can not deal with.
-Brendan