Now:
October Challenge 2014
Ends in:

Coming Soon:
Ludum Dare 31
December 5th-8th, 2014

PST: 6 PM
*EST: 9 PM
UTC: 02:00

ConstructionPlease excuse the site weirdness. Mike is making and fixing things. Clocks are probably wrong. Colors are place-holder.

Ludum Dare 31:
Ludum Deals
???
 
Recent:
MiniLD #XX

Another Castle Post-Mortem

Posted by
December 29th, 2012 3:20 pm

Another Castle Logo

The third Ludum Dare our team has participated in! Here we’ll post our individual thoughts about our game. If you haven’t played it yet, go do so! 

What Went Right

Rose

  • Teamwork / Friendship: The four of us have worked on two other LD games, and have gone through college together. We work comfortably around each other and are not afraid to take risks/try new things. We have a handful of inside jokes that kept us giggling throughout the jam.
  • Google Hangouts: Amazing how technology can bridge thousands of miles! We more or less were able to collaborate despite all being remote.
  • Art: I have a lot of fun designing the quirky characters. I wanted to lean toward the whimsical and silly with my character designs. The ‘Goat’ sub-theme proved to be a fun inspiration. Also put more attention into animation than previous jams: animated in Flash instead of the silly Photoshop animation tool.
Billy-Progress

Iterations for the main villain.

sprites

Cast of characters.

Johan

  • Teamwork: We coded together on the same project without stepping on each others’ toes. We also wrote tools that theoretically would let content creation be more separate from coding so we didn’t block each other. Levels and other settings were set up in XML where we had previously just put everything in code. Theoretically, it would have made content creation (aside from the raw art/sounds) extremely quick once the engine was set up.
  • Google Effects: I don’t always use video chat systems, but when I do, I prefer Google+ Hangouts.
  • Music/sound quality: The sounds came out pretty nice considering how long it took to make them!

Vu

  • Task Separation: Once we had the game idea mostly figured out we were able to jump right into working. The tasks just seemed to split up on their own. Me and Johan worked with the same project in Dropbox. It was amazing how we hardly stepped on each other’s code.
  • Data-Driving: Johan did a really good job of making an XML parsing system and data structures to store and retrieve content. It made tuning and modifying the game extremely simple. We could make dozens of levels in just a few minutes if we wanted.

What Went Wrong

Rose

  • Art Consistency: I am usually a stickler for consistency, but this time I was focused too much on the technicalities and little details. The colors felt too muted for the villainous-yet-whimsical feel we were going for, and the logo style is completely different from the game style. A year+ in the industry makes me really critical of my work :/
    I also never got around to the UI/layout of information, which meant that some screens looked like art with default text slapped over it. Ugh.
poop

Poop.

  • Wasted Time: Not enough time spent brainstorming and fully fleshing out the game design.
    We were no longer in college, which meant we all had relatively healthy sleep schedules and couldn’t stay up as late as we normally do. 3 out of 4 of us had to work on Monday, making Vu the only one working on the game that day.
    The team was split up in three different timezones, which basically meant there was only a window of a few hours a day where all four of us would be in Hangouts at the same time.
  • Scoping: You would think that as game jam veterans, we would have learned to scope games accordingly now. But I think this time we didn’t take into account the lost time on Monday.

Johan

  • Incomplete Design/Scope/Work/Timezones: We had a lot of ideas but didn’t really take into account just how much time we would lose on Monday, since three of us work fulltime on weekdays. We brainstormed late Friday night and I could only work the full day on Saturday. On Monday, we didn’t have final music or any sound effects yet, and we couldn’t get in touch with Hal due to work, so when I got home (with a little less than an hour left!) I ended up taking/slightly polishing one of our drafts and making as many sound effects as possible! A good bit of those sounds didn’t quite make it into the submission version of the project, but will be in the post-jam version, whenever we feel ready to post it up.

Vu

  • Late Start: Friday was the last day of my 8 month co-op and so my coworkers wanted to take me to see the Hobbit after work. It was fun, but it meant that I would not be able to join the team until saturday morning, so I missed out on a lot brainstorming and idea generation. I felt like this head us back a lot since everyone had to wait on me before we could agree on an idea and start working on it.
  • Distance: Although we were able to collaborate well using google hangouts and skype, not being collocated meant that we wouldn’t have nice things like whiteboards, post-its, and just being able to look at each other’s works directly and give immediate feedback and inspiration.
    Additionally, when we work together it’s easier to stay up all night and work harder because we can see everyone else working hard and not sleeping either.
  • Slow Prototyping: It look a lot longer than usual to get a prototype of the game up and running. We couldn’t really gauge the gameplay until the game was basically done. We had a lot of trouble deciding key aspects of the game such as whether or not the play should have HP, do enemies have HP?, where do enemies come from? These were things we should have had locked down before we started working.
  • All Alone: On Monday everyone had to work except for me so I had to put together the rest of the code by myself and lacked support for sound, art, and general feedback on the gameplay. This put a lot of stress and pressure on me.
    I was scrambling to get all the basic screens and generally code in. I wanted to make sure that we had everything that makes a game feel more like a complete work than just a gameplay prototype. I wish I could have spent more time tuning the gameplay and adding features. I feel like I wasted a lot of time tweaking screens and chasing minor bugs on that day. Thankfully we were able to get some additional content and musics and sounds in at the very last second when everyone got out of work.

