peachtreeoath 2016-04-19 04:01
Those monster screams will give me nightmares haha
Foon → Ludum Dare Explorer → LD35 → Noble Sacrifice
By kharza
| Category | Rank | Score | Count | |
|---|---|---|---|---|
| Audio | 704 | 1.60 | ||
| Fun | 870 | 2.69 | ||
| Graphics | 1074 | 1.87 | ||
| Innovation | 1078 | 2.13 | ||
| Overall | 1093 | 2.56 | ||
| Theme | 1116 | 1.93 | ||
| Coolness | 1808 | 32 |
Those monster screams will give me nightmares haha
Hi, I think this game is unfinished, but the concept is good :) I have a hack'n'slash, too. You find it at my itch.io account at my gamelist (That game is not my Ludum Dare game, but I think I will like it)
I applaud the effort of trying to build an ARPG in 72 hours, but that's not so say it's a good idea.
I'm not going to criticize the entry as it's unfinished. Rather I'll give you some pointers on rapid development based on the timelapse and the postmortem.
- Smaller scope (features? kill them!). In this case 3D world & graphics, real-time battle system, inventory/loot system (with GUI) and audio creation/implementation turned out to be too much to bear. Rule of thumb: there should only be at most one system/feature you are unsure of, preferably none. Having made all sorts of systems before and being able to reuse knowledge, code and assets from previous projects is a big bonus (which only comes with experience unfortunately)
- The most important thing with a tight deadline is to have a fully (80% at least) functional prototype ready at the half way point. If you can't achieve this either the design is over-scoped, you under-performed or external forces ruined everything (power outages and the like, you know the stuff). Cutting features and focusing on bringing the prototype up to speed can still save the project, but it’s not going to be easy.
- Creating and implementing graphics should start after the prototype is finished, not one moment before. Up until that point everything should be using temporary "programmer graphics" (i.e. default cubes and spheres). There's no need to create temporary graphics that sort of resemble humans/animals/etc. They look just as bad as cubes (maybe even worse) and take much more time to slap in.
- Audio last. If the main output method of your entry is not completely audio based (which is usually the case), then audio is your last priority. Creating audio yourself also eats up more time than just downloading some off the internet. The jam rules allow this and it is much faster. The internet is full of royalty free sound effects and music. Researching a few good sites before the jam is beneficial.
- Teamwork is a big boost. A well managed team can pull off truly great things (this is a skill of its own, of course). Teamwork also allows to parallel process tasks. If someone only wants to work with audio, they can do that from the word go (and it’s not away from the programmer’s time). Basically some of the above rules can be circumvented with more hands on deck.
That’s about it, hopefully this advice is helpful. Keep at it and you’ll do great!
Thanks for all that HuvaaKoodia! Some great advice in there and I noticed you write great posts in general (lotsa cool gifs :))
I had a bunch of stuff I could have re-used but I set out to do the compo, so I ended up sticking with the compo rules.
Interesting idea and realization
Oops, I left the pdbs in the zips. Sorry about all the many wasted jigglybytes. Updated the zips sans pdbs.
Wait who am I kidding? You probably all played webGL :D