Post feature RSS Pitman Krumb - The first week in development Part II

In this article we want to share the lessons we learned when making a small, but relatively complex game in just one week. The game "Pitman Krumb" was our take on the 7-Day-Roguelike-Challenge.

Posted by on

Pitman Krumb – The first week in development Part II (from Jana)

Read the introduction where we talk about our little Roguelike Project.

In the first week we did - looking back on our work now - the mighty 80% work of the whole project. This is the Pareto principle which says that 80% of work are done in 20% of time, and we actually proved it right. The 7-Day-Rogue-Like-Challenge was like a big crunch time full of motivation.

So, how can you do the most amount of work in one week?

Say YES to time schedule!

The most helpful tool, next to the blog on the official challenge page and recognizing the progress of others, was our time schedule. What sounds like a huge barrier for creativity in the working progress helped us in many ways.

  • To start a perfect schedule, you need to know what you are aiming at. We decided to have a board game style to save time which would be otherwise needed for animations and texturing. The game had to also include:

    • a player character
    • monsters
    • different level styles
    • path finding
    • fighting system
    • world sections that fall from above to complete your path
    • automatic generation of the world sections with texture atlas system
    • leveling
    • user interface, with inventory
    • stuff like decorations, fountains to heal your pitman, chests, etc.
    • particle effects
  • The next step is to decide how long you will need for all those steps (realistically + a bit more time just to be sure, because EVERYTHING needs longer than you think). I did all the graphical stuff while Friedrich was working with C# in UNITY3D. Mostly we worked from 9 am to 12 pm daily (which was kinda cool for this week and just for this week).
Pitman Krumb - The first days in development P II

Day 1

The first day (when our motivation was the highest) I did eight characters and Friedrich managed to build a dynamic dungeon which was textured automatically with only one texture atlas. What was very important to me was keeping always the time in mind. I decided to build eight characters that day. When I'm going to spend one hour per character I will work eight hours on modeling, which isn't very realistic, because everything needs even more time than you think of. So I watched the clock while working on every model to spend exactly one hour on it – which didn't quite always stick to, but it was helpful to not get lost in too much poly pushing just for the sake of it.

Pitman Krumb - The first days in development P II

Day 2

While I painted three textures in Photoshop our dungeon gains the possibility to grow while walking through it. This day was a little bit hard for our programmer to do the work for lack of a real straight plan (in comparison to the day before, it was doing more smaller stuff like the player movement). It's also something I recognized myself: When starting the work (modeling little items) you should exactly know which stuff you are going to build. If you break up your work after every item to think about the next one you are wasting a great amount of time. But with a little plan (you see I'm a great fan of stuff like this) you are dividing your work in CREATIVITY (which items do I need and how do they look like (little sketch)) and REALISATION (the stupid but fast completion).

Pitman Krumb - The first days in development P II

Day 3

The day started with a long list of items that would be cool for mines, lost cultures or swamps. At this point of low-level modeling I did no sketch or plan time, but just did as much objects from the list as I could.

On the interactive part of the game the character was now able to attack and die a dramatic death (rising up like a balloon, haha) – which needed some kind of enemies, of course. Their rudimentary AI was part of that day.

Pitman Krumb - The first days in development P II

Day 4

This day I really learned my lesson in scheduling. Its very nice to have eight characters and 27 little objects ... but who is going to unwrap that stuff (i.e. generating correct texture coordinates). Well, just counting the main part and forgetting about the rest (unwrapping, preparing models for UNITY3D and texturing / texture baking) was a big problem that nearly cost me a day and generated a lot of unpleasant work which definitely had to be done.

All the models I did were texture-baked in 3DSMAX and unwrapped with ROADKILL which is quite cool, but not evolved any further.

My learnings for the day: Unwrapping, arranging UVs, exporting to .fbx format and texturing ONE object is something unnecessary to count with, but the process for 35 objects should not be forgotten to integrate in a time table.

Friedrich enriched the look of the game so far by implementing my decoration models. He also managed to get the inventory done, an important asset in a roguelike. This means he started to implement the interface, which is not very funny in UNITY3D because of several restrictions. Thus it ended to be pretty minimalistic.

Day 5

Of course my work of the last days were dragged right into the next day. But I also did some item cards – in 2D! Which was very cool (because I don't do pixeling very often) and easy. No unwrapping just drawing little halberds, shoes, pretzels and stuff like that. Choosing a board game style turned out to be a good idea again. Now all the items you can collect lie just in little stacks on the floor, just like in e.g. Space Crusade (awesome board game BTW). Some people said they are too small to identify, but through color and shape you will recognize them in most cases, hopefully.

Pitman Krumb - The first days in development P II

Friedrich did much to improve the randomness of the game, which also is very important for roguelikes. Randomness is a feature hard to handle because of the amount of frustration that can happen when it's not balanced enough or the boredom coming in when everything is too easy. The problem is that the balancing is something that has to be tested several times and hours, constantly.

We could do the balancing forever, speaking of enemies (strength AND hit rate AND spawning AND speed AND ...), getting hungry, erosion of armor and weapons, finding food, leveling up, etc. Just a bit of a change and an easy game could emerge to something completely unplayable in the next testing phase.

Things that I learned on the graphics side:

  • Plan everything BEFORE you are modeling, painting, drawing, especially while working on a bundle of characters, textures, etc.

  • Make a list of things that you want in your game when it's finished. Use this list also to check if you could (temporally) handle all that stuff in the time you might need.
  • Never forget that – in most cases – you need more time for everything than you think.
  • Never forget the small things, that also have to be done, but are annoying, like unwrapping all the models you made.
  • Choose a style that fits your gameplay and especially the time estimated for implementing it.
  • Even a small game should be tested many times – unless you don't want anybody to play it.
Pitman Krumb - The first days in development P II

Things that Friedrich learned while doing the scripting stuff:

  • What Jana said, mostly. (No clear vision and no plan => motivation goes down the hill.)

  • DON’T use symmetric assets for testing code. You will realize errors in your dynamic mesh generation too late. (I used both: symmetric level maps and symmetric textures. Urgh.)
  • Be consistent with your coordinates. Sounds trivial, but when you’re doing 2D gameplay in a 3D world, those X/Z axes may get in your way.
  • I don’t like the UNITY3D Inspector. It’s just bad that the same window is used for viewing assets data like textures and meshes AND objects in the scene hierarchy.
  • Randomness is an art in itself, if you want to do it correct. Next time we probably will use tools like the magical die editor.
  • The less GUI stuff a game needs, the more I want to program it. ;-)
Pitman Krumb - The first days in development P II

In our next feature I want to talk about why we decided to make an iPhone game out of PITMAN and why it needed more time to polish it than to get those first 80 percent.

If you like this, you can find the RAT KING also on Facebook and become a fan!

social rats
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.