Archive for the 'development' Category

Bientôt l’été in bèta & end of pre-orders.

Nov 24 2012 Published by under development,project

We interrupt this program for a special announcement:

Bientôt l’été is done!

It took a bit longer than anticipated. I was originally hoping for an October release but decided to take a bit more time to streamline and polish, in response to the great feedback I have received on the alpha releases. Thank you for that!

You can still pre-order the game and play the new beta version. I would very much like to hear if you find any errors. Pre-orders will be available until the end of this month (30 November).

Comments Off on Bientôt l’été in bèta & end of pre-orders.

Many deadlines.

Sep 17 2012 Published by under development

By releasing unfinished versions of Bientôt l’été, I’m creating a schedule where I find myself working towards a deadline often. Right now, I’m working towards a version of the game to demo at IndieCade. This will be the third alpha release.

The difference between regular production and working towards a deadline is a difference in priorities. Certain issues, which need to be dealt with for a final release, can easily be ignored in an unfinished demo version and are thus postponed. Other features, such as controls, require a certain, perhaps premature, optimization for demo purposes.

A deadline offers an extra motivation to get things done. That sort of pressure can be good and bad. But given that the deadline is not the final deadline, one can always minimize the stress. Perhaps unduly. Multiple deadlines add to the workload and thus extend the production time. But they also stimulate. So perhaps the work is done more quickly.

I have a nagging feeling that this constant priority of a deadline is pushing me to make rash decisions that are perhaps not necessary. Every form of prioritization has its victims. And when working under time pressure, shortcuts are often taken. On a good day, it feels like the game is rapidly approaching its final state. On a bad day it feels like building a cardboard house.

Comments Off on Many deadlines.

Characters, virtual actors.

Sep 13 2012 Published by under development

All the animations that Laura Smith is making for Homme and Femme in Bientôt l’été make me want to create more games with the same characters. Why bother designing new characters for every game? Maybe we should think of them as actors and have them re-appear in multiple situations.

I guess we do something like that with the Girl in White. She made her first appearance in the original 8, then appeared in The Path and is now coming back in the remake of 8. And we have plans for her in other games too.

But every time she appears, we make a new model. And all animations need to be redone. That makes sense, though, because she’s a different age every time.

Femme and Homme could remain the same age. Their attire was specifically designed for the seaside situation. So that might need to change anyway. Although. It would be interesting to play with these characters, and even similar controls (like they always look away from the camera), in different situations.

Ah! If only game making were simpler. Then we could play with such ideas!

Comments Off on Characters, virtual actors.

Thank you, alpha-players!

Aug 31 2012 Published by under development

So far people who have commented on the second alpha version of Bientôt l’été, agree that the game has improved since the first alpha release. So it looks like releasing early was a smart move. Many issues were caught in the first round and addressed in the second, improving the experience for all.

It’s funny how you just don’t know as a designer. You don’t know what things will work and what things won’t. Given this experience, it seems rather absurd that anyone would want to release a game without first showing it to a few friends, peers, fans. Yet this is exactly what we have done several times at Tale of Tales.

One could make a case for the purity of the expression of an artist, who should only follow his own instincts. But game development is so long and intense that even the most talented artist must stop seeing clearly after a while. Also, the decisions remain your own. Some players make suggestions, but most reports are about problems. And you have to come up with solutions. On your own.

Comments Off on Thank you, alpha-players!

I want to polish.

Aug 05 2012 Published by under development

I wish I could switch to fine tuning already. I yearn for that feeling of control. To polish the game until it is perfect. But from the looks of my to do list, there will not really be time for that before the planned released date of October. There’s a lot of small functional things and minor features I need to deal with. I may need to postpone release to have enough time for polish.

We have never done this before. We have always released on time. This is the first time in our existence as a company that we could actually afford to give ourselves more time. And I have scheduled for a buffer period before we start the next project. So maybe I should take my time with Bientôt l’été.

Comments Off on I want to polish.

Working blind.

Aug 03 2012 Published by under development

Addressing item after item on my to do list is going remarkably well. But I’m a bit anxious about what Bientôt l’été will be like after all these changes. I don’t have time to play it. I just continue to add and fix individual elements without knowing very well how this will impact the whole.

This is kind of exciting because the game remains an unexplored mystery for me too this way. But it’s nerve-wracking to not know. Chances are I won’t be able to thoroughly play the game before release of the next test version. So I will become one of the alpha testers myself. Let’s just hope the program doesn’t start crashing.

Comments Off on Working blind.

Double the development, remove the prototyping.

Jul 16 2012 Published by under development

The visual logic of Bientôt l’été is starting to be messy. Several system have been redesigned multiple times and fragments of old logic are still present here and there, in case I change my mind. Systems are also entangled with each other more than they probably should be in an attempt to control what should be running at which time.

All of this is a result of designing the game while programming it. And I should probably remake the whole thing. But there’s no time.

In the future, I’ll schedule two production phases: one in which I figure out the design and that ends with alpha-testing and tweaking. And a second one in which the entire game is built again from scratch, according to the specifications defined in the previous phase. I imagine this second phase could be quite fast. It’s generally easy to program something if you know what the end result should be.

