next »

[havchr]

So, the devlog for this should probably have been made aaages ago.
What I'll try to do to remedy that, is bring you through the history of Umami development in a couple of days!

First, Umami started with the idea of making a rhythm game inspired by this:




this happend back in August 2007.

To explain the idea to people, a mock up thing was created by a programmer.
this is why it looks so ugly


This mock up was then handed to McKack, our pixel master, and he created two beautiful mock ups.




a spline system was thrown up and a prototype was developed.
here's screenshots from that.



Tomorrow, I'll move in to 2008 and more prototypes !

[LeFishy]

Hahah I was trying to work out a way to have a branching system in a typographical game I was mocking up in my head and this would work perfectly. It is nice to have a headgame finished.

This is gorgeous. If it has music to match then I'd rub myself in oil and roll all over it.

[Dacke]

Your definition of "ugly programmer art" offends me

[Wander]

hey - dis is fresh! I'm cited to see what goes down in 2008. :-)

2008 is so 2009 of you. ;-)

[havchr]

Your definition of "ugly programmer art" offends me

Well, heh, ugly as in poor photoshop mock-up skills, all the cool looking graphics from that mock-up is taken from the Assembly 2004 invite. 

[havchr]

And so it began. The concept resonated with us as a group, and we began brainstorming around what we wanted, where we wanted to take this.

One thing that surfaced, was that we wanted to make the world you flowed through feel alive. And after the word world was mentioned, we began brainstorming around the concept of a real world, of a character.

We ended up giving birth to an alien which we ended up calling Umami. The first concept on this character was not actually him, but his spaceship.



So we than began working on a prototype with this spaceship.


Some space assets were made
This all happened at the end of 2007/beginning of 2008.
I think we completed the prototype early in 2008.
Yeah, I remember now, we had it running on my laptop when we went to GDC in 2008.

We still didn't know where we would end up with this, but we wanted to make the game to completion. One thing was constantly hunting us though.

It was a rhythm game, it was a simon says game, it was not very different, it was just something old in a different wrapping.

In the next dev.log time machine edition, I'll touch up on how our "it's just a rhythm game with a different wrapping"-view forced us into trying out some odd stuff involving math we never want to touch ever again! (and more pictures of course)

[hyperduck]

Looks sweet, would love to see a video demo! Keep this greatness up!

[havchr]

 

Our face when we met mr MATH!

Oh, let me backtrack a bit. So, we had the prototype working, we had a rhythm game in a level like environment. It was still simon says. After brainstorming on mechanics that would make it a bit different, one thing made more sense than any other mechanic; Jumping.

McKack, our graphics artist had begun throwing up some character designs at this time, and so we envisioned our character running along the path of the level.


He also tried out a different style, so he redid a space concept


And now we figured he'd be jumping as well. Did we think this through, did we really know if this would work together with the rhythm gameplay? Not really, but we wanted to find out.

Concept pictures were made


And jumping explained with pictures


AND then, MATH SMACK ATTACK 

I'll try to explain the crazy math shit going on here. Okay, it's a rhythm game, remember that timing will be crucial. So if we imagine one character (A) jumping up to the upper path, then he'd run there, and the character B would run on the lower path.

Now, the trick is making sure that when that path joins, that the characters now will join seamlessly. That is, be on the very same position at the very same time, no matter which path they have traveled.

The solution we ended up with has something to do with calculating the length of a path, start and end times of the path were calculated from the path below I think. Something like that. If anyone wants to know precisely how it was done, we can go a bit deeper into it, because for us, we coded it once, now it works, and we can't remember what we did exactly :p

Math stuff attack end.

So, we now had some jumping, but no levels to jump in/play with, no real idea on how to use it except maybe jumping over chasms. 

And it had already changed a lot from the initial concept.
Weird how things transform over time

[Dacke]

I love reading this thread! Keep it coming!

Couldn't the timing be solved by having the character move at a constant horizontal speed? That way you couldn't have too steep hills, as it could look wierd if he could run up hills super-fast. But I think you could have gotten away with it. But if you used MATH, all the power to you!

