Rapid vs. lazy prototyping

Anything related to dev. & that doesn't fit in below categories.
Post Reply
User avatar
Q_x
developer
Posts:334
Joined:Thu Sep 23, 2010 15:10
Rapid vs. lazy prototyping

Post by Q_x » Mon Apr 16, 2012 13:01

I think we have some serious problem: people, including me, are hanging around, waiting for things to happen. Or just trolling.
Now, I think (and all statements below is what I think, don't take it seriously) it might be a good time to try to introduce some lazy strategies. Lazy in this case means slow, but also - at least I hope so - enjoyable with little energy committed.

I can nail down the progress problem really precisely, but I guess you can do it as well. My conclusion is we need to take care for proper prototyping - for now, this means testing what we have already and throwing some ideas into our little bag. There are rules waiting to be tested, abilities, cards, single and multifaction decs, faction v. same faction, faction v. other faction and faction v. multifaction games as well - and from all of this, only faction v. other faction is hard to test, because of RB is not yet mature enough in terms of card count.

I used to be focused on rapid prototyping, but in case of online fun there is no existing way to do that - even if I could again refer to my old utopia, Sandscape blueprint. What we use now is pretty long workflow: producing cards in cardscape > producing card images in Inkscape or Scribus > resizing those, updating a patch (or patches) and uploading it online, finally all the testers have to install clients and update their versions of patch.
Cardscape is not online to start with, and, even if prototyping IS rapid indeed, it isn't really straightforward to update cards.
The other method I can think of is a massive videoconferencing session, with HD cameras pointed in desks with some real cards. Badwidth is the first bottleneck here, I think I'm lucky enough to posses HD webcam that is capable of like 5 FPS performance. But let's get back on ground - this just won't happen.

There were some other really valuable ideas that are maybe worth reviewing, but it might be a good moment to rethink how the prototyping could be done. Without thousands of man-hours in coding or in producing patches that are used once or twice and wasted afterwards

What I wanted to propose is a different story: asynchronous, slow testing, "play by any media you wish" type, also "play any game you want", really. With any cards. May be that not all, or none, are invented - so that while testing rules you can invent cards, or change existing, and while testing your deck, you can come up with a rule mod and check it out on the fly.
I think there should be some rules different than the ordinary ones, like the fact that cards on hand are visible to both sides and building a deck isn't mandatory.
If you like IRC, go with it. Wiki, forums, jabber, google docs spreadsheets? Sure! Email? We even have a mailing list for that! Just remember - be lazy, no hurry!

What do you guys think? Can we test things that way - basically "in the meanwhile"? Should I write a basic set of rules and communication guidelines? Would you enjoy playing this way in the first place (it's still a lot of typing and copypasting)?
I'm the filthy bastard you wish you never met.
The Other
Posts:17
Joined:Sat Apr 07, 2012 11:21
Location:Wiltshire, UK

Re: Rapid vs. lazy prototyping

Post by The Other » Mon Apr 16, 2012 15:26

It seems like any costructive activity is better than none. So I think for this project to go anywhere, everybody who is serious about it needs to get of our collective arses and do something. Anything at all.
Frankly, even if people are inventing new cards by the dozen and playtesting against themselves, even that will still give us some useful data. In fact, at this stage of development that might even be a good strategy. If nothing else, it's a lot easier to throw out bad ideas, than it is to come up with good ones.
I think the highest priority should be to come up with a clear and simple 'basic' ruleset. Once we have that, it becomes possible for people to develop cards, abilities, additional rules etc. separately, while knowing that we are all at least roughly on the same page. It will be much easier to make progress that way - everyone will be able to try out any number of ideas, in the knowledge that they are all at least broadly compatible.
A knock-on effect of this is that it would be easier to get more people onboard if we had something at least marginally playable. I can't speak for anyone else, but I'd happily print out low-quality cards to playtest (or in extremis, even hand-write them if need be!), rather than have nothing useable at all. Art is not, or should not be, an immediate priority - either have 'artless' cards or rough sketches until we can get the 'proper' art done.
Once we have a playable product (even alpha-stage and tabletop/PBEM only), people will be willing to play it. And even if they aren't interested in game development, their feedback is still ueful to those of us who are. If we can get ideas (even dumb ones) flowing, it will be a lot easier to proceed.
User avatar
Q_x
developer
Posts:334
Joined:Thu Sep 23, 2010 15:10

Re: Rapid vs. lazy prototyping

Post by Q_x » Tue Apr 17, 2012 19:31

Just to prove - this is how things may look like in terms of sketching and playtesting:
https://docs.google.com/spreadsheet/ccc ... 2psSkp3Znc
This is a basic setup, which I've populated with some cards taken from Wiki (I hope cardscape data wasn't sent into space).
The top is the table, the bottom are available cards.
There are no cards on hand visible - either we don't have them - and no decks - and just pick any cards we like, or we can maintain decks, hands and gold piles elsewhere, unseen (maybe in separate pages of the same sheet?).
There is even chat available on the right side for all the editors

How to play:
to play a card, copy and paste card's title, cost attack and defense values from cards description into where you want to play it
to move a card - cut&paste - just forget the colors, we can make it all b&w and it will work just as good
to invent a card - write the cost and the description. You can alter bg color to indicate the freshness

The progress is saved and the game can be reverted and replayed

I think that's as easy as one can go in terms of "features per work" - not quite as easy to play as I'd want, but probably easier than Lackey - that is if you have any experience with office tools, won't cheat and so on.
I'm the filthy bastard you wish you never met.
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Rapid vs. lazy prototyping

Post by snowdrop » Tue Apr 17, 2012 20:22

non-visual
As for using non-graphical ways to playtest a CCG I, personally, can't do it: I have zero understanding of what's going on, or rather, lack the overview. I would have to read and re-read the text time and time again to even remember what card is where. For me that is also why graphics are important: Art, symbols etc, all work to let us quickly identify which card it is you are looking at, and at the very least which rules you associate it with.

Granted of course this is less true in a playtesting session that's in a constant flux and has everchanging cards - there visuals won't help as much and cards have to be re-read all the time anyways.

While I can't do it it doesn't mean nobody else can or should. I think that you should go with it if it works for you guys, and agree that it is still more progress than nothing.


quick visual flow
Q_x will kill me now, but here it goes:

1. Graphically create cards super-speedy using inkscape (heck, or even gimp, but ink is probably faster) if and only if it's realy faster than using the real template file, which is actually in Scribus, which will be the only officially supported by us anyways once we have a real release (or preferably long before, like already?) It takes 10-20 min to create a good looking card. It takes 5 - 10 min to revise one already existing one.

2. Use LackeyCCG. It works. Creating the "original" playtest patch takes a while (2-3h?), but no text except card names has to be written in it's "database" (plain text files). All text are in the card images. Updating already existing patch is just a matter of overwriting the card images from step one with the newest ones, and then asking everyone to download the latest patch (or do the overwriting themselves on their end, with for example bazaar) It isn't slow, and files are JPG or something small.

3. Use Mumble + Record. No typing will be needed, you see all, hear all, it can record voice, and you can even record desktop as video using other tools.

Drawback is it is nearly impossible to invent new cards on the fly, but as for testing I think it will be way smoother, but that's just from my own perspective, and it would still require plenty of prep.


Resource: http://wtactics.org/forum/viewtopic.php ... 1343#p1343 ...has all cards to date, They somehow need to be extracted and input in wiki(?) where we can start working with them. :?
User avatar
Q_x
developer
Posts:334
Joined:Thu Sep 23, 2010 15:10

Re: Rapid vs. lazy prototyping

Post by Q_x » Fri Apr 20, 2012 08:46

snowdrop wrote:non-visual
As for using non-graphical ways to playtest a CCG I, personally, can't do it: I have zero understanding of what's going on, or rather, lack the overview. I would have to read and re-read the text time and time again to even remember what card is where. For me that is also why graphics are important: Art, symbols etc, all work to let us quickly identify which card it is you are looking at, and at the very least which rules you associate it with.
It's not for rapid, 100% accurate play, it's for lazy testing. Turn in a day, one game a week. The layout is more clear, than Lackey's, not even mentioning the learning curve and time distribution - Lackey GUI looks like a spacecraft to me TBH, and I haven't seen GCCG patch in action - in both cases both players have to be online at the same time ;) while with play-by-mail or play-by-sheet (forums, wiki, whatever) it's completely asynchronous and you perfectly know how the tool works.

For the database my "pretty clever idea" is to put cardscape back online as soon as it's finished and rather than developing cards, take care for more people coming on board - that is advertisement.
I'm the filthy bastard you wish you never met.
Post Reply