{"author_name":"Gjarble","cat":"LD #28","comments":[],"epoch":1388881140,"likes":3,"metadata":{"p_key":"34031","p_author":"Gjarble","p_authorkey":"5467","p_urlkey":"69575","p_title":"Fly On The Wall: A Postpartum","p_cat":"LD #28","p_event":"LD28","p_time":"1388881140","p_likes":"3","p_comments":"0","p_status":"UPD5","us_key":"5467","us_name":"Gjarble","us_username":"gjarble","event_start":"1386892800","event_key":"20","event_name":"LD28"},"text":"<p>I&#8217;ve always thought the term &#8220;postmortem&#8221; to be an odd one.\u00a0 A game doesn&#8217;t die when it&#8217;s released; it&#8217;s more like a birth!\u00a0 So, I&#8217;m calling this a &#8220;postpartum&#8221;.\u00a0 Not that this is necessarily the best time to start using that term- my &#8220;finished&#8221; game isn&#8217;t really a complete product, and I&#8217;m not too proud of its current state.\u00a0 But anyway&#8230;<\/p>\n <p>Instead of trying to create the most polished game I could in 72 hours, I focused on using the jam as an excuse to force myself to learn something I&#8217;d otherwise put off- in this case, developing a mobile game (which I&#8217;d never done before).\u00a0 As it&#8217;s an uncommon approach to a game jam, this postpartum is as much a referendum on that approach as it is on the game itself.<\/p>\n <h2>The Concept:<\/h2>\n <p><a href=\"http:\/\/www.ludumdare.com\/compo\/2014\/01\/04\/fly-on-the-wall-a-postpartum\/concept-30\/\" rel=\"attachment wp-att-327636\"><img class=\"alignnone  wp-image-327636\" alt=\"concept art\" src=\"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/01\/concept.gif\" width=\"448\" height=\"336\" \/><\/a><\/p>\n <h2>The Result:<\/h2>\n <p><img class=\"alignnone\" alt=\"\" src=\"http:\/\/www.ludumdare.com\/compo\/wp-content\/compo2\/308734\/5467-shot0.png\" width=\"448\" height=\"336\" \/><\/p>\n <h2>What Went Right:<\/h2>\n <ul>\n <li><strong>I learned a new skill!<\/strong>\u00a0 As many drawbacks as my approach has, there&#8217;s the one big benefit: I actually accomplished my goal.\u00a0 Before this Ludum Dare, it seemed like it would be a nightmare to start developing for mobile devices- learning all the considerations that don&#8217;t apply to desktop and web development and getting all the necessary components to cooperate with each other.\u00a0 Now, making my first <em>real<\/em> Android game seems like it will be a lot simpler of a task, though much of that is thanks to&#8230;<\/li>\n <li><strong>The tools.<\/strong>\u00a0 I&#8217;ve been wanting to use OpenFL (a library for developing multiplatform applications using just one codebase in Haxe) for quite some time, but I had problems setting it up before.\u00a0 Those problems have been mostly resolved, and it worked like a charm.\u00a0 Installing the Android tools took\u00a0<em>way<\/em> longer than I anticipated, but thanks to OpenFL&#8217;s capabilities, I was able to develop and test the game in Flash while I waited for the tools to download without having to change huge chunks of the codebase for the Android version. There seemed to be a few things that worked in one platform but not the other, but resolving those issues didn&#8217;t take too much time.\u00a0 I also tried a new IDE, IntelliJ IDEA, because I was tired of Haxe code completion not working in Eclipse&#8217;s Eclihx plugin.\u00a0 Code completion worked much better in IntelliJ, though it appears not to detect files in the same directory as the file in which you&#8217;re working (importing classes from those files compiles fine).<\/li>\n <li><strong>The control scheme.<\/strong>\u00a0 I&#8217;ve heard horror stories about virtual joysticks on mobile games being the Worst Interface Ever, but the constraints of my idea (a limited camera view that may not necessarily be looking at the player character) prevented me from having the player directly touch objects to move them.\u00a0 As such, I worked out a two-&#8220;joystick&#8221; setup that avoids the usual virtual-joystick problem: having to constantly make sure your finger is on the spot of the screen that represents the joystick.\u00a0 Instead of having a joystick at a fixed point on the screen, my game uses wherever your thumb lands as the center point (that&#8217;s what the thumbprints represent in the concept screenshot above; the circles represent where the thumbs have been dragged to), re-centering it every time you touch your thumb to the screen anew.\u00a0 As a consequence, you don&#8217;t have to look at the interface to re-center yourself.\u00a0 It also has the added benefit of allowing people with different hand shapes to play the game comfortably without having to adjust the UI.<\/li>\n <\/ul>\n <h2>What Went Wrong:<\/h2>\n <ul>\n <li><strong>The phone&#8217;s accelerometer.<\/strong>\u00a0 See my <a title=\"previous post\" href=\"http:\/\/www.ludumdare.com\/compo\/2013\/12\/15\/mobile-games-are-hard\/\">previous post<\/a> for details on my problems with that.\u00a0 It set me back about 24 hours, but I still had a whole compo&#8217;s worth of time left to go.<\/li>\n <li><strong>Distraction.<\/strong>\u00a0 I spent Saturday and Sunday working very efficiently and brimming with confidence.\u00a0 Come Monday, boom- my resolve suddenly disappeared as I debated whether or not I could finish something workbale in time, and figuring out how to implement some important bits.\u00a0 I ended up spending many hours just trying to de-stress myself by doing things unrelated to Ludum Dare.<\/li>\n <li><strong>Collision detection.<\/strong>\u00a0 Ironically, the big time-sink that became the reason why my game has absolutely zero polish (and no levels of substance) was <em>not<\/em> one of the many technological experiments I underwent in the making of this game, but rather the inherent limitations of the one tool I <em>was<\/em> familiar with: the Flixel engine.\u00a0 I knew going in that I would have to implement circle-to-square and circle-to-circle collision because Flixel does not support those, and I didn&#8217;t want to spend valuable time importing and figuring out a full-blown physics engine like Nape.\u00a0 I implemented those types of collision easily enough.\u00a0 The problem was that I assumed that circle-to-<a title=\"circular-sector\" href=\"http:\/\/en.wikipedia.org\/wiki\/Circular_sector\">circular-sector<\/a> collision, which I also needed, was just a subset of circle-to-circle collision and would also be easy to implement.\u00a0 I realized too late that the problem was not so trivial, and spent about half of my final day attempting (and failing) to work it out.<\/li>\n <li><strong>The aftermath of the jam.<\/strong>\u00a0 This is the major problem with the approach I tried this LD:<\/li>\n <\/ul>\n <p>I knew that I was probably going to turn in a less polished product than I usually do, because this time, I wasn&#8217;t focused on making the best game possible so much as one that worked under the constraints I set for myself.\u00a0 As I said previously, I was willing to accept that risk this time around, because my goals were different from what they&#8217;ve normally been since I started LD two years ago.\u00a0 However, now that I <em>have<\/em> taken that risk, and I <em>have<\/em> put out an unpolished tech demo, I&#8217;m not so sure I want to do it again.\u00a0 While my idea worked in principle (using the time pressure of the jam as a tool to learn a skill), I made a mistake in choosing Ludum Dare as the venue to do it.<\/p>\n <p>A major purpose of Ludum Dare is to make something you can share with others- both for the joy of being involved in a community, and so others can evaluate your work to help improve your skills.\u00a0 This game is not something I really feel is shareable- not in its current state, anyway (I felt a little dirty submitting it).\u00a0 I&#8217;m well aware of the maxim &#8220;it&#8217;s never too early to playtest&#8221;, but I feel there are limits to that idea.\u00a0 This game isn&#8217;t just &#8220;I didn&#8217;t get to include all the features I wanted&#8221; unfinished; it&#8217;s &#8220;I haven&#8217;t even completed the core mechanic&#8221; unfinished.\u00a0 Because of this, <strong>I actively didn&#8217;t want to play and rate anyone else&#8217;s games<\/strong>&#8211; not only because it would draw unwanted attention to my own game (through the Coolness system), but I feel like if this is what people see of my work, than I have no grounds on which to evaluate others&#8217; work (even though I&#8217;m a student of game design who&#8217;s been doing game jams for years).<\/p>\n <h2>So, will I use this approach to LD again?<\/h2>\n <p><strong>Probably not.<\/strong>\u00a0 I underestimated the level of gratification that comes with trying my best to make the most polished game I can, and I didn&#8217;t realize that redefining &#8220;success&#8221; as something irrelevant to the final product (in this case, the learning experience) takes away all the joy of the 3 weeks <span style=\"text-decoration: underline\">after<\/span> LD.\u00a0 That said, am I glad to have done it?\u00a0 Yeah, I can&#8217;t really complain about having opened the door to mobile development for myself.\u00a0 My technique worked as intended, not for gaining a complete understanding of mobile development, but as a way to prove to myself that I <em>can<\/em> do it without agonizing over it forever.\u00a0 I&#8217;d just rather do this again in a context that has much less of a focus on other people evaluating my work.\u00a0 Maybe I&#8217;ll do it again in a MiniLD- no ratings\/rankings, no pressure.<\/p>\n <p>See everyone next LD!<\/p>","time":"January 4th, 2014 7:19 pm","title":"Fly On The Wall: A Postpartum"}