[Kimpix]

Forgot I had an account here... anyways, fun to reminisce!

[havchr]

Hello McKack! I'm pimping out all your pixel history! :p

Let us have some more pixel story!
When we had the ship, we were all like, yeah, our alien will be ridin' all them vehicles and stuff like that. A couple of environments and concept pictures were made based on that.

Like forest and snow




And once again forest was redone in a different style.




One of the effects we really wanted, were growing of things, that the level would feel more alive the better you played.  We called this "a grow effect". I threw together the most insane hackish tool ever created by man, to see if there was a good technique to get the grow effects like we wanted them. http://dl.getdropbox.com/u/1581708/umamiHistory/lolTool.wmv Here is a short video of that tool.
Notice how none of the buttons have any descriptive texture, at all :p

Oh well, we never became happy with how that worked, so we ended up putting those effects on the backburner for quite a bit.

Another thing we really wanted, was to be able to release this on PSN.
We created a video of our pc prototype and sent a mail about who we were and such.
This is the video we sent: http://dl.getdropbox.com/u/1581708/umamiHistory/umproto.wmv

What did Sony tell us, what did we do with the prototype?
More stuff tomorrow.

[havchr]

Dacke: We tried all sorts of hacks, but the only way it worked for us, was with the math way.I guess it depends how much freedom you want in the level design and stuff like that.



We began all the processes of being allowed to develop this game for PSN. Basically, what this means, is you have to get your concept approved.

I don't know how much I'm allowed to say about this process, but we got concept approval for a PSN release of Umami.

This was back in April 08. We said to ourself, we'll release in March 09!
...
The first big project is always the hardest! (I hope :p)

McKack focused a bit on the character:


Our character was done more work on


brought into 3d


in 3d


later brought back to 2d with more facial expressions.


Sketches of facial expressions


More about our level design and how we went on to create levels for our game later this week!

[hyperduck]

I wanna hug this game. so hard.

[godatplay]

Moar plz!! 

[havchr]

Moar plz!! 

It'll come, but we're having some issues figuring out how the first iteration of the tool looked like and how the first levels where made. Kris Jet, the guy in charge of level designing is at home remembering. This very night, he lies in bed, remembering.

Hope to have the continuation of the dev.log tomorrow

[sloopygoop]

I can't wait for the ending of this story, and if I had a PS3, I'd play this in a heartbeat.  This looks like a great game and I'm very intrigued.

[Krisjet]

Hi gals and guys,

I'm one of the level designers on Umami, I'll tell you a little bit about how levels evolved throughout development.

In the beginning, this was the extent of planning put into our level designs:



We didn't know what would work and what wouldn't. We had all played rhythm games before, and we had also played a lot of platformers, but we didn't really know what would happen if we threw them both together.

We understood pretty quickly that the music would have to guide the level design in a pretty intricate manner, taking the player speed into account and what sections of each song contained what we felt were the best rhythm patterns. Spacing the level out, having some rhythm sections and some jumping sections works, but as players get better they're able to do both at the same time. The sections where you have to pick up notes while you dodge enemies and pick up coins are by far the most challenging and fun. It's a bitch to balance the difficulty though.


The levels in Umami have evolved quite a bit since the early beginning. We started out having too much focus on rhythm gameplay, and too little on platforming. Imagine a straight level with arrows scattered about, with some platforms you could choose to jump to. It wasn't exactly what we were going for. I've attached this pie chart to show how NOT to make a rhythm platformer:



Putting in enemies and gaps where you could horribly plummet to your death shifted the focus a bit, but making the game more challenging does not always equal more fun. We kept the enemies but we tried to keep the vicious death plummeting to a bare minimum. When we threw coins into the mix it all started becoming more interesting.

We soon figured out that coins are a lot of fun. They add other interaction than just hitting the beat at the right time, they are voluntary so you're not punished if you don't pick them up, and they're great for guiding a player in the right direction.



Since Umami moves at a constant (and sometimes pretty high) speed the player needs to make decisions pretty fast, and having coins that can guide the player worked out great.

