{"author_link":"\/users\/skosnowich","author_name":"Skosnowich","author_uid":"skosnowich","comments":[],"epoch":1512605720,"event":"LD40","format":"md","ldjam_node_id":69760,"likes":0,"metadata":{"p_key":"106543","p_author":"Skosnowich","p_authorkey":"1000316","p_urlkey":"322353","p_title":"Post-mortem for Electrial Overload","p_cat":"LDJam ","p_event":"LD40","p_time":"1512605720","p_likes":"0","p_comments":"0","p_status":"WAYBACK","us_key":"1000316","us_name":"Skosnowich","us_username":"skosnowich","event_start":"1512086400","event_key":"70","event_name":"LD 40"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD40","removed_author":false},"_superparent":49883,"_trust":11,"author":316,"body":"![Cover.png](\/\/\/raw\/c31\/z\/e15f.png)\n\nThis is my post-mortem of Ludum Dare 40 and our game [\"Electrical Overload\"](https:\/\/ldjam.com\/events\/ludum-dare\/40\/electrical-overload).\nIt was my fifth Ludum Dare in total and I have to admit that this is my first post-mortem.\n\nI wanted to summarize my thoughts on our game and the whole development process.\nFirst off, a short overview summarizing, what we managed to do and what we didn't manage to do:\n\n## What we managed to do\n  \n  - building \n  - random procedural cave generation\n  - power supply and energy network system\n  - automatically mining drones\n  \n## Parts important to me, we didn't manage to do\n\n  - balance the game reasonly\n  - polishing the game and fixing bugs\n  - tutorial\n  - music and\/or ambient sound (at least you can do some music with the transmitters :D)\n  \n## Some nice-to-haves that didn't get into the game:\n\n  - drones mining on their own without relying on a beacon (the initial intention of the beacon was only to force the drones to mine specific parts, so that you can make yourself a way through narrow parts)\n  - the above point would lead to more scattering of the drones, making the game more interesting - currently you have to concentrate on one corner\n  - rework the lightning effects (especially the power transmissions)\n  - add some idle effects to some of the machines (like the one of the generator)\n  - rework the UI, so it doesn't have the Unity look\n  - add post-processing effects\n  \n## Known bugs in Jam version\n\n  - small black lines between the textures on cave walls\n  - sometimes energy generators\/transmitters don't register newly placed drones\n  - drones sometimes mine a second time, even though they are already carrying something\n  - drone particles still playing while in warehouse\n  - drones can't fly over the energy generator\n\n# Theme Announcement\n\nSo it was 3am saturday morning and we were waiting for the theme.\n\"The more you have, the worse it is\".\nWell... not my favorite theme, but my teammate came up with an idea pretty fast.\nThe problem with that idea was, that it was way to over-scoped.\nSo we discussed the core features and thought that we can implement a narrowed down version in 72 hours.\n\n# The Idea\n\nThe idea was to have a procedural generated cave system in which you have to build different machines for harvesting materials.\nWe narrowed the buildable machines down to an energy generator, a droneport, drones, energy transmitters and a diamond press (game goal).\n\nTheme-wise we hoped that we get many drones flying around in the cave, with energy transmitters shooting energy around so you have to watch where you step.\nThe more drones you get and the faster you mine resources, the worse it would get to walk around the cave without being grilled by the lightning bolts.\n\nAfter we had our idea outlined and cut it down to todos, we started developing.\n\n# Developing in a new engine\n\nBefore, we developed our games in Java with the framework libGDX.\nWe tried out Unity this time.\nI had a look at the core features of unity the week before.\nDuring the Ludum Dare I had a blast using Unity, many things are way easier and you have a nice workflow.\nIn the future I am going to stick to fleshed out game engines instead of developing all the boilerplate code myself.\n\nAdditionally to the new engine, we also developed in a new dimension.\nOur previous jam games all were 2D, now we wanted to give 3D a shot.\n\n# Problems\n\nOhhh, there were a lot.\nFirst off, our game still was way over-scoped... especially for a new engine.\nI'm never going to take procedurally map generation into a game jam game again, except for the rare case that we can spare time in the end for it.\nBut never again as a starter feature.\n\nIn the end the map generation worked quite well, but there are still performance issues (even out of memory errors, as I saw >.<).\nBut we had many tiny problems with it, sending us on bug hunts for a good amount of time.\nI'd say that it took away round about half a day of our time, excluding the implementation itself.\nRandom map generation is a cool thing to have, but in a game jam game, where most people will play the game one time and never again... it's just not worth the effort or rather not important enough to invest that much time.\n\nThen there was the energy network.\nWe highly under expected this feature.\nAt one point we had to realise, that there needed to be some sort of priority system in place, so the transmitters transport the energy to the right places.\nAgain.. took more time than planned.\n\nInitially we planned that the drones search for ores themselves, but through the already lost time we decided to simplify the drone behaviour.\nThat sadly destroyed the idea of having drones all around, so the game doesn't really fit the theme anymore.\n\nWe had several more problems sadly, stealing our time to polish and balance the game correctly.\n\n# Conclusion\n\nOur main problem was, that our idea was still too big.\nWe could have dismissed some unimportant features.\nThis probably happened, because we didn't plan enough.\nAfter we got the idea, we started developing very soon after.\nThe past game jams I took way more time to work an idea out.\nTurns out that wasn't lost time, but rather gained time in the end.\n\nThrough all the problems we encountered we lost the really important parts out of our sight.\nThose are polish and fixing bugs, balancing the game so the player has more to do, user experience in general.\n\nI went out of this Ludum Dare with very mixed feelings.\nOn the one hand, I am astonished of what we implemented in the short time, on the other hand... wow, is this an unfinished game experience.\nI sadly can't say, that I am proud of our result.\nIn the end the overall user experience matters, not the features of the game itself.\n\nI probably sound very negative and pessimistic about this Ludum Dare, but all around it was a very important and positive experience.\nWhy?\nBecause of all the faults we made.\nI realised again that the most important part of Ludum Dare is to have a well scoped plan.\nNothing bugged me more than having to implement the core gameplay features until the end of the jam.\nThe previous jams, we were done with core gameplay after the first or maybe the second day, leaving us enough time to polish and balance stuff.\nAdditionally, we got to learn very much about Unity.\n\nEven though I am not proud of our game, I am very happy with all the stuff I learned this time.\nLudum Dare was fun like always!\nI am looking forward to the next game jam. \nNext time with a much smaller game idea and maybe it is better to stick to 2D again.\n\nSee you around.","comments":1,"comments-timestamp":"2017-12-07T00:49:48Z","created":"2017-12-07T00:12:59Z","files":[],"files-timestamp":0,"id":69760,"love":0,"meta":[],"modified":"2017-12-07T00:49:48Z","name":"Post-mortem for Electrial Overload","node-timestamp":"2017-12-07T00:15:20Z","parent":50474,"parents":[1,5,9,49883,50474],"path":"\/events\/ludum-dare\/40\/electrical-overload\/post-mortem-for-electrial-overload","published":"2017-12-07T00:15:20Z","scope":"public","slug":"post-mortem-for-electrial-overload","subsubtype":"","subtype":"","type":"post","version":203100},"node_metadata":{"n_key":"69760","n_urlkey":"322353","n_parent":"50474","n_path":"\/events\/ludum-dare\/40\/electrical-overload\/post-mortem-for-electrial-overload","n_slug":"post-mortem-for-electrial-overlo","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"316","n_created":"1512605579","n_modified":"1512607788","n_version":"203100","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/40\/electrical-overload\/post-mortem-for-electrial-overload","text":"![Cover.png](\/\/\/raw\/c31\/z\/e15f.png)\n\nThis is my post-mortem of Ludum Dare 40 and our game [\"Electrical Overload\"](https:\/\/ldjam.com\/events\/ludum-dare\/40\/electrical-overload).\nIt was my fifth Ludum Dare in total and I have to admit that this is my first post-mortem.\n\nI wanted to summarize my thoughts on our game and the whole development process.\nFirst off, a short overview summarizing, what we managed to do and what we didn't manage to do:\n\n## What we managed to do\n  \n  - building \n  - random procedural cave generation\n  - power supply and energy network system\n  - automatically mining drones\n  \n## Parts important to me, we didn't manage to do\n\n  - balance the game reasonly\n  - polishing the game and fixing bugs\n  - tutorial\n  - music and\/or ambient sound (at least you can do some music with the transmitters :D)\n  \n## Some nice-to-haves that didn't get into the game:\n\n  - drones mining on their own without relying on a beacon (the initial intention of the beacon was only to force the drones to mine specific parts, so that you can make yourself a way through narrow parts)\n  - the above point would lead to more scattering of the drones, making the game more interesting - currently you have to concentrate on one corner\n  - rework the lightning effects (especially the power transmissions)\n  - add some idle effects to some of the machines (like the one of the generator)\n  - rework the UI, so it doesn't have the Unity look\n  - add post-processing effects\n  \n## Known bugs in Jam version\n\n  - small black lines between the textures on cave walls\n  - sometimes energy generators\/transmitters don't register newly placed drones\n  - drones sometimes mine a second time, even though they are already carrying something\n  - drone particles still playing while in warehouse\n  - drones can't fly over the energy generator\n\n# Theme Announcement\n\nSo it was 3am saturday morning and we were waiting for the theme.\n\"The more you have, the worse it is\".\nWell... not my favorite theme, but my teammate came up with an idea pretty fast.\nThe problem with that idea was, that it was way to over-scoped.\nSo we discussed the core features and thought that we can implement a narrowed down version in 72 hours.\n\n# The Idea\n\nThe idea was to have a procedural generated cave system in which you have to build different machines for harvesting materials.\nWe narrowed the buildable machines down to an energy generator, a droneport, drones, energy transmitters and a diamond press (game goal).\n\nTheme-wise we hoped that we get many drones flying around in the cave, with energy transmitters shooting energy around so you have to watch where you step.\nThe more drones you get and the faster you mine resources, the worse it would get to walk around the cave without being grilled by the lightning bolts.\n\nAfter we had our idea outlined and cut it down to todos, we started developing.\n\n# Developing in a new engine\n\nBefore, we developed our games in Java with the framework libGDX.\nWe tried out Unity this time.\nI had a look at the core features of unity the week before.\nDuring the Ludum Dare I had a blast using Unity, many things are way easier and you have a nice workflow.\nIn the future I am going to stick to fleshed out game engines instead of developing all the boilerplate code myself.\n\nAdditionally to the new engine, we also developed in a new dimension.\nOur previous jam games all were 2D, now we wanted to give 3D a shot.\n\n# Problems\n\nOhhh, there were a lot.\nFirst off, our game still was way over-scoped... especially for a new engine.\nI'm never going to take procedurally map generation into a game jam game again, except for the rare case that we can spare time in the end for it.\nBut never again as a starter feature.\n\nIn the end the map generation worked quite well, but there are still performance issues (even out of memory errors, as I saw >.<).\nBut we had many tiny problems with it, sending us on bug hunts for a good amount of time.\nI'd say that it took away round about half a day of our time, excluding the implementation itself.\nRandom map generation is a cool thing to have, but in a game jam game, where most people will play the game one time and never again... it's just not worth the effort or rather not important enough to invest that much time.\n\nThen there was the energy network.\nWe highly under expected this feature.\nAt one point we had to realise, that there needed to be some sort of priority system in place, so the transmitters transport the energy to the right places.\nAgain.. took more time than planned.\n\nInitially we planned that the drones search for ores themselves, but through the already lost time we decided to simplify the drone behaviour.\nThat sadly destroyed the idea of having drones all around, so the game doesn't really fit the theme anymore.\n\nWe had several more problems sadly, stealing our time to polish and balance the game correctly.\n\n# Conclusion\n\nOur main problem was, that our idea was still too big.\nWe could have dismissed some unimportant features.\nThis probably happened, because we didn't plan enough.\nAfter we got the idea, we started developing very soon after.\nThe past game jams I took way more time to work an idea out.\nTurns out that wasn't lost time, but rather gained time in the end.\n\nThrough all the problems we encountered we lost the really important parts out of our sight.\nThose are polish and fixing bugs, balancing the game so the player has more to do, user experience in general.\n\nI went out of this Ludum Dare with very mixed feelings.\nOn the one hand, I am astonished of what we implemented in the short time, on the other hand... wow, is this an unfinished game experience.\nI sadly can't say, that I am proud of our result.\nIn the end the overall user experience matters, not the features of the game itself.\n\nI probably sound very negative and pessimistic about this Ludum Dare, but all around it was a very important and positive experience.\nWhy?\nBecause of all the faults we made.\nI realised again that the most important part of Ludum Dare is to have a well scoped plan.\nNothing bugged me more than having to implement the core gameplay features until the end of the jam.\nThe previous jams, we were done with core gameplay after the first or maybe the second day, leaving us enough time to polish and balance stuff.\nAdditionally, we got to learn very much about Unity.\n\nEven though I am not proud of our game, I am very happy with all the stuff I learned this time.\nLudum Dare was fun like always!\nI am looking forward to the next game jam. \nNext time with a much smaller game idea and maybe it is better to stick to 2D again.\n\nSee you around.","title":"Post-mortem for Electrial Overload","wayback_source":[]}