Well, since this is your thread, i will accept your rejection by not continueing to participate in the thread. Though, i would like to remark that your rating regarding "condescending" by itself is only morally relevant, but *by itself alone* logically irrelevant (it does i.e. not say anything about truthfulness). Also, i'd like to thank Alec for some of his descriptions, because those already spawned an interesting and practically useful discussion between me and someone else.

Have a nice day.

I don't know what I'm doing 100%. And I'm not going to let some almighty preconceived plan or previous iteration get in the way of both the learning and making the game way better. That's what they mean when they say "Kill your darlings".

Try doing that with a large project.

Info: There is something beyond "total control" and "total chaos"... has something to do with "guidance" i think.

We just had very basic outlines that we kept changing. (we changed direction a few times) Basically the world grew from a basic outline (we'd map out the levels as just empty spaces to start, to see if they were about the right size) and then adding more details and making connections.

This is interesting, because it sounds more like an artist approach (first doing the overall sketches and outlines of the image - literarily - and then adding detail).

For Aquaria we just jumped in and started making what we thought would be "the game" but it turned out that it was just a prototype.

So now I would lean towards doing more prototyping up front... but I'm still wary of having a completely separate prototyping phase for some reason. Maybe because it can make things too simplified or "sterile"? I prefer games that feel more organic...

Hmm, perhaps for early prototypes a "testbed sandbox" would work? I mean something like first creating just a small area to first test things small scale - and then after one got an idea how to approach the rest, extrapolating that stuff to a full gameworld? That wouldn't limit you to "sterile" testing of unconnected "atoms". Downside of course is that this way, you cannot test mechanics which span larger areas, or traveling between areas.

I also am really interested in the way that visuals, audio and interaction collide and mix together - so I feel weird doing prototypes with just boxes and no atmosphere. I don't think games are, at their core, just about collision shapes moving around in different ways.

Definatelly, yes. However, a full simulation would mean spending a lot of effort on content, at a time, when it is very probable that things get discarded often, no? The compromise which i use, is that i dont look at such "placeholders" as what they are, but just use them as cues to imagine the rest ("assisted imagination" or smth like that ;- ). I guess this also depends on personal thoughtstyle - for example, i rarely think purely "abstractly", even if from my posts, it may seem that way - i typically also imagine what i think (not just entities, but especially how things are connected).

To me, it seems that simplistic early prototypes are okay, if: 1. You do not just see "boxes" but in your head add the rest / 2. It isn't black/white "Early prototype -> Full Implementation" but instead one or more steps in-between, so that a transition can happen. Or do you think that there is an alternative to simplistic early prototypes, which doesn't require a lot of effort?

I think generally its good to have a 'living' outline - one that is loose and open to evolving.

Not every detail has to be laid out, because its likely to not work or end up changing. (as long as you can visualize how it will work in your head)

The projects I've worked on that have become successes are the ones with the least design documentation.

I'm curious how you applied that style to Aquaria? I mean, the gameworld is huge and the gameplay isn't "basic". How did you do with just a small design spec and flexible overall outline? I mean this question seriously - i'm interested in how you did this that way.

In terms of collaboration, I like leaving things open enough so that the partner can add their own creativity into the mix. In my current case I have a project that is very personally important to me, and I have a very clear idea of how I want it to feel - but it could be put across in a number of different visual styles that would all work well. So I'm open to considering a lot of different options.

Agreed. Details like specific art-style, items, control, etc. shouldn't be nailed in place early on. The overall concenpt, "feel" and "message" is what may be determined beforehand - how in detail that message is communicated, can be adjusted en-route.

Hmm, bonus question: What are your preferences regarding prototyping? Do you tend to prototype all along the way, or prefer to pull as much of the prototyping as possible to the beginning? (I prefer the second approach, because near the beginning, sweeping changes to the concept are easy to do).

---

Maybe some practical examples are more useful than discussing on a purely abstract level. About a year ago, i for fun started to think how i'd like to do a paradroid successor. I never really had the intention to collaborate with others for doing it, because with a new programming language, web community, bookseries and an IF backburner project in the pipeline, i'd overstress my abilities if i'd start another project. Still, i conceptually sketched away anyways because this specific "what-if" scenario was fun to me.

Anyways, i quite early decided, that i'd want to keep the core gameplay and arcade-feel of paradroid 90, but would like to escalate what one does in paradroid more (being a covert intruder in a droid-collective, and basically working like a parasite). I especially wanted to make the player feel being that much more (atmosphere, immersion). So i scetched basic gameplay elements, like that the other droids would be on the lookout for the player (they'd regularily scan each other, like police checking peoples ID), that sensor ranges should matter (but not too complicated), that the player could go into "sleep mode" in which he'd be unprobable to be detected (with the visuals and sounds reienforcing the impression of sleeping, yet being in enemy territory), and borrowing some ideas from other games (security alarms (SS2), searching for datafragments (Impossible Mission), station self-destruct countdown (Alien Breed) and there being droid factories which's production one can reduce by sabotaging generators (Raid On Bungeling Bay)).

