{"assets":[],"author_link":"author\/radiolemon\/","author_name":"RadioLemon","cat":"LD #35","categories":["LD #35"],"comments":[],"epoch":1461535740,"event":"LD35","likes":16,"metadata":{"p_key":"85164","p_author":"RadioLemon","p_authorkey":"0","p_urlkey":"295925","p_title":"Post-Mortem of Monster Village and Ludum Dare as a whole","p_cat":"LD #35","p_event":"LD35","p_time":"1461535740","p_likes":"16","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1460678400","event_key":"33","event_name":"LD35"},"source_url":"2016\/04\/24\/post-mortem-of-monster-village-and-ludum-dare-as-a-whole\/","text":"<p>This was my 9th solo Ludum Dare! In the past I\u2019ve made, in order: <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-25\/?action=preview&amp;uid=18002\" target=\"_blank\">Ethan\u2019s Bike<\/a> for LD 25, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-26\/?action=preview&amp;uid=18002\" target=\"_blank\">Consumerism<\/a> for LD 26, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-27\/?action=preview&amp;uid=18002\" target=\"_blank\">10 per<\/a> for LD 27, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-28\/?action=preview&amp;uid=18002\" target=\"_blank\">One Kingdom<\/a> for LD 28, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-29\/?action=preview&amp;uid=18002\" target=\"_blank\">Ordained<\/a> for LD 29, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-30\/?action=preview&amp;uid=18002\" target=\"_blank\">Silence \u2026 Noise<\/a> for LD 30, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-33\/?action=preview&amp;uid=18002\" target=\"_blank\">Blob<\/a> for LD 33, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-34\/?action=preview&amp;uid=18002\" target=\"_blank\">Spaceman 34<\/a> for LD 34, and, finally, <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-35\/?action=preview&amp;uid=18002\" target=\"_blank\">Monster Village<\/a> for LD 35.<\/p>\n<p>Over the events, I\u2019ve noticed improvements in<\/p>\n<ol>\n<li>Attitude<\/li>\n<li>Programming Skill<\/li>\n<li>Self management<\/li>\n<\/ol>\n<p>However, what has stayed the same is<\/p>\n<ol>\n<li>Art Skill<\/li>\n<li>Music Skill<\/li>\n<li>Anti-patterns<\/li>\n<\/ol>\n<p><strong>Attitude<\/strong><\/p>\n<p>In terms of personal growth\u2026<\/p>\n<p>I entered Ludum Dare 25 as a self-conscious, anxious developer. Here are a few quotes from December of 2012:<\/p>\n<ul>\n<li>\u201cI am going to be attempting to make an entry for the famous LD!\u201d<\/li>\n<li>\u201cI\u2019m a VERY new code writer\u201d<\/li>\n<li>\u201cI am a bit guilty because how how AWESOME other people\u2019s submissions are\u201d<\/li>\n<li>\u201cI actually just jumped in with a \u2018YEAH THIS IS GREAT\u2019 attitude, and no thought is a bad thing for design\u201d<\/li>\n<\/ul>\n<p>Underlying these words was this attitude:<\/p>\n<ul>\n<li>I don\u2019t want to be seen as arrogant for entering the Ludum Dare<\/li>\n<li>My game sucks, and someone is going to tell me \u201cget out\u201d<\/li>\n<\/ul>\n<p>This attitude was constructed from my own circumstances in life, and, as a seasoned Ludum Dare-er would know, is not how things are.<\/p>\n<p>Ludum Dare is a community where everyone rapidly develops a game to the best of their ability, and then gives constructive feedback and encouragement to others for their own games. Ludum Dare is a community of learners. When you are learning, there is no \u201carrogance,\u201d just people sharing their thoughts about each others\u2019 games.<\/p>\n<p>Now my attitude towards Ludum Dare is:<\/p>\n<ul>\n<li>Let\u2019s make something<\/li>\n<li>My game sucks because I\u2019m learning<\/li>\n<li>Look at what other people made!<\/li>\n<\/ul>\n<p>This is vastly different because it is geared towards learning and looking at what other people made to get new ideas. Learning works best when you aren\u2019t afraid to try.<\/p>\n<p><strong>Programming Skill<\/strong><\/p>\n<p>I can implement features a lot quicker than before. I have more to say about this under \u201canti-patterns\u201d<\/p>\n<p><strong>Self management<\/strong><\/p>\n<p>At the start, my usual routine was:<\/p>\n<ol>\n<li>Let\u2019s make an MMO<\/li>\n<li>Oh god this is too much<\/li>\n<li>Let\u2019s make a decrepit skeleton of an MMO<\/li>\n<li>My code is too messy, I\u2019m going to give up now<\/li>\n<li>Submit<\/li>\n<\/ol>\n<p>Now:<\/p>\n<ol>\n<li>Let\u2019s make an MMO<\/li>\n<li>Let\u2019s scope down to the basic mechanics<\/li>\n<li>It\u2019s too small now, let\u2019s make it a <em>tiny<\/em> bit bigger<\/li>\n<li>Finish the scoped down version from step 2<\/li>\n<li>My code is too messy, but I have some of what I planned done<\/li>\n<li>Submit<\/li>\n<\/ol>\n<p>You can see that the start and end points are the same, but the middle points have seen a significant improvement.<\/p>\n<p><strong>Art Skill<\/strong><\/p>\n<p>Compare Ethan\u2019s Bike with Monster Village: it is the same. This is because I focus on programming far more than drawing, and I have not put much effort into improving my art skills. I blame laziness.<\/p>\n<p><strong>Music Skill<\/strong><\/p>\n<p>Half my games don\u2019t have music, and some don\u2019t even have sound effects. This is due to focusing on programming.<\/p>\n<p>Needless to say, if I ever join a development team, I\u2019ll definitely be a programmer.<\/p>\n<p><strong>Anti-patterns<\/strong><\/p>\n<p>For all of my games, there is a \u201cPlayState\u201d class that essentially holds the entire game. I\u2019m aware that this is bad design, yet, in the interest of implementing features quickly, this is what usually happens.<\/p>\n<ol>\n<li>I have my game planned out<\/li>\n<li>I made a few flowcharts and diagrams on how this is going to be implemented<\/li>\n<li>Well designed part of the code is implemented<\/li>\n<li>I need to implement the rest of my code now<\/li>\n<li>I didn\u2019t plan for how a few features were going to be implemented<\/li>\n<li>Mud ball<\/li>\n<\/ol>\n<p>This is a large improvement over my first game, which was<\/p>\n<ol>\n<li>Start making game<\/li>\n<li>For every feature<\/li>\n<li>If it is data, make a \u201cThing\u201d class<\/li>\n<li>If it is an action, make an \u201cActionManager\u201d class<\/li>\n<li>Go back to step 2 until everything has its own class<\/li>\n<li>Cobble<\/li>\n<\/ol>\n<p>A humorous example of this was the all powerful PercentManager class from <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-25\/?action=preview&amp;uid=18002\" target=\"_blank\">Ethan\u2019s Bike<\/a>:<\/p>\n<blockquote><p>package com.horsentp.ld25;<\/p>\n<p>public class PercentManager {<\/p>\n<p>public PercentManager() {<\/p>\n<p>}<\/p>\n<p>public boolean calcPercent(int stat) {<br\/>\nboolean percent;<br\/>\nif(stat&gt;=10) {<br\/>\npercent = true;<br\/>\n} else {<br\/>\npercent = false;<br\/>\n}<br\/>\nreturn percent;<br\/>\n}<br\/>\n}<\/p><\/blockquote>\n<p>As time goes on, and as I make more stuff, I get a little better at ensuring good design principles, but the PlayState-mud-ball problem persists across <strong><em>all of my projects.<\/em><\/strong><\/p>\n<p>I believe this is due to \u201cquickly implementing features.\u201d<\/p>\n<p>I believe that if I take a step back every time I see a mud ball forming, and make some design changes right then and there, I can avoid the point where my code becomes so messy that I abandon my project.<\/p>\n<p><strong>Type of games<\/strong><\/p>\n<p>I noticed that most of my games in Ludum Dare and outside of Ludum Dare have the following gameplay elements:<\/p>\n<ul>\n<li>Management<\/li>\n<li>Platforming<\/li>\n<\/ul>\n<p>and I attempt to make this gameplay<\/p>\n<ul>\n<li>Fast paced<\/li>\n<li>In depth<\/li>\n<\/ul>\n<p><strong>Obstacles<\/strong><\/p>\n<p>But \u201cin depth\u201d usually becomes \u201cwhy is this so complicated\u201d (See <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-28\/?action=preview&amp;uid=18002\" target=\"_blank\">One Kingdom<\/a>). \u201cFast paced\u201d becomes, ironically, \u201cslow paced\u201d (See <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-29\/?action=preview&amp;uid=18002\" target=\"_blank\">Ordained<\/a> and <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-30\/?action=preview&amp;uid=18002\" target=\"_blank\">Silence \u2026 Noise<\/a>). Over time I have become better at making games \u201cfast paced\u201d (<a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-33\/?action=preview&amp;uid=18002\" target=\"_blank\">Blob<\/a> and <a href=\"http:\/\/ludumdare.com\/compo\/ludum-dare-34\/?action=preview&amp;uid=18002\" target=\"_blank\">Spaceman 34<\/a>), but less so with in depth games. A major reason for this is likely player feedback. Most of the games I make that attempt to be in depth end up being confusing. They\u2019re confusing because there aren\u2019t a lot information sources for the player to use while playing the game. In an attempt to make the game less cluttered, it becomes more confusing. GUI programming and design as well as gameplay design is what needs to be worked on to improve a game\u2019s \u201cunderstand-ability.\u201d Not surprisingly, bad GUI programming is always because of\u00a0 mud-ball style PlayStates.<\/p>\n<p><strong>Other notes<\/strong><\/p>\n<ul>\n<li>I drink too much coffee during every Ludum Dare<\/li>\n<li>I feel like I wrote beautiful code until I get a bug that takes 4 hours to fix<\/li>\n<li>I always implement animation, but I don\u2019t have the time to make them<\/li>\n<\/ul>\n<p><strong>In conclusion<\/strong><\/p>\n<ol>\n<li>Thank you for reading<\/li>\n<li>Patience is key<\/li>\n<li>Beware mud balls<\/li>\n<li>Keep making games so you get better at managing mud balls and yourself<\/li>\n<\/ol>","time":"April 24th, 2016 10:09 pm","title":"Post-Mortem of Monster Village and Ludum Dare as a whole","title_was_empty":false}