• JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator
  • JoomlaWorks Simple Image Rotator

A free template from Joomlashack

A free template from Joomlashack

About Alt+Games


Alt+Games is a blog about games by a couple of gamers. Role-playing games , computer and console games , board games etc. Focus on games that enable playing together , whether in the same room or over the net. We try to feature interesting stuff you don't hear from elsewhere.

Site Language

Search

Related Items

Statistics

Visitors: 522909
Home arrow Board & RPG
Board & RPG
Rpg Design and Agile Methods PDF Print E-mail
Written by Antti   
Wednesday, 22 July 2009

I've been toying with this new role-playing game idea of mine for the past a couple days. And you know what, I've realized that designing a complete role-playing game is a complex undertaking indeed. From reading Eric Zimmerman (et al.) I do know that designing any game is a second-order design problem but I'm talking about much more than that. The interaction in around the game table is very complex and can be structured in many ways, leading to more design problems in the way. Putting a rpg together reminds me somehow of software architecture design. Complexity by L-T-L (Creative Commons licensed, attribution, non-commercial, share-alike) There, I'e said it. Not in a detailed way, just the way that you won't be able to design a new system perfectly before seeing or concepting some of its parts in action.

And this brings me to agile software development. Agile dev has been presented as a solution for complex, risky and uncertain software projects (so, most of them, actually ;) ). I've thought about how to go about designing a game in an agile way. Here's what I came up in regards to rpg design:

  1. Specify one specific game instance / situation
  2. Design a system / Tweak existing one for that instance / situation
  3. Playtest
  4. Assess, keep the things that worked
  5. If specified instance / situation not fully covered, back to step 2
  6. Refactor the designed system to fit with the whole
  7. Finished? If not, go to step 1

I'm sure some elaboration is needed. The first step involves specifying a single use of the system. I imagine it would be best to start from a small part of the system, like how to handle a specific situation in the game. It is best to start from the most critical and risky parts of the system. In later iterations the design can jump to one instance of game meaning something between the final game and a scenario for the game. Something with more restrictions than the final game is likely to have: For example, if you are designing a generic thriller game it could be preferable to first produce a sub-set of that, like a game to handle Infernal Affairs/Departed kind of two undercover guys at the opposite sides of the battle kind of stories (I've not spoilt the movie(s) for the two of you who haven't seen either I think ;) ). Maybe even with a playtest / demo scenario kind of set situation.

Designing and playtesting would be done as usual, I'm not going into those in detail. Well, a bit. Playtesting should be done in proportion of the specific game instance / situation in question. If a single mechanic is being developed in the iteration, it may be enough to playtest it yourself or with the help of some random friends just messing about with it. But with game instances you should at least do one or more playtest sessions yourself or even try to recruit somebody from outside to test the game it on her own.

Refactoring the system involves taking the results from the iteration in question and integrating it with the rest of the system. I imagine this can be pretty tricky (what to keep, what to lose, how to structure the whole system). The good news is that it all will be tested in the next iteration.

Are all rpgs designed like that? Probably not. Like agile methods in software dev I think this kind of exploratory design process would be best suited to projects with much uncertainty. Like games with new kinds of mechanic, interaction, goals, whatsoever.

The advantage of this approach as I see it is that you get a grip on some part of the game you are aching to design right away. The idea might change, you might find out that you can't yet get your head around some part of the whole but you get to divide the big ugly uncertainty to pieces you can swallow (agile riddle: How do you eat an elephant?)

The other thing is that you get constant feedback via the playtesting. This helps you keep your feet on the ground and your head out of the clouds if you analyze the playtest results objectively.

But this is just my first thoughts on this matter. I will try to use this process with my new game idea that I got from Denise Bonal's play Les Pas perdus (Asemalla in Finnish). I'll report on how it works as I go on.

 
Secrets in RPGs PDF Print E-mail
Written by Antti   
Thursday, 25 June 2009

My reactions to Vincent Baker's views on secrets in role-playing games on his blog anyway -- only in Finnish, sorry!

Last Updated ( Friday, 26 June 2009 )
 
IAWA Conflicts PDF Print E-mail
Written by Antti   
Tuesday, 19 May 2009
About conflicts in IAWA, only in Finnish, sorry.
Last Updated ( Tuesday, 19 May 2009 )
 
IAWA - End of Episode 1 PDF Print E-mail
Written by Antti   
Sunday, 10 May 2009
Report of second session of our In a Wicked Age game, only in Finnish, sorry.
Last Updated ( Sunday, 10 May 2009 )
 
MitsuSoft shocks PDF Print E-mail
Written by Antti   
Wednesday, 29 April 2009

This post on our Shock: Social Science Fiction game last Sunday is only available in Finnish at the moment, sorry about that. 

Pelattiin eilen Shockia A-P:n luona. Pääsimme viidessä tunnissa maaliin kaikkien protagonistien tarinoissa. Hauskaa oli, kiitos A-P:lle pelin järjestämisestä. Shock: Social Science Fiction on narrativistinen scifi-roolipeli, jossa käsitellään yhteiskunnallisia teemoja henkilöhahmojen ja shokkien eli pelimaailman nykytodellisuudesta erottavien seikkojen avulla.