So in total, a generic idea about the "feel" of the game, and a handful of ideas how to create that feel... but without details being nailed down. Thats how i tend to do first overall concept drafts - and then some quick'n dirty prototypes (if i'd do the paradroid thing with others, it would be a simple one-screen tiled map, with placeholder graphics and some basic gameplay concepts in place to get a first impression).

Thats why its important to have a clear idea about the path forward in the first place, instead of having problematic surprises later. That way, such "incompabilities" can be avoided from the beginning on.

Ha, this seems a lot more naive to me, actually...

I understand what you're saying, but I've never been able to map out a game's development like that at the outset, and my experience coupled with stories I've read and heard from other people has led me to believe that most games change drastically at least a few times during production.  Also, it's impossible to know how a team is going to feel several months into development (probably a lot more tired and cranky!).  I think the "active conflicts" are inevitable and unavoidable, and you'll rarely have the luxury to simply not collaborate on an aspect of the game where you differ.

What you are pointing out was not covered by what you quoted. Of course i was not talking about preplaning every single minor detail. However, overall things as well as the mindset-stuff is something which one can know beforehand, if one has already a mostly complete "concept", and is "now" simply looking for colaborateurs to put the finishing touches on the concept, and then implement it. If one isn't doing ones own first larger project, one does already have a few "tried and tested" mates with which one can go through most of the project concept phase... so that when hiring, the overall path as well as mindsets are already clear. What then can go wrong is:

- the concept overally turns out to be flawed. Bummer. Start from zero.
- Minor disagreements in concept details appear. Those can usually be fixed via compromises, without hurting the project as a whole too much.
- Disagreements in teamwork during implementation happen. Those typically aren't disagreements about the project, but disagreements about the style how one works and interacts with others.
- Persons turn out to have overestimated their abilities. Well, in that case, make minor modifications to the team lineup while the project is already underway. Thats something which needs to be expected.

Did i miss anything? Well, those are the situations i have experienced in the past with non-game related software projects. In all those cases, the above strategy didn't fail me: plan the overall path beforehand with existing teammates. Recruit, pay attention to mindsets, play with open cards from the beginning on, finalize concept, start implementing, communicate, if necessary replace teammembers en-route. It may very well be that this approach has flaws which i dont know yet, because i haven't encountered them yet.

P.S.: One important detail may be, that i do have the luxury to exclusively work with people which have matching mindsets. I understand that for many people, this isn't possible - however, if the team doesn't coherently fit together already at the beginning, then yes, of course conflicts will follow.

If you'd remove the "manually controlling a ship"-aspect, then the smugglers series would also match (its basically elite on steroids, minus space-craft control (you never get to see a "cockpit-view" - it all exclusively happens on map-screens, etc).

Also, there was that "Flatspace" series... it too basically was elite, but with one thing removed: in this case, that was the 3D-view (you control your ship only like a rotating 2D top-down shooter).

-----

In general, you will have no issues finding games similiar to the original Elite. If however you search for something like frontier/FFE, you hitcount will be zero.

- *sigh* post can be deleted - the cookie system again entered my post in the wrong thread, because it cannot handle tabbed browsing -

I'm not so sure if such an angle would have worked well, because alien breed had lots of small corridors... so to clearly see whats going on, the camera needs to be top-down. Or did you mean something else?

People using decompilers and memory editors aren't a problem IMO. Cracking in that aspect only becomes an issue, when easy to use "trainers" appear which anyone can use. That however could be easily bypassed, if you are able to slightly modify the code once per month or so. At that point, waiting and hunting for the next updated trainer-app is more annoying than just paying the microtransaction. So, effortless cracking IMO is a problem, difficult cracking tho isn't.

In case you're using firefox, that "crashing" probably was related to........ advertisers. Why? Because i'm using firefox with an adblocker, and haven't experienced crashes on that site.

Hmmmmmmm, about the whole micropayment thing.... We have arcades where you pay per play. We have full games which you pay completely for one time. We have small low-effort games for a low one-time price - but on the other thread, people are complaining that it locks out larger projects. On the other hand, it should be obvious that micropayment is an interesting route. Has anyone yet tried a "pay to unlock episode" model via micropayment? That way, a player would basically pay depending on how far he gets in the game.

@aeiowu:

I think we're misunderstanding each other a bit, because we understand "conflict" a bit different. What you mean with conflict, is what i'd call an "active conflict". When stuff gets ugly, then thats just the surfacing of the conflict... the discrepancy often was there already beforehand, but just wasn't that relevant until that point. So, we dont actually disagree that much with each other - when you'd say "lack of communication spawns conflicts", i'd say "lack of communication turns passive conflicts into active ones" (and perhaps even amplifies them, if someone gets more and more frustrated for staying silent instead of talking about it openly).

Upgrade Complete - Reloaded

["Every conflict is the result of a breakdown in communication."]

The best thing you can do? Date. Jam with people. Have casual development (read sex) all over the place. Learn from bad experiences, what you liked, what you didn't. But once you're in it to win it, COMMUNICATE! I bet if you bought a book on marriage counseling you'd see the same sappy advice: "Every conflict is the result of a breakdown in communication." Ok, i'm done.

