About | Rules and Guide | Sign In/Create Account | Write a Post
Construction1990’s Internet Montage? No!
Please excuse the site weirdness. Mike is fixing and making things.
Ludum Dare 31 — Coming December 5th-8th 2014!

  • ??? Begins: in 8 days, 8 hours, 25 minutes, 2 seconds
  • October Ends: in 9 days, 8 hours, 37 minutes, 2 seconds
  • Ludum Dare 31 begins: in 44 days, 9 hours, 25 minutes, 2 seconds
  • (FYI: Clock might be off) | Ludum Dare 31: Real World Gatherings (Now Open!)

    [ October Challenge 2014 | Resources | Submit/Edit | View All ]


    About DigiTec

    Entries

     
    Ludum Dare 27
     
    Ludum Dare 26
     
    Ludum Dare 24
     
    Ludum Dare 24 Warmup

    DigiTec's Trophies

    DigiTec's Archive

    T1me Twist0r post jam and post mortem

    Posted by
    Friday, September 6th, 2013 3:51 pm

    I think the most learning from this jam came from a 1 hour postmortem we did with another team who also submitted an entry. We got together and discussed things like technology choices, how long we planned and most importantly what we felt went wrong. Of course many of the problems existed in past jams as well. It is hard to truly learn from your mistakes being creatures of habit. But we keep trying and eventually we’ll get it right.

    Our entry was T1me Twist0r, a game of 10s mini-games. Our triumph was to ensure that the mini-games work together seamlessly in a clock like manner and to this end we succeeded. We also added quite a bit of custom audio and some funny effects. We also felt this went over well. Don’t want to spoil too much, so if you haven’t played and voted on the game do that before you continue.

    So how did things play out?

    Technology:

    We decided to go pure HTML 5 and Javascript. We’ve done this in past competitions as well. This works well on a large array of devices, but can evidence performance problems. Our team is expert level at understanding and working with Javascript performance problems as it directly relates to our day jobs, yet we still find the fill rates of the different browsers on lower end devices to be true bottlenecks. In our case there were some glitches in the animation and things weren’t quite as seamless as we had hoped, but overall we think we hit the mark.

    For hosting we used Windows Azure. Generally this works out really well. We got one complaint of slow load times for the game. We traced that down to what looked like a really slow outgoing bandwidth amount and not related to latency or server load of any sort. In the future, it might be good to use CDN services for larger files especially media components like audio or large sprite strips.

    Development Environment:

    Visual Studio 2012 + Visual Studio Tools for GIT + GitHub + Azure…

    This worked out way better than we thought. The VS 2012 to GitHub connection was seamless. We had a single merging problem that we were able to resolve by going to the command line. Other than that we had 2 developers partying on master and no other conflicts. We pushed directly to master and had Azure listen to and deploy the site directly from there. Turnaround times were seconds in the single digits.

    There was some confusion around a .deployment file to pick which project to deploy, but that was easily configured. In the end we also need to branch the jam version from the post compo version so we created a branch and built a second website that pointed to the jam submission. We still had the ability to push game breaking bug fixes this way. Again, branching and building out a second site was also a seamless experience.

    Not having issue tracking built into VS is a big issue, but with 2 developers we didn’t even notice. Sticky notes are where its at. In the future it would be nice to have GitHub Issues as a window inside of Visual Studio, which is actually quite doable using the Web Browser window and just pointing it at your GitHub repository.

    Planning:

    We planned all of Friday. At least 4 hours of planning before we wrote the first line of code. We did have the source control already set up so we weren’t worried that our technology wouldn’t work for us starting Saturday morning. At the last hour on Friday we pushed some basic sprite framework code up in preparation for Saturday.

    I will probably never do a Ludum Dare again where I don’t plan this hard. We had so many ideas and were able to think on them all night while we slept and have a really good feel for the best ideas in the morning. Had we started coding the previous night on some major features it would have been a big mistake.

    Our failure in planning was in establishing the later task list. We knew what we were going to do, but we didn’t have a task list. Previously in our jams we had done more much task list creation and that allowed us to scale out to more people. Somehow having fewer people we didn’t see the point and it hurt us in the end. Every now and then I’d poke my head up, say I had checked something in, would grunt for a few seconds, and then proclaim my next conquest. Not very good if you want to maximize your working time, but great fun.

    What Went Wrong:

    It starts with a capital P and ends with a laytest. We needed more of it. Earlier. We needed playable aspects of our game done earlier to facilitate it. Reality check. Your first choice is not your best choice, instead without playtesting it becomes your ONLY choice. Doesn’t sound as good when you call it your ONLY choice does it? We would have fixed 2 or 3 very minor coding issues that affected our released game without having to have all of our initial players experience it. Better initial experiences would certainly lead to better scores in the Jam.

    The second thing starts with a capital P and ends with a laytest… Wait, I see what you did there… Some of our mini-games didn’t work quite as expected in all scenarios. Trackpad users are slower to mouse around for instance and so found the games more challenging than touch users or mouse users. This was unfortunate. We also had a game where it wasn’t obvious that your taps were actually doing anything. Too much filtering and noise added to the results was making it sometimes do nothing when it should have been giving the user solid visual feedback that they were doing the right thing.

    Never underestimate user frustration with waiting. The challenge is 10seconds, but if they finish faster, give them something for it. We initially gave nothing and had to gamify the left-over time. We actually had some of this in our planning, but wait, we didn’t write down a task list and so it got easily forgotten in the time crunch. Always give the user positive feedback. When they do something fast, give them bonus points whether or not they have to wait.

    Finally at one point in the game we had some issues around the transitions. As a result we coded in a little countdown timer to the next level. This actually made the game play way too slow and after we had fixed all of the transition issues we never removed the countdown. When we implemented that countdown “Brilliance”, but when we failed to see it lacked further use in the final game, “Idiocy!” Really think about how each of your temporary decisions are impacting the game and make sure you revisit short term decisions to see if they can be made better.

    Conclusion:

    We hope everyone can learn from some of our insights. With just under 2 months to go for the October Jam we are already thinking of ways to improve one of our existing games to ship quality. I sure hope we apply everything we learned from this Jam and finish a truly stunning submission. See you in October!

    DigiTec

    Evolutionary Side Scrolling Shooter

    Posted by
    Monday, August 27th, 2012 3:10 pm

    So we are live with our game, Natural Selection – You vs the World.

    The premise is simple, fly around an infinitely scrolling canvas and shoot through the ghosts of everyone who has ever played. The gameplay will evolve as people last and live longer and as people develop different flying strategies and techniques. When a lot of people die at a specific distance, expect a wall of enemies at that point in the future. When you die, see the names of your killer and hope it isn’t yourself from a previous run.

    Voting Page: http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=14372
    Direct Link: http://naturalselectiongame.azurewebsites.net/
    This was a huge learning curve for us since we built out the server network to scale on Azure SQL and Azure WebSites. If you get a server down screen, come back in a day, we are currently working on provisioning our machines to a larger instance.
    Enjoy!
    Justin Rogers (DigiTec)

    The client side portion of our game is almost done. Here are the code stats and list of retired tasks.

    Posted by
    Saturday, August 25th, 2012 10:47 pm

    So we are doing an HTML 5 based game targetting canvas. Only minor math and sprite libraries we previously generated have been used. So far here are the check-in stats:

    5 developers, 7085 LOC, one of the devs is pumping out 257 LOC per hour worked on the project.

    Completed list of items (not in any particular order):

    Canvas Sprite Engine
    Parallax Tree to enable a star field
    Multi-level star field
    Interactive Environments
    Collidable Obstacles with special properties for bullets
    Single Screen State Manager (we didn’t want screens or transitions, everything flows based on a single screen state)
    Collision Detection Engine (a multi-layer collision detection engine for handling enemies, bullets, etc…)
    Over 80 custom sprites and graphics
    Multiple Ship Designs
    Full interactive in game credits
    Input Manager
    Multiple Input Modes
    Konami Code Support
    Ghost Replay Mechanism
    Windows Azure Server setup for Leaderboards and some Secret Sauce
    Powerups
    Interactive Game Over and Replay
    A Highly Optimized Bullet System for optimum Performance

    Its fully playable now and we are incorporating our core evolution concept now. Should be fun!


    All posts, images, and comments are owned by their creators.

    [cache: storing page]