Prototyping is not sufficient as a first phase for the types of videogames that we want to make. Because our games are not just about interactions but rely on all facets of the software (visuals, sounds, processes, interactions, etc) for full impact. And it is especially important for testing the game on potential players that this impact can be achieved. I imagine for other games, testing if the players are having fun is sufficient. And I imagine this can be done through interaction testing alone. But we have other expectations.

Prototyping is also horrible if you are hoping to achieve a relatively specific mood. Playing around with placeholder graphics opens up a whole range of possibilities, most of which are simply not suitable or not feasible in the project at hand. This leads to frustration. Also, focusing purely on interaction tends to happen in a sort of cultural vacuum. You start creating things that feel nice, that have a certain basic emotional effect, that appeal to our animal instincts. But, apart from the fact that I find this very difficult to do, technically and design-wise, this is just not where I see our work. I’d much rather have broken mechanics in a virtual world that resonates with the player’s life experiences, than build an absurd world around some mechanics that happen to feel nice.

Comments Off on Double the development, remove the prototyping.

Fix problems or prevent them?

Jul 02 2012 Published by under development

I’m extremely happy with the comments that players of the alpha are sending in. Many of them help me identify and fix issues in the current design. This will certainly lead to a better piece than I could have made with only my own instincts to go on. Sometimes, when on your own, you simply overlook things. Also, the frequency at which certain issues occur in comments of different people, helps me judge priorities.

Though it can feel frustrating at times as well. Some comments recur and although I agree with them, I may not be able to fix the problem within the scope of this project. The suggestions that people make are great, I would love to see them in the game, but it’s impossible to implement them given budget and time available.

One could say just increase the budget and then the extra profits generated by a better game will make up for the higher production cost. But my mind doesn’t work like that. I don’t want to spend the rest of my life refining a single idea. There’s other things I want to make. I want to move on. Time is a more important factor to me than money. I cannot add years to my lifespan.

So perhaps the smarter strategy is to change the design in order to prevent the issues from occurring.

For instance, several players have mentioned feeling a certain discomfort with the café interior scene. They want to see the other player, they want to see more of the interior, they want to put their hands on the table, they want more control over the conversation, etc. All of these are valid and I completely agree that they would improve that scene. But I don’t think I can get all this done on time.

I think these issues are caused by the scene creating an expectation of fidelity that the game then does not deliver on. So maybe a cheaper solution is to not create this expectation. In this case, perhaps the interior scene should be more abstract, more stylized, more symbolic. Maybe the characters should not be visible at all. And maybe the table should not look so realistic. Maybe this should look more like a game, a board game, a game with abstract tokens, that takes place in the holodeck layer.

I don’t know yet. I personally like the realism in this scene. So I may ultimately leave it, optimize it where feasible, and leave the rest as a simple difference in taste. We’ll see.

A question still remains. Maybe it is a good sign that people have expectations. Maybe this means that the scene did work to some extent, that it did touch them in some way. And perhaps a more stylized presentation, while potentially less problematic, may not touch them. Is this a choice between unfulfilled desire and no desire at all? Can a work of art take the risk of imperfection?

While I am rather pleased with the look of this scene, none of the playtesters have made a comment on it. Maybe this is one of those cases where realism just goes unnoticed and thus is hardly worth the effort. Maybe it’s more interesting if the beach scene is the closest we get to realism in the game, its aesthetics being far less conventional.

Comments Off on Fix problems or prevent them?

Faster faster faster

Jun 06 2012 Published by under development

We need a faster way to create games. Or I need to become smarter to reduce the scope of the ideas I have.

It’s important to take one’s time to explore an idea thoroughly. But after a while I think myself in knots that I can’t get out of.

Long production cycles give one plenty of time to doubt everything. I’m sure this has advantages. But I wish it was an option. I wish, if only once in a while, I could make something quickly. Just act upon an idea and get it out there, and then judge whether it was any good. And move on from there.

Big productions not only tend to reduce my focus, the longer they go on the more important it becomes that they do not fail. Otherwise all the time was wasted. But that’s a stupid attitude for a creative process.

Comments Off on Faster faster faster

Production schedule.

May 21 2012 Published by under development

After the mini-crunch of preparing a build for IndieCade, I have compacted my to-do list to a little over 80 tasks. I completed 1 of those tasks today. At this rate, I should be working on Bientôt l’été full time for the next 4 months to get it done within the foreseen schedule. That is not going to happen since my kids have holidays in the summer months, and there will be several other interruptions.

So either I work faster or we change the schedule.
I don’t think it’s possible to cut any more.

This is not counting any of the polishing that I want to do without scheduling. I just want to look at the game and tweak what I see. Preferably for a month or more.

Neither included is time for playtesting. Bientôt l’été is not aimed at the masses but I still want to make sure that the most obvious issues are dealt with.

So perhaps we will get an opportunity for the apparently required “hype” before release. If I schedule things well, perhaps I can work on cosmetics first, to a point where the work can be shared. And deal with under-the-hood problems while people -hopefully- get excited about our pretty screenshots and movies.

Comments Off on Production schedule.

Next »