Thats a rather naive and inefficient advice - then again, getting married may be a bad advice in the first place :-P

Conflicts of interest are normal, unless you have robots working on something (and even then, conflicts may arise , because people have different intentions. While its true that open and clear communication is important, and that its the only way to resolve conflicts, some conflicts cannot be resolved without someone doing something which he/she doesnt really want (thus, the conflict isn't resolved, but just "subdued"). Such unresolvable conflicts can only be ended by both parties not colaborating in that aspect. To put it simple: Some stuff just doesn't work together, no matter how hard you try.

Thats why its important to have a clear idea about the path forward in the first place, instead of having problematic surprises later. That way, such "incompabilities" can be avoided from the beginning on.

Most importantly: Mindsets matter! Small ability deficits can fixed by learning, new situations can be adapted to - but different mindsets stick with you for a long time.

O.O

Now thats creative ;-)

Heh, you really can't get over the Ion Storm debacle, hmm? Though, i have to agree that the story is interesting, and that it contains a lot of stuff to learn from.

With the discussion about the broken pay-for-copying model going on everywhere, there's one thing i noticed: as typical for humans, discussions tend to focus on figuring out "the one and only true solution". Others argue that every for every case, a diffierent solution may be "the one and only true one". You know, the usual absolutist and egalist camps.

What typically isn't discussed much, is that in many cases a combination of methods may work out quite well. In another thread, some one mentioned the aspect of building up a "personal fanbase". Well, one approach which may work for some would go like this: first release a few low-effort but interesting games on a "donate if you like it"-model, build up a community, etc. Then after you got people who trust your abilities, think about a slightly larger project, and propose a "funding-model" (fans fund you for creating that slightly larger project, not for copying it). Thats just one example. There are probably quite a few other combinations which may work well if the circumstances are right.

Sorry to say it, but sadly, there is nothing like that (except of the already linked remake). Not even the official successors were able to keep the atmosphere and gameplay of the original. All of the remotely similiar games added annoying 3d graphics (and yep, Team17 is also going to do that for the upcoming new Alien Breed game), rotation and other stuff.

There is something which is quite cheap to manufacture, and easy to integrate into ANY game concept... though, it isn't directly a controller, but just a different display-method.... its called "Head Tracking". If when you hear the words "Head Tracking" have a picture in your head of using a device as a controller for changing your view, then i propose to really take a look at head-tracking in action... the attractivity of it isn't the controller-aspect, but the immersion aspect:

Since you mentioned 2 player games:

(You probably know quite a few of those already, but maybe there are some you missed out so far)

- All "Spy vs. Spy" games - though, be warned... this will lead to quite a few insults at each other

- Archon

- Realm Of Impossibility

- Scorched Earth

- Ballblazer

- Speedball 2

- Oil Imperium

- If you have two laptops and can get a DOS-LAN to work, definatelly try Magic Carpet

- Das Uberleben (not actually old, but multiplayer retro regardless)

- Wizards Of Wor

I think that "normal" language is good at explaining complex things, and that in encourages people to explain things at the complexity at which the language performs best - >>>regardless of the simplicity/complexity of what one is trying to communicate<<<. So, simple things become complicated and very complex things get dumbed down.

That isn't necessarily a general "flaw" of normal languages. Its just that there are things in which it performs well, and things in which it performs not so well. But typically, this isn't taken into account when communicating - its just assumed for granted, that if you want to communicate something, you do it with spoken/written language - it is "normal".

Take for example the message "i am happy". You can explain this with a simple gesture quickly completely and accurately... but what if you do it via spoken language?

"I am happy"

Look at that sentence. By normal language standards, it is a very short and simple sentence - and yet, compared to a simple gesture, it is complex. And it doesn't even tell you much about "how" that person feels happy - you could add more explanation... i am so happy that blah blah blah blah blah because blah blah blah. Its like blah blah blah blah..... a giant amount of information, with an incredibly low signal to noise ratio, compared to simply expressing it with a gesture.

My point now is: Often, things which are assumed to be complicated, actually are based on very simple emotions and intentions. Sure, you can build a lot of bloatage on top of it, but when stuff excalates, you can quite clearly see that the simple base is what is most important. Sure, that doesn't apply to everything.... but it applies more often than one would think.

And there is something else: Take any game story. Remove all the clutter and bloat which adds complexity without really adding important meaning. What are you left with? How many things are left for which you need an "advanced language" to express it? You will probably quickly stumble over a few things, of which you aren't immediatelly sure how to express it without words. But think a bit more about those cases - do they really require language, or is it just that to express simple things simple, you need to think a lot? People assume that simple equals easy. This in most cases is untrue. Explaining stuff simple is more difficult, than expressing it complicated. Any idiot can find a complicated solution to a problem. Thats easy. Coming up with a simple solution, is what takes quite a bit of thought.

So, my point is: The story sans bloat is in most games actually quite simple, but artificially blown up. That doesn't necessarily mean, that one cannot write more complex stories. It just often isn't done in games. Take for example a really deep and well written book. You cannot express that with gestures, images, sounds alone. THIS is the kind of stuff, which IMO really requires a advanced communication method.