|||| 8 - 15 nov 2014 ||||
7DFPS ...
Dance: What Went Wrong And What Went Right?
Now that 7DFPS is well and truly over (no matter how I spin it), I thought it would be good to look back at how Dance turned out; what works, what doesn't, and what fell by the wayside. Things which didn't make it
  • Configuration options (keybindings, resolution, mouse sensitibity, mouse inversion)
  • In-game textless menu/instructions
  • More visual effects (shadows, AO)
  • Visual identifiers for where the player has to move to
  • Dance step references (pre-dance visual guides for the dance sequences to aid understanding/prediction)
  • Setpieces (plants, chandeliers, upstairs crowds, fountain, wall lamps, cornice detail, tappestries)
  • Additional wall tiles (great archway, dining area, stage)
  • Disable player movement during dance moves
  • Allow the player to exit the dance by moving too far from their position
  • Player character model (randomly suit or dress wearing)
  • Player character customisation (select hat, hair, face, jewlry, clothing type)
  • Character details (faces, hair, hats, jewelry)
  • Character variations (colour, mesh)
  • Character animations (curtsy, spin, improved walk, jumping win animaton, sad lose animaton, dance positions eg: promenade)
  • NPC interaction via user selectable dance moves
  • NPC voices ("de-localisation" by not having a variety of languages)
  • Additional music (composed by Anton)
  • Sound effects (dress ruffles, footsteps)
  • Ambient sound (general murmur, glass chimes, pre-dance orchestra tuning)
  • User defined game scale (like minesweeper) to generate room size and number of dance participants
  • Additional dance steps (spin, cross the floor, break into smaller circles)
  • Post dance stats (time elapsed, number of swaps, number of partners, etc.)
  • Wallflower mode (players can wander the ballroom, examine details, interact with NPCs and observe dances)
  • MacGuffins (a set of mini-stories/motivations for why the player is attempting to reach their target, eg: romantic interest, catch a thief, make contact with spy)
  • Reverse mode (where the objective is to avoid being partnered with the target)
  • Oculus Rift support (requires patched Blender - I might get to it at some stage)