Näin jälkeenpäin ajatellen minun mielestäni sessiossa oli pari kohokohtaa. Maailman kehittely pääsi vauhtiin kun pohdimme ja tarkensimme teemoja ja shokkeja. Oli todella hauska heitellä ideoita, kuunnella toisten heittoja ja ottaa niistä kimmokkeita vielä mielettömämpiin ideoihin. Toinen kohokohta oli antagonistien maalailemien avauskohtauksien kuunteleminen. Protagonistien tarinapäämäärät konkretisoituivat ja antagonistit saivat äänen.

Tokihan koko sessio oli oivaa ajanvietettä ja viihdykettä. Meidän shokkimiljöömme muotoutui 2090-luvun maapalloksi, jossa kansallisvaltiot olivat saaneet väistyä suurten korporaatiovaltioiden tieltä. Globaali hteiskunta oli jakautunut omistajiin, työntekijöihin ja ulkopuolisiin. Tekijänoikeudet olivat tiukentuneet ja lainaus oli kriminalisoitu. Tsätä huolimatta ihmiset, niin ulkopuoliset kuin työntekijätkin, lainasivat pimeästi tavaraa toisilleen. Tietoisuuden monistamisen teknologia oli jo kehitetty, mutta proseduuri oli vielä kömpelöä ja hidas. Teemoina oli edellä mainittujen lisäksi myös mainonta ja keinotekoinen mielihyvä, jotka eivät oikein päässeet fiktioon mukaan.

Shockin pelisysteemi on periaatteessa yksinkertainen, mutta sisältää muutaman minulle epäintuitiivisen piirteen. Ensinnäkin praxis-parien (joista aina toinen valitaan konfliktissa käytettäväksi ominaisuudeksi) heittojen onnistumisluvut eivät ensimmäisen session aikana menneet minulle perille sitten millään. Ymmärrän periaatteen, mutta mielestäni pelin tapa kirjoittaaa vain yksi luku hahmolomakkeelle on huono. (Niille, jotka eivät tiedä: Shockissa päätetään 2 praxis-paria, joista toista voidaan käyttää konfliktissa. Praxis-parille määritellään onnistumisluku väliltä 3-8. Ylempää praxista käytettäessä pitää d10:llä heittää yli ja alempaa praxista alle kohdeluvun.)

Toinen epäselkeä piirre on mielestäni konfliktien yleinen rakenne, eli eskaloimisen ja linkkien polttamisen mahdollisuudet ja niiden seuraukset. Ne pysyivät session aikana hyvin hanskassa koska A-P oli sääntöjen tasalla mutta jos pelaisin Shockia kokemattomammassa seurassa, ottaisin ehkä käyttöön jonkinlaisen konflikti-prosessikaavion.

Shockista jäi kuva hyvin suoraviivaisena ja tiukkrakenteisena pelinä. Jokainen pelaaja pelaa yhtä protagonistia ja antagonistia yhdelle toisen pelaajan protagonistille. Jokaiselle protagonistille pelataan omaa tarinaansa, risteymiä tai yhteisiä kohtauksia ei tapahdu. Jokainen tarina kestää 3-4 kohtausta; jokainen kohtaus loppuu selkkaukseen. Viimeisessä kohtauksessa tulee protagonistin tarinapäämäärän suhteen tapahtua jonkinlainen ratkaisu. On selvää, että Shock pitää suitset tiukalla tarinan muodon ja yleisen kaavan suhteen.

Itse pidän tuollaisesta tiukasta rakenteesta. Koska tarinat olivat yksinkertaisia ja suorasukaisia, ehdimme 5-tuntisessa sessiossa mehustella sopivasti myös maailman yksityiskohdilla ja omituisuuksilla. Se, miten hyvin tarinat käsittelivät valitsemiamme teemoja, vaihteli. Toisaalta teemojen käsittely ei ehkä ollut ihan hirveän korkealla ainakaan omissa prioriteeteissäni; pidin eniten Matin protagonistin tarinasta, vaikka se meni hieman ohi hahmolle valitusta teemasta ja shokista. (Matin tarina lyhyesti: brasilialainen MitsuSoftin työntekijä koittaa järjestää ruokaa ja lääkkeitä Rion slummiin (yhtiön) lainvastaisin keinoin, mutta joutuu henkilöstöhallinnon aivopesemäksi ja oppii, että parasta slummille on MitsuSoftin haarakonttori.)

Shockia pelatessa saa myös harjoitella ekonomista kohtauksen raamittamista. Kohtauksien raamitus on periaatteessa antagonistipelaajan harteilla. Minusta oli hauskaa yrittää viedä Matin tarinaa eteenpäin mahdollisimman jämäköillä kohtauksenalustuksilla. Hauskaa oli myös nähdä, minkälaisia tilanteita muut keksivät protagonistien pään menoksi.

Siinäpä ehkä olennaisimmat huomiot. Haluan ehdottomasti kokeilla Shockia uudemman kerran.

Last Updated ( Tuesday, 28 April 2009 )
 
<< Start < Prev 1 2 3 4 5 6 Next > End >>

Results 10 - 18 of 51
Joomla Templates by Joomlashack