-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
877 lines (559 loc) · 55.1 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[zero's a life]]></title>
<link href="http://zerosalife.github.io/atom.xml" rel="self"/>
<link href="http://zerosalife.github.io/"/>
<updated>2017-11-19T11:00:35-05:00</updated>
<id>http://zerosalife.github.io/</id>
<author>
<name><![CDATA[zerosalife]]></name>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[Shovel Knight's Old-school Tricks]]></title>
<link href="http://zerosalife.github.io/blog/2017/11/18/shovel-knights-old-school-tricks/"/>
<updated>2017-11-18T10:43:14-05:00</updated>
<id>http://zerosalife.github.io/blog/2017/11/18/shovel-knights-old-school-tricks</id>
<content type="html"><![CDATA[<p>Here’s a collection of relatively disorganized notes looking at <a href="http://yachtclubgames.com/shovel-knight/">Shovel Knight’s</a> design.</p>
<!--more-->
<p>Great article about parallax scrolling and plenty of other stuff from Shovel Knight: <a href="http://gamasutra.com/blogs/DavidDAngelo/20140625/219383/Breaking_the_NES_for_Shovel_Knight.php">http://gamasutra.com/blogs/DavidDAngelo/20140625/219383/Breaking_the_NES_for_Shovel_Knight.php</a></p>
<p>Even some indies are getting into the spirit: <a href="https://twitter.com/NoelFB/status/487185061972680705/photo/1">https://twitter.com/NoelFB/status/487185061972680705/photo/1</a></p>
<p>Interview with the Shovel Knight creators Yacht Club Games: <a href="https://www.nintendoworldreport.com/connectivity/38203/episode-144-ive-seen-some-badass-canes">https://www.nintendoworldreport.com/connectivity/38203/episode-144-ive-seen-some-badass-canes</a>. The interview starts about 28 minutes into the podcast.</p>
<h2>Resolution</h2>
<p>Shovel Knight runs on displays meant to run 1080p down to pocket-sized 3DS screens. The fine article mentions that scaling Shovel Knight’s NES-style graphics up to 1080p results in virtual pixels of about 4.5 x 4.5 1080p pixels. It also mentions that the effective resolution
they shoot for is 400 x 240, resulting in an aspect ratio of 5:3.</p>
<p>According to the fine article and <a href="http://en.wikipedia.org/wiki/Nintendo_Entertainment_System_technical_specifications">wikipedia</a>, that’s pretty close to a stretched out version of the original NES resolution.</p>
<p>For no other purpose than my own reference here, the DS’ resolution is 256 x 192, according to <a href="http://www.usgamer.net/articles/final-fantasy-iii-pc-port">this article</a>. The Gameboy is 160 x 144 according to <a href="http://jams.gamejolt.io/gbjam3">#gbajam</a>. Typical NES background tiles are 16 x 16 pixels, foreground sprites are either 8 x 8 or 8 x 16 (Sources: <a href="http://wayofthepixel.net/index.php?topic%3D10784.5%3Bwap2"><http://wayofthepixel.net/index.php?topic=10784.5;wap2></a>; <a href="http://en.wikipedia.org/wiki/Nintendo_Entertainment_System_technical_specifications">http://en.wikipedia.org/wiki/Nintendo_Entertainment_System_technical_specifications</a>). For reference, Link’s sprite in Legend of Zelda, an NES game, is 16 x 16, Link’s sprite in Link’s Awakening, a gameboy game, is 16 x 16, and Link’s sprite in A Link to the Past, an SNES game, is 32 x 32.</p>
<p><a href="http://www.fortressofdoors.com/the-quest-to-upscale-pixel-art/">http://www.fortressofdoors.com/the-quest-to-upscale-pixel-art/</a></p>
<p>And <a href="http://en.wikipedia.org/wiki/Neo_Geo_(system">NeoGeo</a>) is:</p>
<blockquote><p>Display resolution: 320×224 (many games only used the centermost 304 pixels)</p>
<p>Color palette: 65,536 (16-bit) (Not RGB565, but RGB666, where the lowest bit of each channel is shared with one bit)</p>
<p>Maximum colors on screen: 4,096 (12-bit)</p>
<p>Maximum sprites on screen: 380</p>
<p>Minimum sprite size: 1×2</p>
<p>Maximum sprite size: 16×512</p>
<p>Maximum sprites per scanline: 96</p>
<p>Simultaneous scroll planes: 3</p>
<p>Aspect ratio: 4:3</p></blockquote>
<p>And LDTV is: <a href="http://en.wikipedia.org/wiki/Low-definition_television#References">http://en.wikipedia.org/wiki/Low-definition_television#References</a></p>
<p>More modern resolutions considered: <a href="http://gamedevelopment.tutsplus.com/articles/quick-tip-what-is-the-best-screen-resolution-for-your-game--gamedev-14723">http://gamedevelopment.tutsplus.com/articles/quick-tip-what-is-the-best-screen-resolution-for-your-game–gamedev-14723</a></p>
<p>PS1: 320 pixel wide resolution. SOTN: 356 pixels wide, tiling pattern consists of 16x16 blocks tiling with 16 colors each.</p>
<p>So the Shovel Knight screen is 25 x 15 tiles.</p>
<p>I find choosing an aesthetically pleasing aspect ratio to be a crucial design decision; one that I often approach on a trial and error basis. Knowing what others have—in my humble opinion successfully—chosen gives a nice starting point <em>a priori</em> for projects with similar scope.</p>
<p>Mighty Gunvolt: <a href="http://2-dimensions.com/2014/08/20/mighty-gunvolt-fine/">http://2-dimensions.com/2014/08/20/mighty-gunvolt-fine/</a></p>
<p>Axiom Verge: 480x270</p>
<p>Mario Maker levels: 12 screens long by 2 screens tall, the longest
level was 512 blocks.</p>
<p>Vita is 960x544</p>
<h2>One comment on designer-player interaction through design</h2>
<p>According to <a href="http://www.usgamer.net/articles/inside-shovel-knights-launch">this article</a> by Chris Holt, the Shovel Knight designers were realtively wishy washy about including the fishing pole. For the record, I like the addition of yet another superfluous minigame. And it’s useful for fishing up money bags left in pits when you die, so there.</p>
<p>The use of sparkles to mark pits containing potential fishing spoils illustrates a clever bit of design and interaction with the player through design. You, the player, will notice that the pit in the fish-themed level has the sparkles. So, naturally, you’re very likely to fish there. Bada-bing bada-boom: fish spoils. The designers have communicated what the sparkles in the pits mean without having to resort to lame exposition from a tutorial or a helper character.</p>
<p>The great games of the NES-era that Shovel Knight emulates were littered with these kinds of ingenious communicative design patterns. Here’s <a href="http://iwataasks.nintendo.com/interviews/#/wii/nsmb/0/3">an interview with Shigeru Miyamoto</a> talking about the deliberate design behind communicating the purpose of the iconic mushroom power-up in Super Mario Bros.</p>
<h2>Another fine example of introducing new mechanic in Shovel Knight.</h2>
<p>In Treasure Knight’s level you come across rocket platforms that fly horizontally when you activate a lever by hitting it with your shovel. For my play-through this was the first time I encountered these platforms.</p>
<p>Since they are your means of conveyance to avoid spikes below, the devs could have been mischievous about it. As your intrepid game design blogger is well versed in virtual button pressing, my first reaction is to hop on the platform and press boot-ton—viciously strike the lever with the shovel. Ah, but doing so leads to a spikey death for those with slow reaction times—your intrepid blogger, yeah, yeah.</p>
<p>The second time through YIB, meaning me, and likely you, meaning you, would be more wary; carefully timing the necessary jump to avoid the spikes. The devs, in their wise and studied ways, saw fit to embed a dig-able reward nugget in the wall. It’s lodged in such a way that when you knock it loose it lands just so, so when you shovel it to dislodge the pecuniary treats within, you also hit the lever, activating te rocket platform. Now you know to look ahead and carefully time your jump. No harm no foul. No wordy tutorial, telling you, “Hey, listen. This platform shoots off when you hit the lever.”</p>
<p>You learned the new mechanic, and thus the behavior necessary to interact with it, through previously ingrained behavior beaten into your head with a thousand gem pickups. It’s devilishly clever.</p>
<h2>Shovel Knight’s toolset</h2>
<h3>Physics</h3>
<p>Box2D</p>
<h3>Level Editor</h3>
<p>Tiled Map Editor</p>
<h3>Pixel Editor</h3>
<p>Pro Motion</p>
<h3>Audio Engine</h3>
<p>FMOD Sound System</p>
<h3>Rendering</h3>
<p>Angle</p>
<h3>Rendering and Input</h3>
<p>SDL</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Creator Questions]]></title>
<link href="http://zerosalife.github.io/blog/2017/02/18/creator-questions/"/>
<updated>2017-02-18T10:23:42-05:00</updated>
<id>http://zerosalife.github.io/blog/2017/02/18/creator-questions</id>
<content type="html"><![CDATA[<p>Taking inspiration from <a href="http://www.decontextualize.com/">Allison Parrish’s</a> talk: <a href="http://opentranscripts.org/transcript/programming-forgetting-new-hacker-ethic/">Programming is Forgetting: Toward a New Hacker Ethic</a>, here’s my version of Parrish’s new hacker ethic for creators:</p>
<h2>Creator Questions</h2>
<ul>
<li>Who gets to use what I make? Who am I leaving out? How does what I make facilitate or hinder access?</li>
<li>What assets am I using? Whose labor produced them and what biases and assumptions are built in? What do the assets leave out?</li>
<li>What systems of authority am I enacting through what I make? What systems of support do I rely on? How does what I make support other people?</li>
<li>What kind of community am I assuming? What community do I invite through what I make? How are my personal values reflected in what I make?</li>
</ul>
<p>Watch Allison Parrish’s talk for more background on why these sorts of updates are critical for shaping a more welcoming community.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Every Week a Dev]]></title>
<link href="http://zerosalife.github.io/blog/2017/01/28/every-week-a-dev/"/>
<updated>2017-01-28T11:21:35-05:00</updated>
<id>http://zerosalife.github.io/blog/2017/01/28/every-week-a-dev</id>
<content type="html"><![CDATA[<p><a href="https://twitter.com/everyweekadev">Every Week a Dev</a> is a twitter bot created by <a href="https://twitter.com/tha_rami">Rami Ismail</a> that spotlights a new person involved in game development every week. Check out the archives and follow it if you haven’t already. The bot’s a great aggregator for gamedev wisdom.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[2016 Year in Review]]></title>
<link href="http://zerosalife.github.io/blog/2017/01/07/2016-year-in-review/"/>
<updated>2017-01-07T10:22:54-05:00</updated>
<id>http://zerosalife.github.io/blog/2017/01/07/2016-year-in-review</id>
<content type="html"><![CDATA[<p>Here are some highlights from the previous year:</p>
<ul>
<li><a href="http://zerosalife.github.io/blog/2016/03/19/how-dungeonmans-teaches-diagonal-movement/">How Dungeonmans Teaches Diagonal Movement</a></li>
<li><a href="http://zerosalife.github.io/blog/2016/03/05/proportion-types/">Proportion Types</a></li>
<li><a href="http://zerosalife.github.io/blog/2016/04/23/improvisation-vs-preparation/">Improv vs Preparation</a>
<ul>
<li>This could be a conference talk!</li>
</ul>
</li>
<li><a href="http://zerosalife.github.io/blog/2016/06/18/mobile-frame-football-association/">Mobile Frame Football Association</a>
<ul>
<li>Needs playtesting</li>
</ul>
</li>
<li><a href="http://zerosalife.github.io/blog/2016/08/27/why-does-pokemon-go-use-passive-voice/">Why Does Pokemon GO Use Passive Voice?</a></li>
<li><a href="http://zerosalife.github.io/blog/2016/11/12/arcana-procedurally-generated-tarot-decks/">Arcana: Procedurally Generated Tarot Decks</a></li>
<li><a href="http://zerosalife.github.io/blog/2016/12/03/procedural-generation-of-social-networks/">Procedural Generation of Social Networks</a></li>
</ul>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Procedural Generation of Social Networks]]></title>
<link href="http://zerosalife.github.io/blog/2016/12/03/procedural-generation-of-social-networks/"/>
<updated>2016-12-03T12:21:41-05:00</updated>
<id>http://zerosalife.github.io/blog/2016/12/03/procedural-generation-of-social-networks</id>
<content type="html"><![CDATA[<p>I’ve been thinking about how to run a hexcrawl style campaign in a cyberpunk world. Mobility is easy, so a spatially distributed procedurally generated map doesn’t make much sense. Characters could easily just look up information on an unfamiliar section of the map on whatever flavor of the internet exists in that world and buy a plane ticket or book a taxi ride to get there.</p>
<p>Transportation is cheap and the Sprawl has largely been explored. This is not to say that a typical hexcrawl-style campaign couldn’t work in a VR hacking setting. Look no further than <em><a href="http://www.ambrosiasw.com/games/uplink/">Uplink</a></em> to see a wonderful example.</p>
<p>In a cyberpunk setting the thing to be explored becomes the web of intrigue among the movers and the shakers in the campaign. Crosses and double crosses become the shifting landscapes and wandering monster encounters of the political landscape. See for, example this <a href="http://monstersandmanuals.blogspot.com/2011/08/cyberpunk-sandbox.html">blog post at Monsters and Manuals</a> and <a href="https://en.wikipedia.org/wiki/Barksdale_Organization#/media/File:Barksdale2.jpg">the organization chart from <em>The Wire</em></a>.</p>
<p><img class="center" src="http://zerosalife.github.io/images/assets/social-network.svg" title="" ></p>
<!--more-->
<p>After looking at a few good resources, I took this stab at crafting a social network generator:</p>
<h2>Defining connection types</h2>
<p>Based on <a href="http://monstersandmanuals.blogspot.com/2011/08/relationship-hexmap.html">this Monsters and Manuals blog post</a> I defined links as follows:</p>
<ul>
<li><strong>Black:</strong> Strong positive link</li>
<li><strong>Orange:</strong> Communication (past or present)</li>
<li><strong>Yellow:</strong> Awareness</li>
<li><strong>Red:</strong> Hostility</li>
</ul>
<h2>Making the connections</h2>
<p>For my initial attempts, I’ve found that a social network with 8 actors is complex enough to get some interesting relationships. I make twice as many random connections between the actors as there are actors. So in this case, we’re working with 16 random connections.</p>
<p>This means that some actors could have several connection sand some could have none. On average there may be 1 or 2 connections between most of the actors in the network.</p>
<h2>Graphing it</h2>
<p>I’ve <a href="http://zerosalife.github.io/blog/2014/04/26/clojure-rhizome-labeled-edge-tutorial/">used rhizome in the past</a> to graph stuff. This time around, I wanted more control over the characteristics of the resulting graph, so I went with <a href="https://github.com/Macroz/tangle">tangle</a>.</p>
<p>Tangle lets me change the node shape and edge colors, which is exactly what I needed to represent the types of connections in this social network.</p>
<p>You can see the resulting image above the fold.</p>
<h2>Additional resources</h2>
<p>Here are a few additional resources worth noting:</p>
<ul>
<li><a href="https://emshort.wordpress.com/2016/04/12/beyond-branching-quality-based-and-salience-based-narrative-structures/">https://emshort.wordpress.com/2016/04/12/beyond-branching-quality-based-and-salience-based-narrative-structures/</a></li>
<li><a href="http://maetl.net/talks/narrative-anxiety">http://maetl.net/talks/narrative-anxiety</a></li>
<li><a href="http://maetl.net/notes/storyboard/narrative-graph-models">http://maetl.net/notes/storyboard/narrative-graph-models</a></li>
</ul>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Arcana: Procedurally Generated Tarot Decks]]></title>
<link href="http://zerosalife.github.io/blog/2016/11/12/arcana-procedurally-generated-tarot-decks/"/>
<updated>2016-11-12T11:04:16-05:00</updated>
<id>http://zerosalife.github.io/blog/2016/11/12/arcana-procedurally-generated-tarot-decks</id>
<content type="html"><![CDATA[<p>Why not make some art?</p>
<p><a href="http://zerosalife.github.io/images/assets/arcana-screenshot.png"><img class="center" src="http://zerosalife.github.io/images/assets/arcana-screenshot.png" width="1278"></a></p>
<!--more-->
<p>Here’s <a href="https://random-arcana.herokuapp.com/">Arcana</a>, one of the projects I’m working for <a href="https://twitter.com/hashtag/procjam">#procjam 2016</a>.</p>
<p>Arcana generates a full deck of Tarot cards based on data from <a href="https://twitter.com/tinysubversions">Darius Kazemi’s</a> <a href="https://github.com/dariusk/corpora">corpora project</a>.</p>
<ul>
<li><p>Click on the cards to expand each card’s meaning.</p></li>
<li><p>Click the button in the corner for a three-card spread from the current deck.</p></li>
<li><p>Click the title, Arcana, in the title bar to regenerate a fresh deck.</p></li>
</ul>
<p><a href="http://zerosalife.github.io/images/assets/arcana-spread-screenshot.png"><img class="center" src="http://zerosalife.github.io/images/assets/arcana-spread-screenshot.png" width="2374"></a></p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Procjam 2016]]></title>
<link href="http://zerosalife.github.io/blog/2016/11/05/procjam-2016/"/>
<updated>2016-11-05T10:36:10-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/11/05/procjam-2016</id>
<content type="html"><![CDATA[<p>I’m announcing my participation in <a href="https://itch.io/jam/procjam">#procjam 2016</a>, which kicked off
yesterday.</p>
<p>This is my third year participating.</p>
<p>You can look back at my previous entries from 2014 here: <a href="http://zerosalife.github.io/blog/2014/11/08/insceptahdeckwu/">Insceptahdeckwu</a>, <a href="http://zerosalife.github.io/blog/2014/11/15/patchwerk/">Patchwerk</a> and from 2015 here: <a href="http://zerosalife.github.io/blog/2015/12/05/procjam-2015-restrospective/">Mech Sheet Generator</a>.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Procjam 2016 Talks]]></title>
<link href="http://zerosalife.github.io/blog/2016/10/29/procjam-2016-talks/"/>
<updated>2016-10-29T09:51:02-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/10/29/procjam-2016-talks</id>
<content type="html"><![CDATA[<p>Last weekend <a href="https://twitter.com/mtrc">@mtrc</a> put on a <a href="https://www.youtube.com/watch?v%3D3wcpLwvBTYo">series of talks</a> leading up to <a href="https://twitter.com/hashtag/procjam">#procjam</a> 2016 at Falmouth University in Cornwall. You can <a href="https://itch.io/jam/procjam">read more about the jam at itch.io</a>.</p>
<p>Here are some links to interesting resources that stood out to me:</p>
<!--more-->
<h2>The Video Game Level Corpus</h2>
<p><a href="https://arxiv.org/abs/1606.07487">https://arxiv.org/abs/1606.07487</a></p>
<h2>PCG book</h2>
<p><a href="http://pcgbook.com/">http://pcgbook.com/</a></p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Special Missions' Story Pattern]]></title>
<link href="http://zerosalife.github.io/blog/2016/10/22/special-missions-story-pattern/"/>
<updated>2016-10-22T09:22:43-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/10/22/special-missions-story-pattern</id>
<content type="html"><![CDATA[<p>I’m interested in Larry Hama’s <a href="https://en.wikipedia.org/wiki/G.I._Joe_%28comics%29#G.I._Joe:_Special_Missions"><em>GI Joe Special Missions’</em></a> influence on Metal Gear and Metal Gear Solid. I want to look at the pattern of story telling that seems to emerge consistently in Special Missions’ issues.</p>
<!--more-->
<ul>
<li>A</li>
<li>A</li>
<li>B</li>
<li>A</li>
<li>B</li>
<li>A</li>
<li>B</li>
<li>A</li>
<li>A</li>
<li>B</li>
<li>A</li>
<li>A</li>
<li>B</li>
<li>A</li>
<li>A</li>
<li>A</li>
<li>A</li>
<li>A</li>
</ul>
<p>Notice how this follows a three act structure.</p>
<p>In the first three pages we establish a scenario, the first act of the story. In the following pages we rapidly cross cut between the primary story (A) and the secondary story (B), forming the bulk of the story, the second act. Finally the secondary story may be resolved or cross over to join the primary story, which takes over for the last five pages, forming the climax and resolution, the third act of the story.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Why does Pokemon GO use passive voice?]]></title>
<link href="http://zerosalife.github.io/blog/2016/08/27/why-does-pokemon-go-use-passive-voice/"/>
<updated>2016-08-27T10:21:50-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/08/27/why-does-pokemon-go-use-passive-voice</id>
<content type="html"><![CDATA[<p>A colleague of mine wondered why <a href="http://www.pokemon.com/us/pokemon-video-games/pokemon-go/">Pokemon GO</a> uses the passive voice when reporting,</p>
<blockquote><p>Pikachu was caught!</p></blockquote>
<p>The simple reason is nostalgia—that’s the phrasing from the original <a href="http://bulbapedia.bulbagarden.net/wiki/Generation_I">Generation 1 Pokemon games</a>.</p>
<p>Was there a limitation inherent in the medium at the time that required using the passive voice? Below I’ll dig into the <a href="https://github.com/pret/pokered">disassembled Pokemon Red source code</a> to answer the question of why Pokemon Go uses passive voice.</p>
<!--more-->
<p><a href="https://github.com/pret/pokered/blob/master/text.asm#L2793-L2798">This code</a> shows the text that is displayed when the player successfully uses a pokeball to capture a pokemon. I’ll break it down for you, using the <a href="https://github.com/pret/pokered/blob/master/macros.asm#L221">text macros</a> for reference.</p>
<p>The <code>text</code> macro starts writing text, printing out the string <code>"All right!"</code>. Then the <code>line</code> macro prints a special character <code>"@"</code> at the beginning of the bottom line in the text box. The <code>TX_RAM</code> macro looks up a stored chunk of text based on the address stored in <code>wEnemyMonNick</code>, which points at the current enemy pokemon’s name, and prints the name in the text box. Then another <code>text</code> macro starts writing <code>" was"</code> following the enemy pokemon’s name. And finally, the <code>cont</code> macro scrolls text to the next line, printing <code>"caught!@@"</code>.</p>
<p>I couldn’t find a good reference, but I’m pretty sure that the <code>@</code> character is acting as a <a href="https://en.wikipedia.org/wiki/Newline">newline character</a>, more commonly <code>\n</code> these days.</p>
<p>The final text looks something like:</p>
<pre><code>All right!\n
Pikachu was
caught!!\n
\n
</code></pre>
<p>Now you’ve seen the implementation of the text for catching pokemon. Is there a technical reason for choosing to use passive voice?</p>
<p>Maybe <code>TX_RAM</code> can only be used with a <code>text</code> macro. Based on a cursory glance over the <a href="https://github.com/pret/pokered/blob/master/text.asm">text</a>, I’d say that this is likely to be the case. But that doesn’t prevent the developers from choosing to say</p>
<pre><code>You caught
Pikachu!
</code></pre>
<p>Could the developers have used a more active voice? Yes! Refer to this <a href="https://github.com/pret/pokered/blob/master/text.asm#L1130">link battle text</a> for an example of <code>TX_RAM</code> beginning a dialogue.</p>
<p>The word “you” occurs <a href="https://github.com/pret/pokered/search?utf8%3D%25E2%259C%2593&q%3Dyou">171 times in the Pokemon red codebase</a>, without controlling for contents of text strings vs method and variable names.</p>
<p>There seems to be a general tendency to use “you” to refer to things that the player does, such as connecting the link cable between two Gameboys to trade pokemon, rather than the player character’s actions in the game. So that could have been a good reason to choose the passive voice. Also, there could be some reasoning behind matching the original Japanese text that I’m missing here.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[A Grammar of Procedural Platformer Levels]]></title>
<link href="http://zerosalife.github.io/blog/2016/08/13/a-grammar-of-procedural-platformer-levels/"/>
<updated>2016-08-13T10:43:49-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/08/13/a-grammar-of-procedural-platformer-levels</id>
<content type="html"><![CDATA[<p>Brief post this week linking to a couple of great articles about elements of platformer game design. I think these articles make great resources for a procedural platformer level generator. Brevity and procedural focus stem at least partially from the release of the captivating <em><a href="http://www.no-mans-sky.com/">No Man’s Sky</a></em>.</p>
<h2>Platformer Level Design</h2>
<p><a href="https://twitter.com/gamedevprof">Ken Bowen</a>’s 2012 article covering <a href="http://gamedevprofessor.com/sidescroller-level-design/">2D Sidescroller Level Design</a> has some great tips. I especially like the section called Define your Building Blocks. I think this will require some revisiting in a future post.</p>
<h2>Fundamental Physics for Platformers</h2>
<p><a href="https://github.com/error454">Zachary Burke</a>’s article about <a href="http://error454.com/2013/10/23/platformer-physics-101-and-the-3-fundamental-equations-of-platformers/">Platformer Physics</a> is a nice resource that explains the fundamentals in great mathematical detail. It also provides inverse solutions for deriving physics based on descriptive parameters for jump height and timing.</p>
<p>Taken together these articles suggest, to me, that we could achieve a fully descriptive grammar of platformer games to generate a variety of levels constructed from basic building blocks, with constraints ensuring fun and responsive gameplay physics.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[How I am Setsuna uses a State Stack: Overworld]]></title>
<link href="http://zerosalife.github.io/blog/2016/07/30/how-i-am-setsuna-uses-a-state-stack-overworld/"/>
<updated>2016-07-30T10:47:19-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/07/30/how-i-am-setsuna-uses-a-state-stack-overworld</id>
<content type="html"><![CDATA[<p>The <code>Overworld</code> state ties together all of the states I previously discussed based on watching <a href="https://youtu.be/GUwmNnMXd4A">this playthrough</a> of <em>I am Setsuna</em>.</p>
<!--more-->
<h2>Overworld</h2>
<p>I think that the <code>Overworld</code> can serve as the base <code>Map</code> state I used in my previous examples. This allows the <code>Overworld</code> to serve two purposes. First, the <code>Overworld</code> state holds all of the map and area entrance data to allow characters to move about the overworld. And second, the <code>Overworld</code> state can store information about the state of the game for use in the other states.</p>
<h2>Area information</h2>
<pre><code>| Overworld |
</code></pre>
<p>The <code>Overworld</code> contains all of the data necessary to render the overworld map, including the assets for rendering the map and the location and the target map data on triggers for entering towns, caves, and other <code>Maps</code>.</p>
<h2>Gameplay information</h2>
<pre><code>| Menu ← |
| Overworld |
</code></pre>
<p>The <code>Overworld</code> also contains the sorts of information you see in the main menu, such as the character’s state, inventory, money. Serializing a snapshot of this information and the characters’ position saves the game’s state and can be used to reload the game later.</p>
<p>The states added to the stack on top of the <code>Overworld</code> state can access this data for consumption and updating.</p>
<pre><code>| Shop menu |
| Map (Shop) |
| Map (Town) |
| Overworld |
</code></pre>
<p>For instance, a shop in town may access the inventory and money to allow the player to purchase items.</p>
<pre><code>| Combat |
| Overwold |
</code></pre>
<p>Similarly, the combat state may access the characters’ stats, equipment and inventory to track health, damage output, and item use in battle.</p>
<h2>Summary</h2>
<p>I hope that <a href="http://zerosalife.github.io/blog/2016/07/02/how-i-am-setsuna-uses-a-state-stack-map-and-dialog/">the</a> <a href="http://zerosalife.github.io//zerosalife.github.io/blog/2016/07/16/how-i-am-setsuna-uses-a-state-stack-combat/">last</a> <a href="http://zerosalife.github.io/blog/2016/07/23/how-i-am-setsuna-uses-a-state-stack-interiors/">few posts</a> have given you an overview of how the state stack could work for supporting an RPG like <em>I am Setsuna</em>.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[How I am Setsuna uses a State Stack: Interiors]]></title>
<link href="http://zerosalife.github.io/blog/2016/07/23/how-i-am-setsuna-uses-a-state-stack-interiors/"/>
<updated>2016-07-23T11:01:13-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/07/23/how-i-am-setsuna-uses-a-state-stack-interiors</id>
<content type="html"><![CDATA[<p>About <a href="https://youtu.be/GUwmNnMXd4A?t%3D5m36s">a quarter of the way through this playthrough</a> of <em>I am Setsuna</em> at E3, the player enters a house.</p>
<!--more-->
<h2>Interiors</h2>
<p>The player enters a house, which triggers a special case of the Map state, the Interior state to be pushed onto the stack.</p>
<pre><code>| Interior ←push |
| Map |
</code></pre>
<p>It’s hard to tell how the interior state differs from the town map and the forest map from the beginning of the video. In fact, I think that you could cover similar features with a simple <code>Map</code> state that knows where triggers (for, for example, Dialog or Treasure) and exits are placed.</p>
<p>So, it’s likely that the <em>I am Setsuna</em> developers are using a generalized <code>Map</code> state to cover these cases.</p>
<p>This leads us to the final state I want to explore, a state to capture the Overworld.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[How I am Setsuna uses a State Stack: Combat]]></title>
<link href="http://zerosalife.github.io/blog/2016/07/16/how-i-am-setsuna-uses-a-state-stack-combat/"/>
<updated>2016-07-16T11:14:59-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/07/16/how-i-am-setsuna-uses-a-state-stack-combat</id>
<content type="html"><![CDATA[<p>The previous post looked at how <em>I am Setsuna</em> uses a state stack to allow players to move around on a map and interact with NPCs via dialog. This time around, I’ll show you how combat can be handled by adding another state to the stack.</p>
<!--more-->
<p>This approach decreases the need to pass information between the various parts of your code handling the various states of your game. So it’s preferable compared to costly serialization and deserialization to pass information to wholly separate code every time the game state changes. Instead you simply change the way that the game’s code runs.</p>
<h2>Combat</h2>
<p>After the player converses with an NPC, combat with a gnarly looking bear begins. Here’s what likely happens.</p>
<pre><code>| Combat ←push |
| Map |
</code></pre>
<p>The player fights the enemy. Then the combat state pops off the stack, returning the player to the snowy forest map.</p>
<pre><code>| Combat →pop |
| Map |
</code></pre>
<p>Note that the combat state may have substates that handle in-combat messages, player turns, and experience and item rewards at the end of combat. Designing these substates depends on the specific requirements of your combat system. That makes it hard to tell what the developers are using from <a href="https://www.youtube.com/watch?v%3DGUwmNnMXd4A">this brief clip of <em>I am Setsuna</em></a>.</p>
<p>That’s all there is to it. The modularity of this state stack approach allows developers to customize the flow of gameplay as desired.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[How I am Setsuna uses a State Stack: Map and Dialog]]></title>
<link href="http://zerosalife.github.io/blog/2016/07/02/how-i-am-setsuna-uses-a-state-stack-map-and-dialog/"/>
<updated>2016-07-02T10:48:42-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/07/02/how-i-am-setsuna-uses-a-state-stack-map-and-dialog</id>
<content type="html"><![CDATA[<p>I recently watched <a href="https://www.youtube.com/watch?v%3DGUwmNnMXd4A">some footage of <em>I Am Setsuna</em> from E3</a>.</p>
<p>Here’s my analysis of the evolving <a href="https://en.wikipedia.org/wiki/Stack_(abstract_data_type)">state stack</a>, as you play this spritual successor to the classic RPG <a href="https://en.wikipedia.org/wiki/Chrono_Trigger"><em>Chrono Trigger</em></a>.</p>
<!--more-->
<h2>Map and Dialog</h2>
<p>There’s likely a catch-all map state in which characters can run around, interacting with the world by opening chests, entering doors and new areas, and talking to NPCs.</p>
<p>The gameplay starts in a snowy forest. So, there’s a <code>Map</code> state pushed onto the state stack that has a reference to the map for this snowy forest.</p>
<pre><code>| Map |
</code></pre>
<p>As the player wanders around the forest, the player encounters talking NPCs. These NPCs likely have triggers that push a <code>Dialog</code> state with a reference to the NPC’s dialog onto the stack.</p>
<pre><code>| Dialog ←PUSH |
| Map |
</code></pre>
<p>As the player advances and completes the dialog, the player is returned to the previous state, the snowy forest <code>Map</code>.</p>
<pre><code>| Dialog →POP |
| Map |
</code></pre>
<p>The gameplay is controlled by the current state at the top of the state stack. This provides a more convenient way to track the appropriate controls and UI elements than to sprinkle a bunch of complicated conditionals throughout some monolithic game code.</p>
<p>Next time I’ll talk about combat.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[/r/proceduralgeneration's spaceship challenge]]></title>
<link href="http://zerosalife.github.io/blog/2016/06/25/slash-r-slash-proceduralgenerations-spaceship-challenge/"/>
<updated>2016-06-25T10:53:41-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/06/25/slash-r-slash-proceduralgenerations-spaceship-challenge</id>
<content type="html"><![CDATA[<p>The June contest on <a href="https://www.reddit.com/r/proceduralgeneration/">/r/proceduralgeneration</a> is to create a <a href="https://www.reddit.com/r/proceduralgeneration/comments/4mn9gj/monthly_challenge_7_june_2016_procedural/">ProceduralSpaceship/Fleet generator</a>.</p>
<p>Here’s a look at some of the entries, so far.</p>
<!--more-->
<h2>a1studmuffin</h2>
<p><a href="https://github.com/a1studmuffin/SpaceshipGenerator">a1studmuffin’s</a> entry is a Python script that interfaces with Blender to create 3d spaceships. I’m digging the choices with textures. I also appreciate that a1studmuffin has commented to describe the phenotype of some of the parameters. I feel like this code would be good for a future deep dive explaining it.</p>
<h2>Ladus</h2>
<p><a href="http://i.imgur.com/rgs0b5y.png">Ladus’</a> entry is only shown in a screenshot and a WIP video available on the reddit thread. The 3d ships rendered in Unreal engine look good. More of a stylized look in contrast to a1studmuffin’s gritty ships.</p>
<h2>NoDownvotesPlease</h2>
<p><a href="http://i.imgur.com/MrjkVU3.gif">NoDownvotesPlease’s</a> entry gets bonus points for creating a galaxy for 2d spaceships to explore.</p>
<h2>Hans_Meiser_Koeln</h2>
<p><a href="http://i.imgur.com/XcCBnoh.png">Hans_Meiser_Koeln’s</a> entry has some good looking 2d ships.</p>
<h2>green_meklar</h2>
<p><a href="http://imgur.com/a/OZqSv">green_meklar’s</a> entry has some nicely <a href="https://en.wikipedia.org/wiki/Greeble">greebled</a> 2d ships made in JavaScript/HTML5. I’d be interested in seeing the code.</p>
<h2>Conclusion</h2>
<p>I’m excited to revisit a1studmuffin’s code after the contest ends.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Mobile Frame Football Association]]></title>
<link href="http://zerosalife.github.io/blog/2016/06/18/mobile-frame-football-association/"/>
<updated>2016-06-18T12:35:49-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/06/18/mobile-frame-football-association</id>
<content type="html"><![CDATA[<h2>Inspiration</h2>
<p>I asked myself the question, in a universe where mecha are used for primarily for military-industrial applications, how did the technology
get to that point?</p>
<p>Sure, some routes for technical advancement are funded purely by governments, but think of the racing sport’s influence on the
automobile industry.</p>
<p>So I asked the question, what if mecha became a dominant technology because of sports applications?</p>
<p>In which kind of sports could mecha thrive? There have previously been pugilistic representations of robots, but I deemed these as too
costly and too on the nose for the future military application.</p>
<p>Likewise, pure racing, while plausible, seemed to be ground that had
already been explored.</p>
<p>I settled on the possibility that the military-industrial applications mecha technology and piloting ability of the Mobile Frame Zero universe grew out of a pursuit of the world’s (universe’s?) most popular sport, (Association) Football a.k.a. Soccer.</p>
<p>Thus, the Mobile Frame Football Association, a rules mod for <a href="https://twitter.com/JoshuaACNewman">Joshua AC Newman’s</a> <a href="http://mobileframezero.com/mfz/">Mobile Frame Zero</a>, was born.</p>
<!--more-->
<h2>Football games</h2>
<h3>Duration of play</h3>
<p>Mobile Frame Football Association (MFFA) sanctioned games last 6 turns, consisting of two equal 3-turn halves. MFFA rules do not allow for the countdown mechanic from the vanilla Mobile Frame Zero (MF0) rules.</p>
<h3>Objective</h3>
<p>When time expires, the player with the highest number of goals scored wins.</p>
<h3>Teams</h3>
<p>Games are played between teams consisting of equal numbers of frames. Frames may have up to 4 systems installed, with the usual vanilla MF0 benefits for fewer than 4 installed systems (see, e.g., MF0 p. 64). For more explanation see <em>Dice Systems</em>.</p>
<h3>Field of Play</h3>
<p>The game field should be approximately the size of a normal MF0 table, with goals the size of 1 <em>movement scale</em> on each end of the field. Lines should be laid out to clearly mark the in bounds/out of bounds boundary. There should be at least 1” of space on the sidelines, to allow for units to be positioned outside of the field during out of bounds situations.</p>
<p>The size of your available Field of Play can dictate the Movement and Shooting Scales for your game. The suggested defaults are based on a normal MF0 table, your mileage may vary.</p>
<h2>Deployment</h2>
<p>During the deployment phase, you may place your units anywhere on the field in a legal formation. Cool your servos, I’ll describe the legal formations in just a sec.</p>
<h3>Beginning of play</h3>
<p>At the beginning of the game, at the beginning of the second half, or at a kickoff following a goal, players take turns placing units in bounds, in the half of the field that has been assigned (See: Determining possession). The player in possession of the ball, the <em>offensive player</em>, goes first. The ball, represented by a d12, is placed at the center of the field. The offensive player must place a unit next to the ball, this unit is in possession of the ball.</p>
<ol>
<li><p>Maintaining possession of the ball</p>
<p>A unit possesses the ball if the ball is in contact with its base (i.e. its legs). If two opposing units are in contact with the ball the unit in possession of the ball first maintains possession unless the opposing unit steals or tackles. Similarly if two units on the same side are in contact with the ball, the unit in possession of the ball first maintains possession unless it passes successfully to the second unit.</p></li>
<li><p>Determining possession at kickoff</p>
<p>A coin flip determines possession at the beginning of the game, with the winning player electing to be on offense or defense first. The losing player gets to determine the side of the field in which to deploy.</p>
<p>At the half, the possession and sides switch. Following a scored goal, the player who was scored on gains possession of the ball at the kickoff.</p></li>
</ol>
<h3>After a dead ball situation</h3>
<p>Play is stopped due to a foul, an out of bounds ball. This is called a <em>dead ball</em> situation.</p>
<ol>
<li><p>Out of bounds</p>
<p>Out of bounds balls force a turnover of possession. The ball is placed on the sideline where it went out of bounds.</p>
<p>Both players may redeploy their units, however the offensive player may not place a unit beyond the defensive unit closest to the goal. The defensive player places first, and must move the unit closest to the goal first, if it will be moved in the redeployment. Players alternate placing units. The offensive player must place a unit next to the ball.</p>
<p>After the offensive player redeploys the last unit, play resumes with the unit next to the ball immediately taking its turn, regardless of its initiative roll. If the unit next to the ball has an initiative die, remove it.</p>
<ol>
<li><p>Corner Kicks and Goal Kicks</p>
<p>Corner kicks occur when a defending unit kicks the ball out of bounds on the sideline running on its own ‘goal’ side of the field. The ball is placed on the corner sideline on the side it went out of bounds.</p>
<p>Goal kicks occur when an offensive unit kicks the ball out of bounds on the sideline of the defensive units’ ‘goal’ side of the field. The ball is placed in front of the goal.</p></li>
</ol>
</li>
<li><p>Fouls</p>
<p>Fouls do not force a turnover of possession. Redeployment following a foul occurs the same as in the Out of bounds situation.</p></li>
<li><p>Redeployment and units that have already taken turns</p>
<p>Redeployment does not normally reset whether a unit has taken its turn. If the unit placed next to the ball in a dead ball situation has already taken its turn, it gets a free turn taken immediately following deployment, when play resumes.</p></li>
</ol>
<h2>Initiative</h2>
<p>For the time being, MFFA uses the older per-unit turn order from MF0 (p. 136). Enough with the hutching bellyaching, you yabbies.</p>
<p>Players roll 1d10 for each unit, placing the die next to the unit. Initiative starts at 1 and counts up. When you reach a unit’s initiative roll in the count, remove the initiative die next to the unit, that unit takes its turn.</p>
<p>If two units have the same roll, when their number is reached, reroll the initiative dice. Lowest roll goes first with the next highest reroll going immediately after. Once all of the rerolled ties have been resolved, the initiative count continues as normal.</p>
<p>In a dead ball situation, the initiative count does not reset.</p>
<h3>Coaching</h3>
<p>Coaching adds a layer of complexity to initiative determination. It may slow down the game a bit, but it allows for extra tactical decisions.</p>
<p>Coaching allows players to take control of the assignment of initiative to each of their units. Both players roll a number of initiative dice equal to their units, then take turns assigning to initiative dice to their units. The defensive player chooses first. After initiatives are assigned, the initiative count starts and counts up as normal.</p>
<h2>Dice systems</h2>
<p>As in MF0, frames have 2 white dice representing the frame chassis plus other dice representing up to 4 additional systems. Frames get the usual vanilla MF0 benefits for having fewer than 4 installed systems (see, e.g., MF0 p. 64).</p>
<h3>Red dice</h3>
<p>Red dice represent the ability of a frame to shoot or pass the ball on offense. Unlike the vanilla MF0 rules, there are two legal ranges for red dice on offense: direct and artillery. Systems granting hand to hand dice are not rolled on offense.</p>
<p>When shooting, you must score a successful hit on the goal using the difficulty table from MF0 to score a goal. When passing you must score a successful hit on your ally to successfully pass the ball. You must declare the range you will be targeting at the beginning of your turn.</p>
<p>On defense, red dice represent steals (hand to hand range) and slide tackles (direct range). Systems granting artillery dice are not rolled on defense.</p>
<p>Red dice use a special scale that is different from the movement scale. See Movement Scale and Shooting Scale</p>
<ol>
<li><p>Passing and shooting</p>
<p>When in range for a shot or a pass, the player must roll a number of <em>hit dice</em> equal to the <em>shot value</em> minus the blue <em>defense value</em> of any units in the line of fire. Any units in the line of the pass or shot act as cover, using the normal MF0 cover rules. If there is doubt, consult the MF0 cover rules to determine if a unit is in the line of fire.</p>
<p>If the rolled hit dice successfully <em>score a hit</em>, then the ball goes where the offensive player wants, into the goal or into the possession of another unit. Use Damage chart 2 from the MF0 rules (Hit target on a 5 or 6) if there is no other unit between the shooter and the target. Use Damage chart 4 if there is a unit between the shooter and the target. (Hit target on a 6)</p>
<p>Failure to score a hit is called a <em>fumble</em>, and causes the ball to go wide somewhere in the range of the shot at the opposing player’s discretion (be reasonable here, it’s not going to <em>fly backwards</em>). This may cause the ball to go out of bounds, into the possession of a unit, into the goal, or into the field of play.</p></li>
<li><p>Stealing and slide tackling</p>
<p>When stealing or slide tackling, <em>scoring a hit</em> results in the ball coming into the stealing or tackling unit’s possession. The stealing or tackling unit’s player rolls a number of <em>hit dice</em> equal to its red <em>shot value</em> for the steal or tackle attack minus the blue <em>defense value</em> of the unit in possession of the ball.</p>
<p>Always use Damage chart 2 for stealing and slide tackling. On a roll of 5 or 6, the steal or slide tackle scores a hit. Possible rule: the player who slide tackles to steal the ball may choose to destroy a system on the opposing player’s unit.</p>
<p>Failure to score a hit is a <em>fumble</em>. Nothing special happens, unless the player rolls a 1 on one of the hit dice.</p>
<p>Rolling a 1 on a hit die during a fumble results in a foul. See <em>Fouls</em>.</p></li>
</ol>
<h3>Blue Dice</h3>
<p>Blue dice systems remain the same as blue dice systems in the normal MF0 rules. However, rather than representing armor, they represent the ability of a unit to gain or maintain control of the ball.</p>
<h3>Yellow Dice and Green Dice</h3>
<p>Yellow and green dice systems remain the same as vanilla MF0.</p>
<h3>Hot rodding</h3>
<p>A player may choose to hotrod a unit’s system by sacrificing a system to gain a free action with one of the other systems after the unit has taken its turn.</p>
<h2>Taking a turn</h2>
<p>Taking a turn begins with target declaration. For the defensive units this will generally be the unit in possession of the ball. For the offensive unit in possession of the ball, this could be targeting a fellow offensive unit for a pass or targeting the opposing goal.</p>
<p>Attacks don’t do anything to units without the ball. Save that animosity for the war.</p>
<p>The turn proceeds as per the vanilla MF0 rules. Any unit that would be activated with the normal MF0 turn rules, i.e. the target of a steal attempt or a pass, takes its turn as per those rules.</p>
<p>For example: If a unit equipped with a blue system is in the line of fire and has not rolled to determine the blue <em>defense value</em> this turn, defending player must declare a target for the unit, roll all of the unit’s dice, and assign a <em>defense value</em>. The unit takes its turn as normal when its initiative dictates.</p>
<h2>Movement Scale and Shooting Scale</h2>
<p>Normal vanilla MF0 scale is 2”. <em>Shooting scale</em> for MFFA is 2”. <em>Movement scale</em> is double that, 4”, to represent the agility of these hot-rodded sportsframes.</p>
<p>Using two different colored rulers (e.g., 1 red for shooting and 1 green for movement) is a good way to distinguish <em>movement scale</em> and <em>shooting scale</em>.</p>
<h2>Licensing note</h2>
<p>This rules expansion for Mobile Frame Zero is made in accordance to the Creative Commons, Non-commercial, Share-Alike license of the original game.</p>
<h2>Playtesting</h2>
<p>If you’re interested in playtesting these rules go for it. I’d love to hear suggestions and reports here in the comments or on <a href="https://twitter.com/zerosalife">twitter</a>.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Redesign exercise]]></title>
<link href="http://zerosalife.github.io/blog/2016/06/11/redesign-exercise/"/>
<updated>2016-06-11T11:13:29-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/06/11/redesign-exercise</id>
<content type="html"><![CDATA[<p>From <a href="http://www.gamedesignworkshop.com/">The Game Design Workshop book</a>:</p>
<blockquote><p>One good way to train yourself in the design of game mechanics is to
challenge yourself with controlled design exercises in which you take
an existing game system, set a new player experience goal, and make
changes to the system to meet that goal.</p></blockquote>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[What makes a game feature complete?]]></title>
<link href="http://zerosalife.github.io/blog/2016/05/21/what-makes-a-game-feature-complete/"/>
<updated>2016-05-21T10:47:38-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/05/21/what-makes-a-game-feature-complete</id>
<content type="html"><![CDATA[<p>Of course, the makeup of a list of game features depend on the particular project in question. This list of features required to make <a href="http://asherv.com/threes/"><em>Threes</em></a> feature complete comes from <a href="http://asherv.com/threes/threemails/#threemails">early on in the published emails about the game’s development</a>.</p>
<h2>Features</h2>
<ul>
<li>Core Game</li>
<li>Tutorial</li>
<li>Menu Flow</li>
<li>Music</li>
<li>SFX</li>
<li>Monster Animation</li>
<li>Game Rotation (for the iPad/PC)</li>
<li>Leaderboards</li>
<li>Achievements</li>
<li>Twitter</li>
<li>Skin Packs</li>
<li>IAP</li>
<li>(Undos?)</li>
<li>Puzzlejuice Cross-promotion</li>
</ul>
<p>The final product has certainly received many times over more polish than the time spent implementing these features and the list may have changed. But, from time to time, it’s nice to see what other successful projects have deemed necessary to get a better sense of how to plan for your own projects.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Mario Design Interview]]></title>
<link href="http://zerosalife.github.io/blog/2016/04/30/mario-design-interview/"/>
<updated>2016-04-30T09:48:07-04:00</updated>
<id>http://zerosalife.github.io/blog/2016/04/30/mario-design-interview</id>
<content type="html"><![CDATA[<p>In the interest of preserving an interview that could easily vanish into the ether following a Nintendo website redesign, I’m going to collect some wisdom from <a href="http://iwataasks.nintendo.com/interviews/#/wii/nsmb/0/0">an Iwata Asks with Shigeru Miyamoto</a>.</p>
<!--more-->
<h2>Elements of a fun game</h2>
<ul>
<li>“A fun game should be easy to understand – you should be able to take one look at it and know what you have to do straight away.”</li>
<li>“It should be so well constructed that you can tell at a glance what your goal is and, even if you don’t succeed, you’ll blame yourself rather than the game.”</li>
<li>“The people standing around watching the game have also got to be able to enjoy it.”</li>
</ul>
<h2>Form follows function</h2>
<p>A repeated theme that emerges in the interview is that constraints of the hardware or display technology restricted the designs. Miyamoto and crew had to come up with simple, evocative designs that communicate the function for each of the entities in the game world.</p>
<p>Following the maxim that a fun game should be easy to understand, straightforward designs that show an entity’s purpose in an easily recognizable manner communicate the designer’s intent to the player.</p>
<h2>Try it and see</h2>
<p>Gameplay staples from the Mario series that seem unequivocally well-designed emerged from a simple iterative prototyping process.</p>
<p>The designers had an idea, for example, “What if we double the size of our main character?” They then implemented it in a development build of the game, and tested it out to see if it was fun. By testing this particular design choice, the designers came up with the idea for a mechanic in the game to double the size of the main character as the result of picking up a power-up.</p>
<h2>Communicating through design</h2>
<p>The simple introduction of the mushroom power-up is a clever bit of communication through the design of a level. By this point the player has likely learned that stomping on Goombas squashes them. The placement of a power-up block above the player situates it so you have no choice but to hit it when you try to squash the Goomba. By keeping the player trapped under a line of blocks, the power-up has time to bounce off of a pipe (blatantly informing the player that power-ups can bounce) and the player is likely to run into it, thus discovering the power-up’s purpose.</p>
<p>Notice how the construction of the level (one of the elements of fun), its design, makes it easy to understand (another element of fun) the function of these power-ups. At no point is it necessary to wrest control of the player to blabber on about what power-ups are, why the player may want to pick them up, what other power-ups exist in the world, <em>et cetera, ad infinitum, ad nauseum</em>.</p>
<h2>Feel and smell</h2>
<p>These two terms refer to the subjective aesthetic impression of the perceptual and interactive elements of a game. These can be a nice way to distinguish your game from the others out there.</p>
<p>Miyamoto uses the term smell to refer to the overall impression that a game leaves on your senses. By really making a distinct impression on the player, the experience is likely to stick, leading to replayability.</p>
<p>The feel of a game refers to the subjective feeling the player gets when pressing buttons on the controller. Every game uses the same controller (more or less), but the feeling that a player gets upon pressing a button can differ drastically depending on the game. Miyamoto mentions, and I agree, that sound effects have a huge impact on the feel of a game.</p>
]]></content>
</entry>
</feed>