State Of The Game #2
Aug 24, 2015
It's time for another State of the Game post. The last one was in May, and it's now the glorious month of August and a lot has happened. Part of our commitment to you when doing the Kickstarter was to keep everyone informed on our progress and adventures.
Making games is Fun. I can't imagine doing anything else with my life, but it's also stressful, exhausting and can be demoralizing. It can wake you up in the morning with vigor and excitement and send you to bed with a sense of doom and defeatism. If there was one emotion to describe my mental state at this stage of the project, it would be "overwhelmed."
But that's normal.
Pre-production is the exciting time of a project. Everything is possible and your only limit is imagination. You design and create and dream with reckless abandon. It's the way it has to be.
Then you enter production, the stage we find ourselves in now. It's the stage where the mind of a dreamer crashes into the mind of a realist. You budget and schedule and track every detail as it oozes its way through the process. You become terrified with what you've designed and fight the desire to just hack limbs from the body to cure a disease.
But that's normal.
How We Got Here
Despite the doom and gloom of my opening, the project is in a really good state.
We've come a long way in the five months since I first got the scripting language working...
And where we are today...
A fully functional adventure game and adventure game engine with final art and puzzles and funny dialogs that are showing the promise of what we set out to create: an all new classic point & click adventure game.
The big news over the last three months was the addition of Mark Ferrari to the team. When Gary and I did our Kickstarter, we didn't know how much money we were going to raise, so we described an art style we knew we could do with just Gary as the sole background artist and animator. It truly invoked the era of Maniac Mansion.
When Mark became available, we both knew we had an opportunity to move the art forward. We raised more money than we thought and Mark becoming available full time was an opportunity we couldn't pass up. But it posed some challenges.
The animations needed to change. We're happy with the overall style of the characters, and as we've stated several times, we're keeping with the large bobble heads, but it's been a challenge to figure out how to render them to fit with Mark's art.
Mark is a master of lighting. If there is one thing that defines Mark's art, it's his lighting. I spent an hour on Skype with Mark, him asking questions about the direction each room faced and where the setting sun would be so he could capture the glow of the dimming evening just right. Mark wasn't satisfied with "It's early evening, the sun is setting somewhere over there." He wanted to know exactly where the sun was so he could draw each room with the correct light coming from the right direction.
"I don't think anyone will notice", I said. "Oh yes they will," Mark replied and I think he's right. Maybe not consciously, but the light being right makes things more real and believable. You don't notice it, but you do notice it. Details, no matter what they are, are like that. You don't notice, but you do.
The art is going to be a lot more work than originally planned.
Wiring of the rooms during pre-production went well. David is a machine with that stuff. He is amazingly detail focused and wiring the wire frame rooms up during pre-production went pretty fast.
We cut 25 rooms from the game and the game feels better for it. That wasn't an easy job, but it was a necessary job.
We've added two major puzzles to the game as a result of playing and realizing we need to gate players into some key (and exciting) areas. It will help significantly with the flow of the game.
When the project began, I was faced with a big decision. Do I use engine like Unity, or do I write my own engine?
Countless game devs will tell you to never write your own engine. It's a fool's journey, and I agree with them, except for two reasons:
1) I like building engines. I've been doing it my whole career (and before that) and it's fun.
2) This will be the 4th adventure game engine I've built. There wasn't a lot that was unknown to me, and it felt like a safe journey.
I also enjoy the power of being able to change the engine as I need; adding new features and optimizing (minimizing) repetitive game programmer tasks.
If David or I are writing the same code over and over, or a seemly simple task is taking three lines of code, rather than one, I just change it.
Where We're Going
We're into full production right now. The entire game has been wireframed and 90% of puzzles are functional. We've been able to play through the whole game and get a feel for the world and the puzzles. It's good stuff. I am very happy with the design, story and characters. It feels like a true classic point & click adventure.
That's both a good thing and a bad thing.
I've shown the game to a few people, and they immediately start trying to optimize the UI. "Do you really need verbs?" or "Can all the touchable objects in the room glow?" Or they worry about new players. "Some kind of pop-up help would be nice here." or "How are you going to on-board the user?"
No, no, no. I keep saying. This is a classic point & click adventure game. It's going to turn some people off. We know that, and we don't care.
We're not building a modern adventure game with all the rough edges sanded away and a safety net, ready to catch even the smallest misstep or endless rewarding of the player for the completion of mundane tasks. I know a lot of modern players want to constantly be told how great they are and how amazing they're doing. This is not one of those games. Success is rewarded with the greatest reward of all: New art. Hints are given through well crafted dialog and feel like a natural part of the story. Players are introduced to the game by a slow escalation of puzzle difficulty and a well focused story.
I spend a lot of time doing budgets and schedules. One of the keys to a successful production is knowing everything you need to do. Lists. Lists. Lists. Get every task into a list and start marking them off. You become a machine. But not a machine without feeling. As you build something, you start to see where it's not working, when that happens, don't be afraid to change what you're doing. Don't slavishly follow the lists off a cliff. If something isn't working, redesign it and then update the lists.
David and I are cranking away at game programming. It's exciting to see final art, puzzles and dialog go in the game. At the end of each day, the game feels more done. David does most of the actual game programming with me doing the dialogs and tackling game programming where I know there will be engine changes or features added. It's easy for me to do both at the same time.
We signed a deal with Microsoft to bring Thimbleweed park to the Xbox One. We're very happy about that. We really wanted the game to be on console. It's a whole different audience. Microsoft has a three month console exclusive and after that we'd like to port it to the other consoles, but our ability to do that will depend on getting the money to pay for it. Either by doing a deal (unlikely with the exclusive in place), or the game being successful enough that we can afford to pay for the ports ourselves, or by raising the additional investment. Porting to console isn't something that can be crowdsourced, because none of the console makers have the ability for us give away keys to backers.
Next month we'll start to delve into music. I wanted to get the world defined first, so we know what needs music. Music in adventure games tends to be about where you are, not what you're doing. The area of the game gets scored, rather than events. There are obviously exception for big events or plot altering puzzles, but it's mostly ambiance. I'm looking forward to working with Steve Kirk and defining the sound of Thimbleweed Park. (Note to self: Email Steve and let him know we'll be starting next month).
Also thinking about testing. Thimbleweed park is going to be a big game to test, given three Kickstarter platforms, mobile, and now console. The plan is to bring on a lead tester who will create test plans and manage the other testers. We've budgeting for the lead, plus four paid testers. We'd like to get the lead started (part time) early October, get them acquainted with the game and start building test plans. I don't think any meaningful testing will happen until Jan. There is also the danger of starting testing too soon and overwhelming the programmers and artist with bugs while they are still adding pass one content.
What Scares Me
As mentioned above, the animation is taking longer than we thought to lock into the right style to fit Mark's backgrounds. We have yet to put any final animation into the game and this scares me. Once we figure out the style, I'm sure it will turn into a well oiled pixel cranking machine, but we're already one month behind and that could stretch into two. In animation, most of the Kickstart rewards are falling on Gary to do or coordinate. Those won't ship for a while, but they are taking time right now.
The backgrounds are taking longer than expected. We were hoping Mark would have everything done first pass by January 1, and would then enter a polish/fix stage, but realistically I don't think he'll be done until March. The backgrounds are stunning, so in a odd way, I'm OK with them taking longer, but I do worry about budget and it affecting the ship date. So far, those two issues aren't a problem, but we need to keep an eye on them so they don't become one.
Saving games still scare me.This is something I should have figured out months ago. The issue isn't a matter of how to store the data, it's way more complex than that. There is a lot of data to iterate through and save off in a way that can be reconstructed. Doing save games is harder today than it was back in the SCUMM years. Back then we didn't have to worry about patching. These days, the save game has to survive the game being patched and that can mean resources being added or removed.
Managing all the translations and the English voice recording is going to suck up a lot of my time when that rolls around. It also means that we need a script lock sooner than I like. The entire script needs to be locked on April 1. That scares me.
My biggest fear these days is how much time I spend NOT making the game. Writing these blog posts takes hours each week, plus it takes me around two hours to record, edit and post the podcast. These things aren't free. I think they are worth it and I enjoy doing them, but it cuts into the hours I spend programming and designing.
Budgeting and scheduling also takes several hours each week. I'd love to have a full time producer that could handle this part of the project, but it's all falling on me right now. It's tempting to just skip budgeting and scheduling as they often don't feel like "real" work, but the sense of accomplishment is short lived. You need to know where you are and how long it's going to take to get there. If you don't, you're surprised to find yourself out of time and money. Game schools should require proficiency in scheduling and budgeting just as much as level design or 3D modeling.
I feel good about the design and the progress we're making on the tech side. Of course, all that could change in three months.
Stay tuned for next quarter's nail biting episode of "State Of The Game".
- Ron
for sharing such deep insights in the developing process and the future outlook.
It is really great to read each of your blog posts, it gives me the feeling of standing next to you and looking over your shoulder while you are working on your next great adventure.
I wondered many times why Will Tiller had so many troubles to pass Kickstarter, even just small budgets. He made lots of good adventure games with very good art quality. ..well...Budget suck same way as volunteers :o) JK
At the end, you are all progressing well, and I am sure you will earn some good $ when its released, then you can afford all you need for another game.
Unless it turns out to be another coin collecting endless runner, for business reasons.
I'm still hoping for an option to make it EGA/C64/crappy looking!!!
Hell yeah! Reminds me of Millwall supporters chant: http://www.youtube.com/watch?v=coUd-AaLkjQ
One of my favorite parts is:
"No, no, no. I keep saying. This is a classic point & click adventure game. It's going to turn some people off. We know that, and we don't care."
I think Monday's post are enough if you need more time to spend on the game. We really appreciate them but the game is the real thing.
Thanks again. And keep it up!
We know that development is well underway and the project is in good hands. And it's looking like a future classic already. Great work! Take your time, we can wait. We've unconsciously waited for 20 years, after all.
Oh, and here is a link to Zak McKracken on the FM Towns:
https://www.youtube.com/watch?v=dt7AYqdoWXY
*Ron, please make someone say: "AIEEEEE!" at some point in the game!*
It'd be great if you would open source the engine.
With regard to data saving, one way to do it that I think works well would be to have encoder and decoder for every data type (basic, structured). When encoding that type, prefix it with the following fields: current version of the decoded type, minimum version needed in order to read it, and total number of bytes for the encoded data (which will be calculated automagically when encoding).
I'm not sure how this would be done with squirrel, but you could do it with overloading encode/decode functions. Then you'd do something like:
struct buffer {
int total_bytes;
int cur_ofs;
char *data;
void *reserve(int num_bytes) { ... }
};
#define ENCODE_BEGIN ...
#define ENCODE_END ...
void encode(int i, struct buffer *b) {
ENCODE_BEGIN(4 /* cur version */, 2 /* min ver */, b);
void *p = b->reserve(sizeof(int)); /* not safe, just for the sake of example */
*((int *)p) = i; /* not portable! */
ENCODE_END(b)
}
Once defined the basic types , we can use their encoders in other types:
struct high_score {
char *name;
int score;
};
void encode(struct high_score *h, buffer *b)
{
ENCODE_BEGIN(1, 1, b);
encode(h->name, b);
encode(h->score, b);
ENCODE_END(b);
}
etc.
If I were working on a save format for a game like this, I think I would be looking at an XML format that had each entities' states (i.e. Inventory, dialogs, scripts, characters' inventories, etc.) serialized into it.
If an area, character, or item was cut/replaced in the game, the XML node(s) governing them could be ignored (despite hanging around in the save file). When a new version of the game is launched, it would need to migrate any modified items' nodes into their new nodes with the appropriate key/value pairs relating to that object.
Thanks to all team members for taking the time to
write these wonderful blog posts - very appreciated!
And, after all, thank you for taking the challenge to
make a new classic adventure!
I've seen good arguments for removing verbs, but there's one question that kills them all. Do verbs make for better puzzles? I think so.
Example 1: Monkey Island 3. You get stuck in quicksand. You try everything and there's nothing left you can do. It turns out you need to blow on the balloon. There is no "blow" verb, so you talk at it. It's obscure, and I'd cry foul except that you're stuck in one spot. The solution is funny and makes sense.
Example 2: Broken Age. You get attacked by a snake. You know you need it for something, but all you can do is blow a horn and the snake goes away. It turns out the solution to the puzzle is to do nothing. Boo! Bad form. I'm not going to get trained to sit and do nothing in every game I play in hopes that the problem resolves itself. Verbs would have served for a better solution to this 'puzzle.'
Also: I said it twice before. Mark's lighting is very noticeable! It makes you want to be in the scenery. You couldn't have wished for better artists.
On the saves, this is something we have to deal with in our firmware (user settings/counters, etc in NVM). What works out pretty well for me is: always, always have a version up front, and always increment the version when it changes (okay, obvious to most people, but that's key...); If it's a binary struct save, never remove things from the struct or repurpose positions, only add so positions are always the same across all versions - that's crucial. On load, check the versions, and if you're going from v12 to v13, do the specific massaging you need of any values. If you're going from v11 to v13 do the v11 to v12 massaging and then the v12 to v13 massaging. This even works going backwards versions (if someone backs out a patch) thanks to never changing the position of things in the struct.
Now if you're using something more modern, like JSON or just flat key/value pairs then it's even easier - just never reuse a key name for something different (but never throw out deprecated ones easier, in case you need to do go backwards).
We're up to NVM layout 45 for one of our years old products which keeps accumulating options and obsoleting others - the only problem we've ever had is when someone forgets to add the vN to vN+1 massaging code - and that was caught in test.
I wonder how the yooka-laylee team are doing exactly that then?
The new Humble Bundle is Humongous!
Go back, review your "promises", and do that as a baseline. If you didn't promise 3 updates a week, a stand-up meeting podcast, etc. -- then don't sweat it, feel free to cut back! I have to be honest, I read EVERY post -- but I sometimes skip the podcasts, as they are just "I did this" type of meetings. Are they relevant? Sure. Are they super-informative? Not really. There is far less content in them (as far as I am concerned) vs. a nice juicy blog entry with code samples.
If you aren't planning a documentary after the fact, then you are putting way too much time into video editing. Just give us a raw video without any narration or cuts. I'm fine with raw materials, as long as I have a 1-sentence context setup. :-)
Again, I'm not complaining.
If your planning something like this, it just important to know, this stuff doesn't come for free. Documenting a process is fun, but so is documenting the documenting of the process. People often forget that part.
Also, would you write a book on making games? I really need to learn about budgeting and scheduling in general, and learning from your experience in doing games would be awesome.
(Did you already write a book? I found some books having "Ron Gilbert" or "F.- Ron Gilbert" as author on Amazon; can you tell me the titles of the books you wrote, if any?)
For me, it's like watching an episode of 'How it's Made' where they show you how garden rakes are made: sometimes the process is a more interesting than the product. I think it's awesome and scary how we've grown to expect things to magically appear and not understand the process and hard work behind even the dumbest things. I'm by no means slamming the game, because I haven't looked forward to a game this much in years, I just REALLY dig the blog.
I'm happy with whatever I get (in terms of content posted here), and I promise not to bitch if you don't have time to do it or need to work on the game in lieu of blog maintenance.
The other ones I really like are artwork posts and video gameplay example posts.
I'd say I don't care if the game is delayed by a month if that keeps Ron sharing it with us.
This blog has become one of my favourite pages.
As some say, it's not about the destination, it's about the journey!!!!
PS: What about asking Malcolm for making an occasional contribution to the blog? Maybe he is interested in writing a blog entry regarding his subtasks.
"I can't imagine doing anything else with my life, but it's also stressful, exhausting and can be demoralizing. It can wake you up in the morning with vigor and excitement and send you to bed with a sense of doom and defeatism."
I try to keep this short. I am an Art Director and experienced web programmer, and this quote pretty much describes my work. I love it, but it can be exhausting. Also the parts about budgeting, planning and own promotion fit my experiences. They are important, but take way too much time from the actual doing. I would love to concentrate just on creative work, but it's impossible. But, as budgeting and scheduling is a big part of creative process, I find the outcome is often better, if one person is responsible for budget and schedule as well as creative direction. With web projects, I like to do the budget, creative direction and base programming, as this will ensure that the project will be predictable, flexible and delivered on time.
Funny thing is, I was really kicked into my trail by Lucasfilm Games. Mainly by Maniac, Zak, Indy 3, Loom, MI, MI2 and Fate of Atlantis. It started with Zak. So... thanks guys :)
Can't wait for TP. You're absolutely correct with the new art being the reward. Haven't experienced the sense of accomplishment since Lucas games with new location presented after completing a puzzle. Passive entertainment (movies) can be easy to consume. Active entertainment can't be easy to be entertaining. Be it a amusement park ride or a game of puzzles.
I am with Christopher here and dont care too much about the podcasts, mostly because I like to waste hours uh mean spend my breaks in the office with catching up on stuff and its much easier to read a post where you can be easily interrupted and continue than to listen to a podcast (in a noisy office).
I know the youth doesnt like to read and want it all on youtube, but your audience is older anyway ;).
On a completely different topic:
Thanks for posting about Caren and the tangled Tentacles. It comes from a demoscene background (which means it will be completely free, guys!) and I happen to like those folks and stick around them a lot. And an audience like the people on here is exactly what those 3 guys need to keep on being motivated. Also make sure to visit at least one demoparty in your lifetime if you havent already - theres always one caring about your favourite platform of all times (which I suppose is the C64 but even if you would be into Speccy or Javascript-Demos...).
Thank you Ron (and Gary, David, Mark and everyone making this possible):
You made me happy when I was but 7 years old and you still make me happy now (25 years later), so I guess thats something. Oh boy, this is gonna be so great!
And remember to never pay more than 20 bucks for a computer game (I actually paid 25, but 5 of that is only for absolution of my childhood sins ;).
Regarding the savegame problem..
I think the multiple format solution suggested above is a good one, with some additional details.
I used that in a game that was released in early access and which was updated in a whole year with new features
and changes. Players uploaded more than 16K items on Steam Workshop and we didn't have
any compatibility problem between file versions.
Ok, we used it for our level/items editors, and formats naturally fits to them,
but I don't think it's too far from a savegame actually.
Pratically, you will define a class which holds the code for loading the savegame (that is, a format class);
then, in the next update, you will define a new format class (you will keep the old version class).
You will define a new class for each new format, and you will keep all the code to load a savegame for every format,
not just the last format version.
Of course, you will assign a unique id to each format that will be written in the savegame.
So far, nothing new under the sun; and of course, this could be extended to define a format version for every data type,
as someone suggested above; but the game savegame format version is more important here
because it is directly connected to the game update release.
Each time you stabilize a new format for a new game update, you will define a conversion routine
from the previous release version (just from the previous version to the current one).
Then when you load a savegame, the game will apply sequentially the chain of conversions from that savegame version to the current one, and then apply it to the game state.
For "conversion routine" I just mean that you update, in an arbitrary way, the state of the current savegame in memory
in order to be valid/consistent in the new format.
For example, in the past version, in order to solve a puzzle P, you should pick up the object A and use it.
In the new version you should pick up the object A, talk to the character C, and then use the object.
In the conversion routine, you will check this: "If the puzzle P is solved, then register that I've already talked to C".
It could seem a difficult task, but it must be noted that you'll always reason about the current state of game and the previous release only
(and so just about the very last changes to the game), not the whole development story.
If you ever want to write a longer post about rewarding players in videogames I'd gladly read it. It sounds like something you've thought about a lot.
That said, perhaps making so many ports brings unnecessary risks to a development of this nature. They won't make the game any better, and all the audience worth-catering to uses a PC to play videogames since it's the most sensible thing to do (specially if you are interested in old-school adventure games that don't even require a modern PC to be enjoyed). From my point of view, all the UI and coding work seem to be a waste of time that could be used to simply finish the game and start working in another one. Of course it's nice that there will be no need to spend any of the Kickstarter budget on it, but still.
Other than that, I'm eager to know a bit more about Steve Kirk's work for Thimbleweed Park. He's a great composer, and hearing his music in an adventure game will be fascinating to say the least. I wonder if the game will have an area with changing tracks for the screen transitions iMuse-syle, since it was such an awesome feature that reached masterful levels with MI2's Woodtick.
And regarding's Mark's art, I'd suggest adding one or two close-ups as a reference to the ones in The Secret of Monkey Island and Loom. Those were superb, and definitely deserve some love in TP.
... wait, what!? No highlighting items?! NOoOoo!! I want my money back.
I'm also in favour of reducing the blog posts, if it means that you can work more on the game. Originally, you wanted to post only once a week and sometimes you skipped a week, which was totally fine. Now, most weeks there are more than one post. Don't be afraid to CUT. :-)
Kindest regards
(which could happen just a few months until the release), you should wait the engine devs to fix.
Sometimes, the engine developers just don't fix it
(e.g. old Unity3d networking code is broken and was never fixed, they just added _after some years_
a new rewritten and quite different networking layer, deprecating the old one).
I for one, really appreciate your weekly podcasts. Just hope, that you won't hate us for making you do them at the end of the project.
I send a comment in a more related post but that post it's very old and maybe here can be more "visible". http://blog.thimbleweedpark.com/roadmap1/55d23ecb8195c3a829e1a6b4
I'm talking about the voice recording, and if it could be a way to, like the fan translations, make a fan dub, and making the possibility to do fan projects to make the voices for the game in other languages. I know some of them, and maybe Thimbleweed Park could be an "easier" one (inside all difficult it is by itself) because there isn't lip sync and things like that. My girlfriend is in that world and she knows projects like this and she is aboard in one.
Of course, i (and everyone, i think) don't want to make more difficult the development of the game. You know if it's possible or approachable. It could be overwritting the original voices (i know this is the ugly way... but it's the normal way to do this things) or maybe have a folder with the default english voice and another folders with other(s) languages (this is the beautiful way...), but it isn't needed to be much sophisticated than changing the voice files one to one, and maybe making the actor talks meanwhile the voice plays (crap, i need to remember that always it can be more complicated), and allow to have a text file with the credits of the project and the names of the voice actors.
Anyway, whatever happens, i only want to drop the idea. Thanks for all of your work (o all of you) and thanks for the way in which all of you described the development of the game. I think is a lot interesting, and i don't miss anything.
PS.: And sorry for my english :P
At least that was my impression.
But dayum, that lighting looks tasty overall!
in english: dude, calm down and read exactly before you post.
corresponding to the version of the game
installed? Here's some items from version 1:
1 sword
1 hat
1 phone
The game is updated to version two and now
one object is removed and another is added:
1 2 sword
1 2 hat
1 phone
2 joystick
Now the items are marked as they are in version
1-2, but the phone doesn't have a 2 mark which
means version 2 of the game will not try to load
that item in the players inventory.
If you get a save file from a friend that is
using version 2 of the game, then your version
1 of the game will simply ignore the version
2 items because the code says to ignore items
higher than the game's current version number.
If you remove a room in version 2, then the
characters can maybe get moved to a default
location or something like that?
I don't know if any of this makes sense, I
just want to try to help out.
Regarding the sound track in the save file,
I guess the game has an internal player
keeping track of where the song is playing
right now, like 38 seconds into the song
Circus Soundtrack 1 and then stores that
position in the save file under the variable
soundtrackplayingrightnowforactorX.
Greets
http://blog.thimbleweedpark.com/faq
>> We have yet to put any final animation into the game and this scares me.
Like you are fond of saying... if something is not working, don't be afraid to slash and burn it, or change courses! Perhaps the original Maniac Mansion style would suit better.
Just sayin'. ;)
-dZ.
(Sorry couldn't resist it. Please don't hate me.)
Keeping in mind that's not the final version of the game, and it's already so beautiful, with a care and attention to the tiniest particular... you are really great!
And if you won't ready yo release the game within the 1st of June, in my opinion it's not a problem. I can wait... Take your time, really!
Loving everything the team has been creating. I'm really looking forward to getting my hands on it.
You guys are awesome!
I played the late Broken Sword (kickstarter one) and was great fun, especially for the classic graphic), cannot wait to play this. I couldn't finish Zak playing it in 1990 (too young and no solutions, and the game was very hard!), I hope this game will give me the same challenge, I'm sure the puzzles will be amazing!
Greetings from Italy
One thing I'm curious about (and this is going to make me sound like comic book guy from the Simpsons) but you mentioned in your grumpy gamer blog that if you were to make another Monkey Island game, that you would lose the verbs (http://grumpygamer.com/if_i_made_another_monkeyisland), yet it looks like you've stuck with them for Thimbleweed Park. Is there a particular reason for this? Did you decide there wasn't a better way to to do it? Or is it purely in keeping with the "1987" aesthetic?
Thanks, and once again I'm seriously excited to hear about the game. Can't wait!