{"assets":[{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/08\/screen0000049215-550x401.png","local":"\/data\/posts\/2014\/08\/9c75fc2154b6797142ed35e8a2c3615d.png"},{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/08\/screen0000025368-550x434.png","local":"\/data\/posts\/2014\/08\/a43e4331ea306601a8e49ee8d7fb953a.png"},{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/08\/screen0000025456-550x410.png","local":"\/data\/posts\/2014\/08\/74ca6b0abd9566ebcdb0e4d52b780d8c.png"},{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/08\/screen0000008929-550x298.png","local":"\/data\/posts\/2014\/08\/fa37bb433ea148ccecdae55c8cd50f9a.png"},{"original":"http:\/\/www.ludumdare.com\/compo\/wp-content\/uploads\/2014\/08\/screen0000033543-550x432.png","local":"\/data\/posts\/2014\/08\/6809409dd7a47652a47fece58ea44334.png"}],"author_link":"author\/nikki93\/","author_name":"nikki93","cat":"LD #30","categories":["LD #30"],"comments":[],"epoch":1409160540,"event":"LD30","likes":7,"metadata":{"p_key":"82638","p_author":"nikki93","p_authorkey":"0","p_urlkey":"293370","p_title":"\u2018Reminisce\u2019 Post-Mortem","p_cat":"LD #30","p_event":"LD30","p_time":"1409160540","p_likes":"7","p_comments":"0","p_status":"WAYBACK","us_key":null,"us_name":null,"us_username":null,"event_start":"1408665600","event_key":"24","event_name":"LD30"},"source_url":"2014\/08\/27\/reminisce-post-mortem\/","text":"

OS\/X<\/a> | Windows<\/a> | LD30<\/a> | Source<\/a> | Timelapse<\/a><\/h2>\n

I decided to write a proper post-mortem on the development of \u2018Reminisce,\u2019 especially on the experience of using cgame<\/a> (my rapid game development engine\/tool) to make a game. For more information on the design philosophy behind and the implementation of cgame do check out the paper<\/a> (slightly outdated \u2014 from May \u2014 also links to a poster) I wrote on it for independent work at university.<\/p>\n

\"screen0000049215\"<\/a>

Editing the title screen in cgame\u2019s in-game editor<\/p><\/div>\n

Concept<\/h2>\n

When the competition actually began at around 7 pm I was out with some friends for dinner and was brainstorming game ideas. I thought maybe something modelled after Avatar, with a fire, water and earth realm, respectively with traps\/enemies that utilize fire power (lava or flames), water power (flooding) and earth power (puzzles involving bushing blocks). Thus gameplay would have a different focus in each world, one on combat, one on speed and the third on puzzles. The idea was ambitious, but I wanted to start with a large concept and simplify it as I went, so that I wouldn\u2019t have to grasp for ideas if I actually had the time later.<\/p>\n

Eventually I dropped the combat (you don\u2019t have weapons and just run away from monsters) and the water world entirely, and the game became mostly puzzle-based with later puzzles stretching across both hell and earth. To make it make sense story-wise I thought, \u201cOk, so you\u2019re a dude going through his memories and they\u2019re good and bad, hence the two worlds, and hence the title.\u201d<\/p>\n

Code<\/h2>\n

cgame made coding really easy with the entity-system model and live-coding. To add a new element to the game, say a door, I drew the sprite in the atlas, added a new entity with a sprite<\/code> system, set the sprite atlas rectangle, created a new door<\/code> system in the code, added the entity to it and saved it as a prefab. All this could be done without ever exiting and restarting the game, seeing changes live \u2014 as soon as I added the open<\/code> property to the door<\/code> system in code it appeared as an editor property in-game.<\/p>\n

Then to add doors in a level later I just hit \u2018.\u2019 in the editor (which means \u2018create from prefab\u2019) then type \u2018doo\u2019 (or even \u2018do\u2019 \u2014 it\u2019s an autocomplete field) hit enter and I have a door! To tie it to a switch I just select a switch and hit the \u2018set\u2019 button in the door system inspector, because cgame figures out that it\u2019s an entity-type property and allows me to select the switch visually.<\/p>\n

\"screen0000025368\"<\/a>

Live-coding the door system (code on bottom right)<\/p><\/div>\n

Ideally I would split the door logic into a generic door<\/code> system which just exposes an open<\/code> property and reacts accordingly, and a specialized door_switch<\/code> system which would have a switch<\/code> property and sets the door<\/code> system open<\/code> property based on the switch. Then you could have generic doors which may or may not be switch based \u2014 maybe have a door triggered by a scripted event instead of a switch, for example. But since this was a 48 hour compo and I was in a hurry I just put the switch property in the normal door system and went on to work on other things.<\/p>\n

\"After<\/a>

After adding the \u2018switch\u2019 property which can be set with point-and-click; also the new code<\/p><\/div>\n

The prefab system also made it easy to construct objects in code. For example, the Lua statement that creates bullets in the quad-shooter enemy system is as simple as follows:<\/p>\n

cg.add {\r\n    prefab = prefab_dir .. '\/hell-bullet-1.pfb',   -- the prefab is preset with the sprite etc.\r\n    transform = { position = p + 0.7 * obj.dir },  -- position the bullet in front of us\r\n    bullet = {\r\n        creator = cg.Entity(obj.ent),              -- bullets like to remember their creators\r\n        velocity = 8 * obj.dir,                    -- make the bullet go forward\r\n    }\r\n}\r\n<\/pre>\n
The cg.add<\/code> function allows easy creation of entities in code, specifying systems and properties in Lua tables.<\/p>\n
cgame\u2019s built-in serialization capabilities made game save\/load super easy. This is in fact how the portals worked \u2014 when you walked through a portal it would save the state of the exited world, then load it back when you came back, thus creating the illusion of time having paused when you left. I never had to write explicit save\/load code for any of the gameplay entities, cgame handled it all automatically.<\/p>\n
Art<\/h2>\n
cgame\u2019s sprite<\/code> system uses an atlas image, so I drew all the sprites into one big atlas. I used Pyxel Edit<\/a> for drawing. Staying true to its live-editing philosophy, cgame listens for changes to the atlas file and automatically reloads sprites in game. So you can draw\/edit sprites in the atlas and they\u2019ll just update in-game without you having to exit and restart. This was great especially for editing the quad shooter animation:<\/p>\n
\"Editing<\/a>
Drawing the quad-shooter animation in Pyxel Edit and watching it update in the game\/editor live<\/p><\/div>\n
Level Editing<\/h2>\n
I built the levels with cgame\u2019s in-game level editor. This generally went pretty smoothly, except for two issues which I found to be pretty relevant from a practical level editing standpoint and would like to tackle before the next game project:<\/p>\n
    \n
  1. If you make a level and then go back and edit a prefab, how should cgame propagate the property changes in the base prefab to all its intances? Right now changes aren\u2019t propagated since the prefab link isn\u2019t remembered (prefabs are basically like copy-pasting without any additional links). Unity, for example, has instance properties override prefab ones only if explicitly set, and so properties that aren\u2019t explicitly set will get the new values from the updated prefab.<\/li>\n
  2. If I play a level a bit and stuff has moved around, then I edit some parts of it and want to keep the changes, how do I merge these changes back into the original level situation given that things have moved due to gameplay? For Reminisce I would always load back the starting level scenario before editing.<\/li>\n<\/ol>\n
    \"The<\/a>
    The editor\u2019s duplication and box select functions allow quick level editing<\/p><\/div>\n
    The cgame editor interface takes a lot of inspiration from vim, emacs and Unity. It aims to be fully scriptable and is thus pretty easy to extend. For example, the physics<\/code> system in cgame provides a visual polygon shape editor. This is simply written as an additional \u2018mode\u2019 for the editor (like modes in vim) and is not in the editor core at all. You could write your own such mode for systems you create \u2014 this could be useful for a camera track system for example to draw spline paths. The editor GUI itself is built with entities in the GUI system, so you could edit the editor GUI in the editor, or add editor buttons to physics<\/code> if you really wanted to!<\/p>\n
    Sound<\/h2>\n
    cgame has a sound<\/code> system too, and the play_sound()<\/code> utility function I wrote in the game code is as simple as follows:<\/p>\n
    \n
    function play_sound(file)\r\n    cg.add {\r\n        sound = {\r\n            path = sound_dir .. '\/' .. file,\r\n            playing = true\r\n        }\r\n    }\r\nend<\/pre>\n
    <\/p><\/code><\/p>\n
    So I just create an entity that\u2019s in the sound<\/code> system. You can see that I\u2019m again using the cg.add<\/code> function I talked about before. cgame doesn\u2019t discriminate, anything can be done this way! And sound properties can be edited in the editor too \u2014 you can change sound gain, set loop state or seek around while it is playing in-game! The actual sounds in Reminisce were generated using cfxr, which is a Mac version of the popular sfxr tool.<\/p>\n
    In all, I learned a lot from this experience. The biggest thing I figured is that I was often really my own enemy more than cgame \u2014 just being tired, sleepy, stupid or lazy. cgame\u2019s strengths played pretty well in a game jam scenario with all the live editing and coding. You\u2019ll see many pauses in the timelapse, all places where I go, \u201cOh, wow, that worked out quicker than expected\u2026 Umm, what do I do now?\u201d and ponder for a bit before moving on. I think it could work really well in the hands of an inspired, motivated and experienced developer, much like the ones churning out great games here at LD. This is why I hope to write some documentation on it soon and record video tutorials and such. I loved my first LD experience as a participant, and am looking forward to many more to come. Thanks for reading!<\/p>","time":"August 27th, 2014 5:29 pm","title":"\u2018Reminisce\u2019 Post-Mortem","title_was_empty":false}