Swarm Development: Retrospect and continuation of theoretical discussion

Started by TomatoesInTheHead, Sat 05/11/2011 15:28:48

Previous topic - Next topic

TomatoesInTheHead

I feel like this should be a new thread because the other one is "cluttered" mainly with posts about the actual experiment and might be better used for discussions about a fourth part of the Draculator series now. If you feel otherwise, m0ds, please merge the two threads if that's possible. :)

I also hope that you, Baron, don't mind if I start/continue the discussion here, don't want to appropriate your topic and idea, but I've put some thoughts in this and want to share them before I forget everything. :D


So, we got that experiment done now, and I think we can all agree that the product turned out great, probably much better than most of us expected. Still, from a theoretical point of view, there are several issues in the process to discuss - not meant as criticism of the actual process or anyone who took part of it, since it was always clear that the realization will differ from the idea and that in the end we wanted a finished game and not cancel the game because one of the swarm development criteria was not met.


E.g., there was the idea of "not more than one hour per person", this request was clearly not met. Well, we have no thousand people here to sum up to 1000 man-hours (or whatever the game required), so there had to be more time per person, of course. Still, some contributed much more time to this (and we're all happy about it, of course!), especially Baron, so we have to ask how much it was actually swarm development or if it was in some parts more like a traditional game development process with a bit more discussion and some minor help from others here and there.

I think Baron will have a bit more to say about the particular propositions for the experiment and their respective realization.

Then we have the question: Was it worth it, in terms of efficiency (not in terms of originality of the product - that was definitely worth it)?
Swarm development requires some extra time for polishing and streamlining graphics, Ali's artistic guidelines were not that much enforced than they would probably be if there were only a few graphic artists.
Then there's extra time for discussion and organizational overhead, managing who does what and what is still needed. Time we didn't count that much (since we're all 24/7 in the forum reading and discussing things anyway 8)), but that should count. I don't know what time a game of this length/complexity/quality needs with a traditional game dev process (for a non-supernatural develeoper/team, not Ben304), and we can't really calculate or even estimate what time we all together needed for this one, my guess is that it took in fact longer than it would have the traditional way (which is not bad of course, since it was only an experiment, and we had some times where not much or only some discussion was done).

Still, we saw that graphics are pretty swarmable, backgrounds, sprites, animations and portrait pictures were drawn by many different people. It would have taken much longer if only one or two guys had done all this on this level of quality. There's the question however how much this is parallelizable and how much time we actually saved or could have possibly saved. If I don't know the character sprite (and have no very detailed description), it's hard to draw the portrait picture, if I don't have the background, it might be harder to draw the character sprite to fit in the environment and general mood of the location (?).

Music for different rooms/situations could be swarmable, but in the end all the (used) music was done by Jackpumpkinhead. I'm not much of a musician, so I don't know how hard it's here to diminish a clash of different styles if different people compose music. It's not as easy to streamline musical pieces into one style like it's in the graphics department were you can adjust palettes and "just" push some pixels, correct shading/dithering and so on. But it's probably worth to discuss which analogons there are for composers - like changing instruments and effects, adjusting measures and beats, and/or whatever, I have no clue. But I think it's worth mentioning that we saw that only the composer himself changed his piece after some suggestions, whereas graphics were (sometimes/often?) directly changed by other people (e.g., the first room). There's always an issue that you hesitate to alter other people's work because it might come off as "Your work is not good enough. There, I can do it better."

Sounds: We may have treated this one with a bit few enthusiasm, I mean, there are good sounds in the game, but only at the very end of the production they were gathered and added, though there was a list of needed sounds there for a long(er) time. It's maybe a bit of a boring task to just search sound bits on the hard drive or search for free sources on the web, and in many cases it's not feasible to record the sound by yourself (you know, powering up your big laser cannon just for one shot...), so that may explain the lack of enthusiasm there. Still, we got some good sounds and in no way do I mean to disrespect the work of the people who got them together.

Voice acting: I'm glad we added this, it adds so much to the atmosphere - and humour - of the game. In terms of swarm development though, there's not much that can be changed. It always has to be done near the end of the development, and the voice of one character can't be split between different people, so we have to go the traditional way there. (Or are there any ideas swarming around?)

Coding here was mainly in one hand, or two, but only one at a time, or something. It is hard to maintain the overview of what's happening in the code with many people changing small bits, but with all the open source programs we have a pretty good assurance that it is possible. So that's definitely a point I'd suggest for the next round of the experiment to make more swarmy. It will produce more errors, but it will hopefully also help to find some more and to fix them faster. It will probably need a code repository with SVN or something similar to keep track of and integrate all changes, but there are some free and relatively easy ones available, so that should not be the problem.

Story writing - I'm bad at this (see my game :P). What we did was giving a small premise (bionic vampire marine, or something), then gather some stories and mix them into a big one, extending, changing or leaving out some parts on the fly as the development went on. Is there a way to divide story writing into smaller bits from the beginning? Also, puzzle design, ties into story writing, I don't know anymore how exactly the puzzles came together here.

Dialog writing should be easy to split among many people, though there's also some effort needed to streamline them, in terms of structure (e.g., there should not be one dialog with several dialog options and another one with pretty much no options) and in terms of style, speech, humour, personality. We made the decision not to use any dialogs where Merrick has to talk (i.e. where the player had choices), so that made the thing much easier (but gives us less experimental insight on this part). If I'm not mistaken, dialogs were made only by a few people, right?

That's probably also an issue: Some tasks seem boring to many, like writing, reviewing the writing, proof-reading, GUI design, streamlining/polishing things, sound effect search, coding maybe...



Lastly, about the continuation of the experiment:
In my opinion, we should not start it until next year, after the Bake Sale is done and some labour force and attention is freed there.

Another question there: Do we want to continue the experiment with another Draculator game? Yes, because everyone wants to see it and yes because it's easier to reuse assets and story/character bits, but no, because it will not tell us so much about the swarm development process as a fresh new game could do, where we again have to swarm-develop the story and graphics. So maybe we should split the thing: Develop a Draculator IV game with only slightly altered development process and develop a fresh new swarm game (not at the same time though) with some drastic changes in the development process as a continuation of the experiment.

There I'd suggest trying and failing from the other side of the process: While here, Baron took the usual (?) sequential/hierarchical game development process and split everything apart that can be done in parallel and in single bits (top-down approach), let's just do everything in parallel, whether it makes sense or not, then refining and refining (and also tossing ideas or even assets away during the process) until everything fits together to a whole thing (bottom-up approach), so basically anarchical chaos that evolves to something playable without (much) guidance. Then we'll see what is maybe doable that we didn't even try in this first round, and see what's absolutely impractical.

Ponch

I'm proud to say I took the "no more than one hour per person" thing very seriously.  ;)

And as far as providing sounds go, I had to wait until the animations were in the game before I could try to mix up the right sounds. What if I'd spent hours mixing together the perfect exploding poodle sound, but then the wav doesn't match up to the animated sequence? Why, it would be a tragedy, of course! That's why I wisely waited until the last possible moment.  8)

Baron

It's been a week since release and I've had time to gather my thoughts, so I guess we'll get this postmortem rolling.  I apologize in advance for the wordiness: I've been sick, which means I've been holed up in front of Elizabethan dramas these last few nights  ::).  

On the first count, that of the Swarm process being a revolutionary means of making games more quickly and easily than the traditional route, I hereby pronounce the experiment to be a failure.  It was not long into the experiment that the "one hour contribution" rule was relaxed, and for good reason.  It was an idea with appeal, and for some tasks (simpler backgrounds, simpler animations, finding a couple sounds, etc.) it was even feasible.  But many tasks in game-making simply require more time, and it is not at all practical to spread their conception beyond one mind.  I concede that greater organization may well have facilitated some greater spreading of the work load -more experienced animators drawing keyframes, for example, while others filled in the simpler tweens.  I regret, in retrospect, not setting up a specific forum somewhere so that discussions could be organized by threads instead of the intimidating 38 pages that the swarm thread became.  But even so, training (or corresponding with) to bring a contributor up to speed sufficiently to accomplish only an hour's worth of work, and then to be left with the task of starting again from scratch, was quite simply impractical.  
      The project thus quickly evolved into a voluntary contribution scheme, where you could contribute as much as you wanted on the basis of your enthusiasm for the project.  Let's call this the beginning of an evolution of the Modified Swarm Process (MSP).  This worked surprisingly well, though it was not my initial goal.  Here I have come to two important conclusions, however.  
       Firstly, no matter the number of contributors, the success of the project always depended entirely on the willingness of its organizing conscience to see it through.  I'm not now making that extra lunge for personal glory (whatever Ponch may have you believe): this was from the start the Swarm's game; but from a practical perspective it was Baron's project.  That meant that any organization, direction, and all the little bits that were never picked up by contributors all fell to me to undertake.  If someone's sprites were offset from others, someone had to fix it.  If the sounds didn't quite fit, someone had to edit them.  If no one volunteered an essential animation, someone had to draw it, and very often this someone was me.  I suppose if we'd dragged the project out long enough someone could have been found to do these things, but that would have risked losing momentum (making recruitment harder), and anyway I began to question the rationality of spending half-an-hour recruiting volunteers and explaining to them what to do when I could just do the tiny task myself in a fraction of the time.  The project would probably not have worked out so well if I'd tried to control everything (indeed, I tried my very hardest to merge the ideas and artistic output of all swarm members into a harmonious whole), but at the same time it would certainly have not been finished at all had I not been willing to be the workhorse that actualized it.  I say this to anyone planning on organizing such an endeavour in the future: be always flexible and cooperative, but in the end one person must make the game happen.
      Secondly, it would have been more advantageous to lay down from the outset a decision making process.  Here I must apologize to the many contributors who were frustrated by the lack of clear governance in the enterprise.  As the project unfolded I vacillated between open democracy and autocratic declarations, neither of which worked as well as I might have hoped.  The first rarely gave clear direction, and the second deprived the end product of sound ideas in the interests of “just getting it done”.  In retrospect I would have organized the decision making structure in proportion to the contributions of the swarm members, much as a corporation's board votes in proportion to the shares held by its members.  I think this would have kept the peace better, seemed more just than my say-so, and the end-product would have been stronger for it.  Contributors would be rewarded with greater say in proportion to their efforts, which would in turn motivate them further as they saw the game leaning further in the direction of their mind's eye.  Again, something to consider for next time.

On the second count, that of the Swarm process resulting in a unique game that no one developer could conceive of and implement on their own, I hereby pronounce the experiment to be a success.  I'm not a bad game developer, but I could never have come up with such a solid plot and great puzzles on my own, nor could I have drawn such fantastic art or animations, let alone voiced such personality into such well-developed characters (considering their screen time, that is).  I couldn't have even directed talented people to execute such ideas if I had had them: the best instincts of the contributors trumped my imagination.  Organized properly, I think the Modified Swarm Process (MSP) has great potential, as long as the organizer isn't too set on what the project should look like in the end.  (That would be a case where the more traditional approach would be more appropriate).  When many talented people collaborate spontaneously, the best game ideas tend to float to the top.
     This leads me to my final point, the unintended but very much welcomed camaraderie that developed among the collaborators.  Originally I was pretty sure I could scare up several dozen AGSers to contribute an hour each to the experiment, and then they would promptly forget about it, much as university students will participate in a psych or economics experiment for an hour and then forget it ever happened.  This was rare, however: even when the project was in its infancy, and there was no way to tell where it was going, or even if it was going anywhere at all, there quickly developed in the contributors a strong attachment to the project and a happy bond between them.  The experience of contribution towards something bigger than one person made the community stronger, and I am very happy to have been a part of that.  The game may well have turned out well, but it was the process -the journey -that truly made it worth while.
     I thank you all for your time and consideration of my thoughts and look forward to discussing the finer points of Swarming below.  

kconan

  It would be great, but its not realistic to expect a thousand people to send in their contributions on-time all of which fit together like a perfect puzzle.  I think no matter what is proposed, simply due to the sheer number of people involved, it will always end up being something like a Byte of the Draculator II style of development in that a project manager will have to aggressively pursue swarmites for contributions and fill in the blanks himself/herself.  This isn't a bad thing if you have a willing Baron, but I think anyone less than him would throw their hands up in frustration and go back to their own project.  To be honest I'm surprised that the game turned out so awesome and within a good timeframe even with 20-some (?) swarmers.

Anian

Hmm, whatever happens in the future, I think the best thing for such a project is strong leadership, as in art direction gets a lot from an example of background, invetory item and character design (at least sketches). Music could have like instruments limitations or theme examples to keep things directed.
Even though creativity is always a plus, inconsistency kind of kills the mood for me (not that it happened here, just in general).

What little I gave, it still was nice to be included in this project, would be nice if something like it came along annually, maybe a topic where the story would be figured out and polished. Really nice idea, Baron and co.
I don't want the world, I just want your half

RickJ

When I first saw this idea I thought you guys were out of your nut and didn't think this would work out at all.  I'm happy to say my first impression couldn't have been more wrong.  By any reasonable measure the experiment has succeeded.   

TITH and Baron both point out that some of the initial assumptions (i.e. 1hr/dev) were not realistic and that lessons were learned along the way.  IMHO, this doesn't taint the success of the project at all. So here's a big congratulations from an initial skeptic for a job well done.
 
With regard to future experiments you may want to consider adding  "pipe-lining" in addition to parallelism to the workflow organization.  I haven't followed along and so apologize if this technique was already utilized or considered.

Way back in the ez-board days someone (whom I can't remember) gave the advice to get the game world working first and then layer the plot elements of the game on top of that.  To produce a room for example there would be two steps:

Step-1:
- Add areas and regions to the background art.
- Add objects and animations
- Add script to make game world functional

Step-2
- Add dialog implement the game logic & plot
- Add script to implement the game logic & plot
- Add any other to implement the game logic & plot

After Step-1 PC would be able to walk around the room, operate doors or interact with other game world objects and characters. Story, puzzles, sound, music, etc could come later in the process and could all be done by different people.

Coding:
Develop a programming style/pattern very early in the process and ask others to follow it.  Develop modules and/or global functions to do all the heavy lifting.

Characters:
Use a pixel scaling to draw all characters.  For example if the game's character scaling is 20 px/ft than 6ft tall character would have a height of 120px.  In this way any character could appear in any room on any walkable area an would be scaled to the correct size.

Hope my suggestions are of some use. Cheers
     


Ali

I've was too busy to help out on the tail end of the project, and still haven't had time to play the game. (As soon as I finish the new Blackwell...)

Nevertheless, I wanted to add a thought. I wonder if designing character/plot by committee was one of the stumbling blocks.

Perhaps someone should have been named story director, a counterpart of art director. They could start by presenting the swarm with a number of plots and/or lead characters, which could be voted on. The art director could then produce template background and a lead sprite / template sprite. That way the character would dictate the sprite rather than vice versa.

The story director could then break the plot down into acts, and different script writers, puzzle writers and coders working each act. Depending on the scale of the game, each act could be as small as one room.

In essence Baron did this, but it would have been better if it had been formalised. We could have avoided the is-he-a-tough-marine-or-is-he-a-camp-vampire debate which threatened to scupper the game for a while.

Also, perhaps instead of 1 hour per person, it ought to be up to 24 hours?

Snarky

Turning out a completed game is a big achievement in itself, not just for a swarm development process, but for any team of game developers.

When it comes to the quality of the result, I think that is due to the individual talents of the contributors, rather than to how the project was organized. Maybe you could say that swarming was successful at recruiting, selecting and motivating talented contributors. On the other hand, I do think some of the weaknesses of the game are due to limitations of the process. But I find it extraordinary that the game feels as cohesive as it does.

Baron's role was clearly key to the project working out. Having a motivated and motivating team lead, as well as someone with the skills and patience to handle all the little left-over tasks (and set deadlines!) is probably the only way something like this could ever work out.

I also think it was important to have some of the key decisions nailed down early. "Bionic vampire escaping from mad scientist's lab" is simple and gives all the contributors common ground to work from, while still leaving room for individual creativity.* I'm not sure I agree with Ali that it would have been better with a designated story director, or offering the swarm as a whole different story options to choose from. The way the story came together seemed to work quite well; I think improvements on that front should focus more on how to solicit and incorporate revisions and later additions, so it could be improved further along in the process.

Like Baron said, one of the big challenges is how to make design decisions, and particularly the decision to not use certain a contribution (mutually exclusive design alternatives, elements that don't fit in, or contributions that aren't up to the expected level of quality). It's definitely demotivating if your work gets turned down, but on the other hand it's demotivating to the team as a whole if there's no quality control, consistency or sanity checking. I don't really have any good proposals for how to resolve this. Maybe the project driver should see his role in these situations as that of a judge offering instructions to a jury: putting things to a vote but explaining how they should make their choice. (Only big decisions should be voted on; the people putting the game together should make smaller design decisions on their own.)

The discussion definitely became too daunting pretty soon. It was also tough because TODO lists and other important status info was buried deep into the thread. I'm not sure a whole board is called for (since then it can too easily die from lack of activity), maybe just locking the thread and starting a new one now and then, with summaries of (or links to) the important information in each new thread-starter post.

I would also agree with RickJ that it would be good to have a "playable" build as soon as possible in the process, even if it's just Roger walking around the first couple of backgrounds. It's much easier to relate to something you can experience. (Another way to get that across could be video playthroughs, so the project lead could quickly explain what's supposed to happen at certain points in the game before it's actually implemented.) And the source code should be open, even if it's ultimately one person who's responsible for putting together the builds.

I would hope that being able to play the game earlier would also give more time for revising story and puzzles. I love a lot of the puzzle ideas (eXit! Carrot skin!) and the dialog writing, but I think the overall story and the composition of the puzzles could have been stronger if there'd been a better chance to change things after seeing how they played. Like I mentioned above, I don't think this is a matter of coming up with a better plot in the first place, but being able to get inspired by details that appear during development (graphics, music, animation, voice acting, coding), and thinking of ways to tie together those elements in new and other ways.


* One of the problems, I think, with the earlier SPHINX project attempt create a game by mass collaboration was that we started by focusing on world-building rather than defining the situations that would appear in the game. Of course, there was a reason for that; it was envisioned that small teams would create individual episodes set in the same world, but it left too much open for potential contributors, so they didn't have the confidence that what they would do would fit in.

Hudders

The problem with limiting everyone to an hour is that you very quickly end up with an incomplete game and an exhausted supply of contributors.

Quote from: Ali on Sun 06/11/2011 18:41:05
In essence Baron did this, but it would have been better if it had been formalised. We could have avoided the is-he-a-tough-marine-or-is-he-a-camp-vampire debate which threatened to scupper the game for a while.

You act like that debate was a bad thing. I think the game is better off for it having happened.

Ali

I have now played the game, and it was a lot of fun!

In retrospect, I wish I'd been a bit more forceful as art director. I was reluctant to be too pushy because it was contrary to the spirit of the swarm.

I do think there could have been better consistency between different sprites and between characters and backdrops. I also wish I'd been more ruthless about not allowing dithering. It may be a niggle but it really weakens the visual continuity for me.

I'm obviously in a minority in thinking that a pinch less democracy would have helped the coherence of the game in narrative terms too. I do think that if the swarm becomes a regular event that fundamental disagreements could start derailing the project if there aren't project leaders / directors able to make decisions.

I didn't mean to suggest that the swarm shouldn't come up with the ideas for the game, only that the contributions should be collected and edited by a story director.  Again, this is what Baron did, but he could have been empowered by the swarm to make bolder editorial decisions to maintain stylistic consistency.

I hope I don't sound negative! I think it was a great project, and an interesting experiment.

Baron

Well lots of people have been pestering me so here it is: The Draculator Source Code

A few notes:

-yes, there are many instances of me not following best practices.  I've tried to identify this in my comments
-comments are as comprehensive as possible, but PM me if you have any further questions
-In the interests of version control, if you feel compelled to upload your own director's cut please make this absolutely clear on the title page (i.e. Byte of the Draculator: Baron's Director's Cut) so that I'm not being asked to fix new bugs, etc.

Quote from: Snarky on Sun 06/11/2011 23:22:06

I would hope that being able to play the game earlier would also give more time for revising story and puzzles. I love a lot of the puzzle ideas (eXit! Carrot skin!) and the dialog writing, but I think the overall story and the composition of the puzzles could have been stronger if there'd been a better chance to change things after seeing how they played. Like I mentioned above, I don't think this is a matter of coming up with a better plot in the first place, but being able to get inspired by details that appear during development (graphics, music, animation, voice acting, coding), and thinking of ways to tie together those elements in new and other ways.

I like this idea, but the timeline for idea contributions would have to be strictly controlled: one of the most frustrating things for me was the feature creep of the swarm project.  Every time we were getting close to the finish line, someone would come up with something new.  Yes, the game is better for these contributions, but it was very frustrating saying the game would be ready by such-and-such a time (and it would have been!), but then having to constantly postpone releases due to last-minute extras.

Quote from: Ali on Tue 08/11/2011 00:06:51
I didn't mean to suggest that the swarm shouldn't come up with the ideas for the game, only that the contributions should be collected and edited by a story director.  Again, this is what Baron did, but he could have been empowered by the swarm to make bolder editorial decisions to maintain stylistic consistency.

....just like the Roman senate voting dictatorial powers for a finite period! 

   Interesting discussion so far.  I would be most interested to see how another swarm project could build on the lessons learned this time around.  I'm WAAAAAY too burnt out at the moment to consider leading it myself, but I'd definitely be a contributor.

Ghost

On a personal note, what I really liked about the swarming was the easy-come-easy-go approach. It was true teamwork were a task WOULD be done.

I did contribute just a few things, and all of them were really simple. And I always felt that they were a contribution with no strings attached- if someone did a better job, I had wasted little time. If the contribution was taken aboard, well, I had added my bit. That felt really good, it was extremely easy to invest a little time. One hour, a little more a little less, who cares?

The only other time I (sucessfully) was part of a team was ColourWise, were my job was bigger and I was the only one "able" to do it. I had a script that added up to roughly a dozen pages of cartoon cutscenes, together with character design. I had the script and I had "outline dialog", and roughly two months time to get things done. I still remember that I did it all in two very, very long night-shifts. It still was fun but instantly added a lot of responsibility, and I think I am not the only one who goes stiff when threatened with a deadline (and not in the good way).

So the swarming as a whole- in my eye- really helps to build a "friendly working atmosphere". One has the idea, the next a few frames worth of animation, and then someone will tidy it all up? That's really neat.

Baron

Quote from: Ghost on Sun 13/11/2011 01:49:07
On a personal note, what I really liked about the swarming was the easy-come-easy-go approach.

So the swarming as a whole- in my eye- really helps to build a "friendly working atmosphere".

.....But how can we combine easy-come-easy-go with dictatorial powers?!?  Seriously, I'm glad people felt laid back about the whole process.  Game making is supposed to be fun, right?

To help with the post-mordem discussions I've uploaded a Developer's Playthrough which attempts to document how the project was assembled.  I'm sure that I've left out all kinds of contributors in my ramblings, but the gist of the swarming process is there.

EDIT: Part 2

EDIT: Part 3

Wyz

It took me a while to read this entire thread pfew :D

Let me begin with saying that the original idea would have failed because of the lack of direction so Baron did was needed to keep this project alive and much gratitude for that. It was an experiment and in it hard to predict where it would have ended. Well it has brought a great game but also valuable test results regarding swarming.
The general lesson is what he already pointed out: when working with a swarm a lot of tasks fall through the cracks but they still need to be done; the project leader will wind up doing ninety percent of them.

Some of you pointed out the project was too much or too little a democratic process. I'd say it was in the green; sometimes there was a debate, sometimes it was decided on by Baron. Projects like this are an organic process, if you try to regulate it by rules and committees that will not work if you'd ask me.
The same goes for voting. The one time there was a vote was also the one time I was a bit disappointed. I guess when voting noone will really be happy, while when there is an open discussion a middle ground will likely be found (that's called 'polderen' in the Netherlands ;D).

Although I've been true to the one hour limitation it was a silly thing to do really in retrospect. The original conditions were put quite strong so they were bound to be broken. I think Ghost has a point with easy-come-easy-go. The limit at first gave people the no strings attached feeling and there were no boundaries for them to join, even if it was giving their opinion. Heck some people that initially just wanted to be supportive started making assets for the game even though they never animated or drew before. That is awesome!

The thing that worries me the most for collaborative projects is motivation. The approach this project used worked really well. The only problem is it would drain the project leader beyond anything; future projects need a way to relief the stress in a way.
Also the topic became a mess but the fact it was always in the general discussion forum would draw new people and keep the people who already participated interested. Though I'd go for what Snarky said: restart the topic once in a while with milestone events.
This post is already becoming quite long so I'll post one of the ideas I have for the first problem tomorrow.

Btw, great job on the play-through video Baron, I loved it.  :D Though is it me or is the sound out of sync?
Life is like an adventure without the pixel hunts.

Baron

Quote from: Wyz on Mon 14/11/2011 02:17:09

Btw, great job on the play-through video Baron, I loved it.  :D Though is it me or is the sound out of sync?

Yeah, the sound starts off pretty close to synchronized, then gets progressively more and more off by the end of the clips.  In retrospect I should have "cut" the video more often so that the offset would never get so severe.  Yet another thing to know for next time.....

SMF spam blocked by CleanTalk