{"author_name":"nesis","cat":"LD #30","comments":[],"epoch":1409508660,"likes":1,"metadata":{"p_key":"26332","p_author":"nesis","p_authorkey":"2726","p_urlkey":"61759","p_title":"Post-Compo Design Iteration","p_cat":"LD #30","p_event":"LD30","p_time":"1409508660","p_likes":"1","p_comments":"0","p_status":"UPD5","us_key":"2726","us_name":"nesis","us_username":"nesis","event_start":"1408665600","event_key":"24","event_name":"LD30"},"text":"

This post is\u00a0about developing my game Matters of Perspective for after Ludum Dare. In it, I’ll talk about\u00a0a quick level editor I made to save tons of time, and how I’m reworking\u00a02D physics for better player experience.<\/p>\n

If you haven’t seen my game Matters of Perspective<\/a>, a game about changing perspective from sidescroll to perspective to explore eerie rooms, please do check it out<\/a> and let me know what you think!<\/strong><\/p>\n

Even if you don’t rate it, any\u00a0feedback in the comments is very valuable to me!<\/p>\n

Here’s a quick gif showing a change in perspective:<\/p>\n

\"\"<\/p>\n

Level Editing<\/strong><\/p>\n

I’ve spent some time figuring out the fastest way to iterate level designs. A fast iteration time means a better level design is approached much sooner. During\u00a0Ludum Dare, I manually placed a ton of cubes (around\u00a01500-2000!) in all the levels. Iterating those designs was painstakingly slow, and took roughly the last 16-20\u00a0hours of my time. After trying a few methods, I’ve settled on writing my own simple editor for level geometry.<\/p>\n

With this new level editor,\u00a0I threw together a large level in about 30 mins, iterating the design\u00a0extremely easily.\u00a0Iterating a level’s design\u00a0includes improving navigability, layout, wall heights, directing\u00a0the player’s\u00a0view, hiding an easter egg, etc. Here’s an example of what I threw together:<\/p>\n

\"physicsTesting1_1\"<\/a> \"physicsTesting1_2\"<\/a><\/p>\n

 <\/p>\n

It looks like creating good levels is going to be\u00a0a heck of a lot easier than I thought \ud83d\ude00<\/p>\n

Reworking 2D Physics<\/strong><\/p>\n

As you could expect, the physics in the compo version of the game were hackishly put together to have something playable, rather than something that was necessarily the best experience for the player. 2D sidescrolling was\u00a0achieved with a\u00a0SphereCollider, doing various 2D-style checks to make it work like a 2D character controller. The biggest\u00a0problem\u00a0with this approach\u00a0is ensuring the sphere can pass through gaps as desired. At least once during play, players usually\u00a0find\u00a0the sphere\u00a0catching on\u00a0geometry that should<\/em> be\u00a0the foreground or\u00a0background.<\/p>\n

This issue can be fixed by instead using the 2D physics system in Unity3D. However, this brings up another issue. The sidescrolling I want to do is all done on a horizontal plane, with gravity going down along the Z-axis. The sidescrolling built in to Unity3D’s 2D physics is all done on a\u00a0vertical<\/em> plane, with gravity going down along the Y-axis.\u00a0To make matters more tricky, 3D colliders (like ones I could use to collide with a\u00a0Sphere) don’t collide\u00a0with 2D colliders at all, ever. In Unity, 2D and 3D\u00a0are two totally\u00a0separate physics\u00a0systems.<\/p>\n

To address this issue, I’ve used\u00a0procedural generation. In the editor,\u00a03D geometry and colliders are\u00a0created (a rectangular prism with changeable size), then 2D\u00a0colliders are generated during play. Depending on the player’s height, different 2D colliders are enabled and disabled, which ensures players won’t catch on “invisible” geometry as they run around in sidescroller mode.<\/p>","time":"August 31st, 2014 1:11 pm","title":"Post-Compo Design Iteration"}