Right now our levels have shifted to being more platform-focused than earlier, making it more of a 50-50 split between platforming and rhythm gameplay.

Next time we'll show some more fantastic art from our pixelpusher McKack!

[Hideous]

  @ the awesomeface expression

[havchr]

, Hideous, just come with any feedback, no need to seal lips

Another thing being constantly talked about, was how fast-paced a level should be..

Uhm, let's see, where in the timeline could this dev.log story possibly be now?
So, Kris Jet was doing the initial first levels.

What I remember of one level in particular, was that it was very tall (vertically oriented), and that the camera didn't follow/show you enough to make informed choices.
There were some leaps of faith, and sometimes you'd be raped after leaping.

Level creation is done by using mainly two programs. The level editor, and Acid Music Studio. In Acid Music studio, we'd map out the note patterns using midi notes. Each midi track corresponding to paths in the level. Then we'd just export the midi file and load them into the level and it'd be filled with notes!



and



Levels became better as we figured out how to make cool levels and had good input from playtesters.

Also, I talked to one of the game dev students here in Hamar, he wanted to know more details about the curve and time stuff that makes the game work. I hope to find time to make a proper article about it, with more details.

[cmv]

Hi everyone, I'm one of the programmers behind this crazy game.

I thought I'd fill in some lore about the initial level development, from a pure technical aspect.

In the beginning, we were considering creating our level editor in .NET to avoid having to write our own GUI. This was quite early in the project though, and the game engine was just starting to take form, so we were still investigating the best approach. Eventually we settled on using either wxWidgets or Qt. There was one slight problem though. We had a very important deadline in what I think was February 2008, where we needed to have something playable to show. We had just started converting our pipeline to PS3, so the levels we used to test with at that point was created using some really ugly hacks involving lots of cursing and hardcoding. This took forever. One tiny adjustment meant a complete recompile, which drained a lot of precious time. About 20 hours before the deadline, we came up with an even uglier hack to speed up the process somewhat, which was just a way to move platforms around using the PS3 pad, and outputting the resulting positions as C++ code (we had no I/O at that point). Basically a really really primitive WYSIWYG editor. This worked surprisingly well, and we ended up having a 2min long level a couple of hours before the presentation.

After this life-saving hack, we figured we'd save a lot of time by just writing the entire level tool that way, and so we did. The first iteration was a major pain in the ass to work with. It felt really awkward to use, mostly due to having each button do a hundred different things with some "clever" use of pop-up menus when holding down the shoulder buttons. Even though it was a pain, some of us got used to it (ok, ok, *I* got used to it. The others wanted to strangle me for conjuring up this beast). Eventually, we passed the tool onto our graphics guy, McKack, and it became very clear that something needed to be done as our productivity was pretty much down at 4-5% when it came to level authoring.

A few days after receiving the tool, McKack came up with a better way to handle the interface. He built a mockup application demonstrating how the buttons should be mapped, and how the thing should operate. It was still supposed to run inside the game, using the PS3 pad. After a few days (or was it weeks? time flies by..), it was time to put the new concept into action. I sat down on a Friday evening, and three days and several bottles of caffeine later, we had something that did some of the things it was supposed to do, and operated more or less the way it was supposed to. I think it took a week or so before it could do everything the old tool could do, but using McKack's concept.

Turned out it worked pretty well, at least at the time. This tool even featured marvelous innovative features, such as picking, scaling and rotating, all features the first iteration could only fantasize about (he he, kinda explains the need for a new one). The screenshot havchr posted above is the latest version of this iteration.

I'm not gonna spoil too much about where the tool was headed (e.g. where it's at now in terms of productivity), as I'm sure it will pop up in the later logs.

EDIT: One thing I forgot, the first iteration and the WYSIWYG hack was heavily inspired by the way the Lego Star Wars guys PS2 tool worked, which they demonstrated on Nordic Game in 2008, so the deadline I thought was in February, was actually in May/June. Funny how time becomes blurry when all you do is sit around coding all day.