RPG collaboration

Well we all laughed at FV's strategy game colloboration Velox et Astrum, but take a look at this. You may have heard of the RPG series known as ``Broken Sword''. And a small team of ~15 people managed to make a sequel to Broken Sword 2.

http://brokensword25.com/news/news.htm

Just think what we can accomplish instead of making poitnless spam threads.

>>160
http://en.wikipedia.org/wiki/ECL_programming_language#Procedures_and_bind-classes

Amazing! All it's missing is GRUNNUR.

>>156
This seems way excessive. No one has time for that shit. We should just do it in Python, since it's extremely easy and probably has the best chance of us actually getting something playable.

Alternatively, we all know what the classic /prog/ troll is, so why not put our money where our mouth is?

Also, is >>88 the gameplay mechanic we are talking about here? Seems like quite a bit of leg work to actually get something playable. Why don't we do a JRPG, like a stripped down version of FF1? Seems by far the easiest. A character sprite that can wander around a simple static dungeon/overworld, with a simple tileset, and tiles simply have passable/impassable state. Random battles in the style of FF1; turn-based, party-style, no effects other than moving health bars. That's it.

This to me is the quickest way to get a playable game, and from there you can enhance it however you like. I am sure I can write a simple tile-based map editor with wxPython in a few hours, and we can let whoever wants to make content go crazy; meanwhile we can add basic elemental spells (no effects needed, just an alternative form of damage), items and chests, scripted events, etc. These things are not difficult; the main thing in a JRPG is always content.

Also, what do you guys think of revision control? I feel like it's cheating if we break anonymity, which would be required to maintain any kind of shared revision control system; I don't think we should use anything other than pastebin and rapidshare. I think all code patches and such should just go on pastebin and be linked and discussed here, and whoever feels like it can rapidshare a tarball every now and then.

I think this project is a good experiment. Thoughts?

>>161
I thought >>160 meant a certain embeddable compiled-to-c implementation of a certain language, but I wouldn't know, for I am not >>160.

>>162
How about completing a formal design document so that I can start with Scheme.

>>162
http://spheredev.org/
http://ika.sourceforge.net/

>>163
Of course I did.

You can't draw anything. Not even low-pixelated elf tits. Why even bother coding?

>>167
One word programmer art thread over

Programmer Art refers to temporary graphics added by the software developer to test functionality. When creating the artwork speed is a priority and aesthetics are secondary, if they are given any consideration at all. In fact, programmer art might be intentionally bad. This draws attention to the fact that the artwork is only a placeholder and should not go into the final product. This practice might also speed its replacement.

Examples include stick figure sprites and fuchsia textures.

Programmer Art may also refer to the art created by an independent or hobbyist developer, where a single person is responsible for all aspects of software/game development. As the creator in this case is typically a developer rather than an artist, the resulting art is functional rather than aesthetic.

FUNCTIONAL ART, TAKE THAT, M.DICKIE

>>167
low-pixelated elf tits
reminded me of Ginormo, did it reach Prague?

>>162
Also, what do you guys think of revision control? I feel like it's cheating if we break anonymity, which would be required to maintain any kind of shared revision control system; I don't think we should use anything other than pastebin and rapidshare. I think all code patches and such should just go on pastebin and be linked and discussed here, and whoever feels like it can rapidshare a tarball every now and then.
This sounds miserable.  Any unnecessary obstacle can kill a project, and a bit of pseudonymity is alright when we want to organize something.

Anyway, here's a thing I did: http://www.assembla.com/spaces/prog/
You can sign up with just an email address (which can be hidden), and the `space' is set to open access so you should be able to add yourself to it and commit code.  I might add a /prog/fighter later.

>>162
Why don't we do a JRPG, like a stripped down version of FF1? Seems by far the easiest. A character sprite that can wander around a simple static dungeon/overworld, with a simple tileset, and tiles simply have passable/impassable state. Random battles in the style of FF1; turn-based, party-style, no effects other than moving health bars. That's it.
Yet another RPGMaker?

These things are not difficult; the main thing in a JRPG is always content.
And that's the problem; we won't be able to come up with a lot of content of good quality.

>>162
the main thing in a JRPG is always content.
The main thing in a JRPG is always the combat system.

Anyway,  I had been thinking about making a RPG myself lately, my ideas are somewhat like this:

* Touhou theme so we can skip backgrounds and everything.  Has a non-zero chance of having music and graphics made for us.
* Traditional overhead view, etc. etc., like Dragon Quest 1.
* Traditional turn-based combat system.  Romancing SaGa concepts can be imported to make the combat fun.

And here are the aces which will make the game fun to play:
* Epick Rogue-like dungeon crawls.
* Epick boss fights.
* Epick Rogue-like amount of loot from enemies (like Angband).

I have not yet figured out how to make such amounts of loot play with a classic JRPG turn-based combat system.

>>173
I wish I knew what any of that meant.

>>172
Yes another RPGMaker because it's easy and, you know, possible for a bunch of disorganized anons to get it working.

A rogue-like is crazy in my opinion. A huge advantage of doing a JRPG is that combat and exploration are completely disjoint, so it lends itself well to splitting up work.

Also, who cares about quality content? Just grab a simple CC tileset and character sprite, and make up a random world map. That's plenty good enough to call a game.

I very much agree with >>173-chan. A rich magic item system is easy and fun to write, and can give even the shittiest game a lot of depth. Let's do that.

Also we still haven't figured out a language yet. Python?

>>176
ONE WORD THE FORCED INDENTATION OF CODE THREAD OVER

Ruby is much more kawaii desu

I'm doing my bits in Go.  You guys can do the rest in Ruby if you want.

Ruby is not portable. Use C.

>>179
If people aren't too stupid to write conformant & portable C then I would like to contribute.

>>179
Use C.
U MENA HASKAL???

Just use the damn Python.  It's your best shot at getting anything (portable, GUI-oriented) off the ground before /prog/ completely forgets about this next week.

>>182
[quote]GUI-oriented[/quote]
Oh gosh. Op, don't you ever listen to anyone from this kind.

>>183
[quote]
Oh gosh. Op, don't you ever listen to anyone from this kind.

>>180
Longtime C coder here, it's not a matter of stupid; it's a matter of time. I know it takes me a lot longer to get things done in C than in Python. There's just no point in doing it in C.

>>185
Yes but some people are clueless and write horribly non-conformant and unportable code just because they have never even thought of it.

>>182
>Python
>best

what the fuck am I reading