Of this stuff, I'm most disappointed by not having time to get Rift support in. That was one of my biggest inspirations for Dance and it's super sad that I wasn't able to get it in. It's probably clear that what's missing is superficial/atmospheric stuff, and most of it I'm comfortable not having. I think this is a reflection of having good prioritisation. What worked
  • General aesthetic (people have told me it's "charming", and that makes me pretty happy ^_^ )
  • Textureless materials
  • Modular approach (room tiles, character models, etc.) saved my bum when I ran out of time
  • Familiarity with Blender in general helped me work faster
  • Stylised character models were fast to make and fairly easy to work with animation wise
  • Armless models meant I didn't have to worry about arm occlusion
  • Support and encouragement from Mim, Syd, Anton and Hannah was really helpful
  • Getting some prototype positioning code from my Dad helped me avoid some hurdles
  • General concept feels like it has promise
  • Placehodler music feels good (and Anton's advice on tempo was good)
  • Idle animation is simple, but turned out awesome :D
Whilst as a whole, I feel like Dance is a shadow of what I'd have liked to achieve, it's worth acknowledging what worked well. I'm pretty happy with the general aesthetic and the concept. Even though I felt like this was a solo project, the support and encouragement I got along the way, both from the people mentioned here and people in the #7DFPS IRC channel was invaluable. I also feel really good about thrying to modularise my assets and prioritise functionality so that I could hit my bare minimums and still leave room for extras if I had time. I spent a lot of time angsting about placeholder music choice when it became clear that Anton wouldn't have time to do anything. I had wanted to give Anton a lot freedom and so didn't have a preconception of what the music would feel like, and I was super wary of chosing a placeholder track that didn't fit, and nothing I found felt like it was right. Syd offered to help me hunt up music though, and came up with the track that's in there now, which I'm really happy with. Yay. What didn't work
  • Dance sequences are hard to read/identify (multiple player interaction points make it hard to see where the sequences loop)
  • Dance sequences don't offer enough puzzling content and can be solved by staying in whatever ring is opposite to the target and waiting (by making both outer and inner rings rotate both forward and back, more challenging puzzles could be presented)
  • Readability of the overhead screen, particularly the suit character (hats, iconography for indicating significant characters)
  • Menu screens feel cramped and should be more interactive
  • End to end gameplay happened at the last minute, leaving no time for iteration.
  • Fiddling with jMonkey Engine ended up costing me a day and a half
  • Blender bugs (mac sadface) and limitations (proper shadows weren't really achievable) hurt the project
  • Other committments ended up being a huge distraction (slightly related, the SteamLUG team missed out on any direct contribution from me)
  • My change in availability cost me my planned collaborators (by starting and intending to finish a week early, I put myself out of sync with others and messed up plans)
  • Not 100% sure of how well the player interaction works. Should there be some kind of time pressure on players to make things feel more dynamic?
  • Thre are no lose conditions (left out because I had no way to communicate impending loss)
  • I wasn't quite prepared to be working solo (code from my Dad was valuable, but we had infrequent communication and he didn't directly work on the game's codebase)
  • Blender Python documentation (could be an extension of Python documentation culture, eg: inhereted methods not being shown on class pages, often vague details on what parameters mean or should be)
  • NPCs don't have much character
  • The animations are too bland (excluding the idle)
The biggest one here for me is that I didn't get something that was really playable until the last minute. If I were to do this project over again, I'd focus more on having something I could do playtesting on early and be less concerned with nailing the look and feel before I had an actual game. At the last minute, I back and forthed on removing all but one interaction point from each dance sequence in the hopes that being able to see the sequence as a single whole would make the loop point more clear, but I just didn't get enough player feedback before I ran out of time on whether this made it too easy to have been able to make a good decision. Second to that was only being able to give about half of my time to Dance's development (I consider the current day version to be representative of 7 days' worth of work). Next time I do a solo game jam, I'll need to be firmer with making sure that I've stepped back from things which would get in the way. I'm not 100% certain that I regret my decision to check out jMonkey Engine, but I perhaps should have pulled the pin on it sooner rather than trying to work around the issues I was facing. Known Issues
  • Overhead view being rendered on top of everything on Linux sometimes (haven't identified the cause)
  • Keyboard and mouse issues on Mac OS (upstream bug by the looks of things)
  • Player can get stuck between floor tiles momentarily (not 100% sure why this happens) and is ejected at a high velocity
  • Player can exit the room sometimes (caused by not clamping velocity when it gets too high)
  • Player's partner doesn't turn to face the player.
  • Poor performance
A few people have reported bits and pieces. For me, the most significant is that was unplayable on Mac OS. After a lot of fiddling around, I was eventually able to get it to a more user friendly state by packaging the whole Blender application and using autostart (which requires a --enable-autoexec option) rather than just using the lighter weight blenderplayer binary, which fixed problems with keyboard events being interpreted as joystick input. Unfortunately there's not much I've been able to do to work around that. Performance is the other big issue that I encountered, with people reporting slow frame rates on machines I would have hoped it'd be passable on. Some of this is to do with inefficiencies of the code I hurriedly ported from Java, but it seems that some is also inherent to Blender's game engine. I'm going to try and correct a couple of these issues, but I don't want to move much beyond what I feel is 7 days' worth of work for the 7dfps build. I'm currently weighing up whether I'll flesh this out into something that's a bit more of a full game, and if I do, I'm not certain that I'll stick with Blender for it (making it hard to justify investing a lot of high-effort fixes at this point). Check here for downloads (when they become available) and other posts.
7DFPS brought to you by Sven Bergstrom & Sos Sosowski & Jan Willem Nijman | Logo by Cactus Follow news and info about 7DFPS on twitter Games hosted on itch.io