What We Got out of the Experience

Rose

    • Extra practice working with the technical side and the full art pipeline. Animated bitmaps in Flash instead of Photoshop’s animation tool, which allowed me to create smoother animations. Then had to figure out a quick way to export into a spritesheet, which took some roundabouts (GlueIt) but I was pretty happy with the process. Also, XML!
    • This was the first time any of us had worked on a game remotely, which is a good experience to have.

Flash-scr

Johan

  • Used Torrunt’s Developer Console in a personal project for the first time! Being able to type in cheats/functions that you want to call at runtime was pretty much amazing. Previously, we’d tie cheats to button presses, but in general, it’s tough to remember to clean those up, especially with time constraints. It was also useful when setting up features in code (especially with all of us working on the “same branch” at the same time), since I could do test calls/functionality from within the cheats instead of having to compile and use possibly-broken code.
  • Wrote an AnimationBuilder class that lets you determine sets of Flixel animations in XML without going into the code yourself :D. Definitely going to add this to my code library!
  • Mostly successful completely-remote working experience.

Vu

  • A fresh new game! Although the game is a runner at heart, it feels different because of the spatial layout of levels and environmental involvement. It may not be exactly what we originally planned out but it’s definitely on the right track and illustrates the basic gameplay we planned. With a little more work we could expand the game into what we originally designed and incorporate the feedback we’ve gotten so far.
  • Proof that remote development can work well. The HCI person in me wants to try to improve this and make more/better tools for communicating these kinds of ideas. If we had a simple collaborative animation board I think we would have been able to communicate some ideas better.

 

What Will We Do in Future Jams?

 

Rose

  • I saw in some Post-Mortems that other artists would set up a moodboard before the jam to establish a style and color scheme without wasting time doing it during the jam. I definitely want to try this next time, and make sure the game has a more consistent mood throughout.
  • It would also save a lot of time to have a nice library of fonts, textures, actions, and brushes ready in Photoshop. I spent far too long searching for free ones to use.
  • Timelapse!
  • I wish to be more involved with understanding the code side. I have done an individual jam once, learning AS3 along the way. More of this!
  • Have the full art pipeline set beforehand. I’ll need to research more powerful and up-to-date programs to create spritemaps.
  • I made an animatic to show the programmers how I wanted the prop-throwing mechanic to feel in the game. They did a fantastic job of recreating that procedurally, giving it realistic physics that varied slightly every time. I strongly suggest making plenty of mockups and animatics to make sure the team has the same vision in mind.
mockup

Early background mockup.

Johan

  • I’d like to experiment with some more code/design patterns
  • I’d like to have more patterns/setups in mind, so while not exactly copying code from previous projects, I’d be more prepared to set something up quickly to solve a problem I’d already thought about.
  • Maybe have more of a hand in the gameplay coding…or be quicker with setting up tools. Also goes with my previous point though. Mental preparation!
  • I’d like to better-design how objects in the world are set up, with a better relationship between XML (data) and code (behavior).
  • Design with non-desktop platforms in mind!? It’d be a pretty fresh experience to try that out.
  • Maybe it’d be nice to escape from Flixel at least once. 2D game development has considerably less overhead than 3D, so I’d like to stick with 2D/Flash for game jams. Flixel’s FlxGroups are just too handy though.

Vu

  • For other jams we sometimes have two running ideas that are prototyped extremely quickly (by the end of the first night). I’d like to do that again to prove out ideas before going full force on any one idea. We didn’t have time to do it in this case since we lost a lot of time due to schedule conflicts and time zone differences.
  • I’d like to spend some more time planning out the flow of the game and all the important systems and have them fleshed out way before starting detailed systems
  • Do more art! I didn’t have my tablet or any good art programs on the laptop that I used for the jam so I wasn’t able to help out with art content at all.
  • I’d like to be able to have the game pretty much done way earlier than the deadline so that we can just add polish and do testing much earlier
  • Try out more some unexplored territory. We’ve tended to stick to single player games with a set of core mechanics. I’d like to branch out in future jams and do some games that are more story driven, multiplayer, and/or totally abstract.

 

winScreen

Thanks for reading!

Stay tuned for a post-jam version!

Tags: , ,

2 Responses to “Another Castle Post-Mortem”

  1. uncade says:

    Neat game! Not to be a dick, but I’ve been working on a game titled Another Castle for a while now, if you guys release a post compo version could you please change the name? I couldn’t find your contact info, hence why I’m leaving the comment here. You can check out my game at http://www.AnotherCastleTheGame.com and
    you can reach me by email at david [at] uncade.com

  2. [...] Another Castle Development Post-Mortem [...]

Leave a Reply

You must be logged in to post a comment.


[cache: storing page]