Sign in to follow this  
DF Brandon

Programming Update #3: Tools Development

Recommended Posts

great update! wow youre really making progress fast. yeah the open source thing is really generous. I didnt think that would happen to be honest. awesome! thats like a high-performance multi-platform AGS for anyone to use? amazing. that will help bring adventure games back even more with amateur and indie projects. would there be licensing for commercial projects?

Share this post


Link to post
Share on other sites

Debugging the game, changing variables on the fly, reloading arbitrary scripts, all that is probably not too different from, or more disruptive than messing with Javascript on a random website. It is super important to be able to iterate and try new things quickly with art and design and misc other development.

Share this post


Link to post
Share on other sites
Howdy, folks!

Once 2HB is stable, we'd like to release it under an open source license. That way, anyone who wants to make games in Moai could use all of 2HB’s authoring, tweaking, and debugging capabilities for their own projects. It’d be really nice to be able to give something back as a result of your overwhelming generosity. We still have some legal and logistical issues to work out internally, but if we can make it happen, we will.

I am curious as I'm moving into game development myself (hoping to release my first game later this year) about the legal issues of releasing the source code as open source. I'm guessing that it has to do with Double Fine resources being put into the product so it becomes a Double Fine Asset (as in a business asset) and one can't just give away business assets without some legal wrangling first.

Is this the case, is it something else, or is it something that you can't easily talk about?

Kieren

PS thinking about it are there also liability issues with others using the tools you've provided that need to be carefully stepped around?

Share this post


Link to post
Share on other sites

Very cool news, keep up the great work!

Can't wait to hear more about 2HB and looking forward to more updates :)

Share this post


Link to post
Share on other sites

I feel overwhelmed about all this techno speak... I feel like I should read everything about everything ever.

Share this post


Link to post
Share on other sites

So if I understand correctly, Bagel or another artist creates a layered psd file, that file is imported separating the layers into chunks and providing each chunk its z-plane. Thus you get for example the layer called cabin in plane 4 as a separate png.

The 2HB programming layer seems essential, I'm guessing it's tightly coupled with Moai (meaning it will be for Moai and difficult to migrate for other game engines). Furthermore, are you building more programming layers above it, for example, generic ability to load plugins?

Another question is about testing, it seems that the same framework could be a basis for automated testing, or at least some unit tests.

Thanks for the update, seems very nice progress and it's certainly cool you plan to open source your effort. I'm sure this will give a boost to adventure game developers.

Most importantly - little baby RedBot seems lost in that world, where are the parents?

Share this post


Link to post
Share on other sites

Loved this update! That's some heavy duty programming- I'm really impressed. I never had to go and build my own development environment- just relied on the tools that were provided. I find it amazing that you guys implemented so much already in Moai. Thanks for the update, Brandon!

And I would be ecstatic if you guys do release 2HB! I would've been fine if DF kept it proprietary for future projects, but this would be quite a gift to all of us!

One question: Did Psychonauts have its own game engine or did that evolve into Buddha?

Share this post


Link to post
Share on other sites

First up, Brandon. Awesome update! Thanks heaps <3

I'm guessing that it has to do with Double Fine resources being put into the product so it becomes a Double Fine Asset (as in a business asset) and one can't just give away business assets without some legal wrangling first.

It's not quite "giving away", it's licencing (which is an agreement between two parties - it just happens that open source licences are generally accessible to everybody, where as a lot of other agreements within a business context are limited to internal or external customers). Obviously there has to be an internal decision be Double Fine to go down that road - I'm assuming it would probably be frowned upon for a developer started handing out code without an official OK.

I'd definitely be interested to hear which legal issues are currently concerns or unknowns though.

Once 2HB is stable, we'd like to release it under an open source license. That way, anyone who wants to make games in Moai could use all of 2HB’s authoring, tweaking, and debugging capabilities for their own projects. It’d be really nice to be able to give something back as a result of your overwhelming generosity. We still have some legal and logistical issues to work out internally, but if we can make it happen, we will.

That is fantastic! Big love for you all!

Are you guys hoping to contribute any enhancements you make to Moai upstream as well?

Share this post


Link to post
Share on other sites

Thanks for the detailed post. 2HB looks like it's shaping up nicely, and I'm looking forward to getting my hands on it =0).

Regarding string tools, I've found that for my adventure games, Excel has worked well as an editing tool, and makes localization easy, when you pass it on to your localization partners, because Excel is a fairly ubiquitous tool for editing spread sheets of data. You can even write lua scripts directly into a cell of Excel to execute when that line of dialog runs, this is useful for turning conversation options on and off, playing animations, giving inventory, etc, basically anything you could do in your regular script.

In order to get this scripting working however, a separate tool is normally needed to parse the excel, to pull out the lua commands into a native lua file, to run in conjunction with the strings file. This still allows for hot editing, but does introduce an intermediary step. I suppose writing a separate tool would be good, but Excel really comes with a lot of neat features for editing this kind of data, so I like it. Our latest project was in Unity using C#, and I wrote a similar system to pull the C# out. The cool thing about this was the C# would be compiled into native code, so it was super fast!

Regarding walkable areas, you could do what AGS does and simply paint the walkable areas in, with colors determining height, which doubles as a decent hotspot editor. The other alternative would be to have a simple geometry editor to define walkable areas, then do a linear scale based on the y values between certain line positions, but this makes things like walking over hills tricky, or sand dunes like in QFG2, actually, the color painter doesn't really solve this either!

Personally I think the painting walkable areas gives you the most freedom, because you may want the character at different sizes on the left and right of the screen, for example, if they're walking up a steep path from left to right. Once you have that implemented, you can do a tint/shadow map easily based off the same system.

The other alternative, which I just thought of, would be to load 3D geometry and have the player figure their coordinates in a 3D space, this way you could have a really powerful depth system, and solve the issues mentioned previously. That's exciting. Do that =0).

Share this post


Link to post
Share on other sites

Oh, just a small addendum to the previous post. Be careful if you're editing strings between Excel for PC and Excel for Mac, because they treat line endings differently, and can really stuff up your formatting! We found this out the hard way!

Share this post


Link to post
Share on other sites

@brawsome did you read the other updates? the walkable areas will be polygons, presumably in 3d.

Share this post


Link to post
Share on other sites
@brawsome did you read the other updates? the walkable areas will be polygons, presumably in 3d.

Ooh, I haven't looked at Update #1, maybe I should take a look! I saw mention of geometry for walkable areas in this post, but I made the assumption it would be 2D. Sorry if I misread =0).

Share this post


Link to post
Share on other sites
Out of curiosity since I haven’t worked with Lua or Moai much, is it possible to obfusucate the lua code being used in the final product? Or is it just going to have to be all in clear text?

Yes, depending on how much you care to do so. Easiest is to compile to byte code, though there are good Lua decompilers. You can then take that byte code and package it into a custom format or a zip, though that's more obfuscation. You can encrypt said package and hide the key somewhere in your executable, though a truly determined attacker could probably find that key with enough searching.

I'm curious about the motivation to hide code... I know it's the case for grim and EMI (which also use lua), but I don't really get why it is so. In my understanding, it describes the storyline and interactions with it - which looks trivial enough to not be in the "trade secret" ballpark. Also, still in my understanding, it should not contain anything of value to another project (different puzzle, story line, ...). It's certainly more like in the "spoiler" ballpark, but then people poking in game resources should not be afraid of them.

Disclaimer: working full-time on free (libre) software, without such level of engine/script distinction.

Share this post


Link to post
Share on other sites

@brawsome well I dont know they said in so many words that its 3d but why would they handle the sprite scaling and other things separately when they can do it accurately over depth in a 3d system? especially with camera truck ups and truck backs. I suppose having 2d walkable areas per layer mean no sliding when scrolling etc, I dont know if thats a problem. but...hm. youve made me unsure now! =)

Share this post


Link to post
Share on other sites
Disclaimer: working full-time on free (libre) software, without such level of engine/script distinction.

Offtopic: Oooh, what do you work on? I'm an on-and-off contributor to Neverball and a few other bits and pieces.

Share this post


Link to post
Share on other sites
@brawsome well I dont know they said in so many words that its 3d but why would they handle the sprite scaling and other things separately when they can do it accurately over depth in a 3d system? especially with camera truck ups and truck backs. I suppose having 2d walkable areas per layer mean no sliding when scrolling etc, I dont know if thats a problem. but...hm. youve made me unsure now! =)

Yeah, I guess I saw a picture in my head of it being 2D because I've used a similar editor to define hotspots and walkable areas in an adventure game. I guess I'm so used to thinking in 2D because I've been making 2D games for the last few years, even though I'm working in Unity 3D =0). Incidentally, a 3D space is remarkably good for making a 2D game.

Share this post


Link to post
Share on other sites

The awesome just keeps piling up. I can only imagine the benefit to the adventure game genre and community releasing these tools might have.

Share this post


Link to post
Share on other sites

Very nice. I'm impressed with this work, and I love it how these projects can help such free engines, which can make everyone's life better. Just like inXile helping bring Linux to Unity.

Share this post


Link to post
Share on other sites
Very nice. I'm impressed with this work, and I love it how these projects can help such free engines, which can make everyone's life better. Just like inXile helping bring Linux to Unity.

I haven't seen anything that indicates whether or not inXile's Linux Unity work will find its way upstream. From what I understand, they're getting access to source for a Linux client that was developed but not released earlier in Unity's lifecycle (the fact that it existed and never saw the light of day is not reassuring).

Share this post


Link to post
Share on other sites
Disclaimer: working full-time on free (libre) software, without such level of engine/script distinction.

Offtopic: Oooh, what do you work on? I'm an on-and-off contributor to Neverball and a few other bits and pieces.

The projects I contribute to are mostly off-topic, besides a handful of commits to residualvm because I just needed to play Grim again :) and a WoW add-on (because written in lua). See my ohloh page if still interested (I see there are a few missing projects an not-linked aliases, I should update ohloh more often).

Share this post


Link to post
Share on other sites

A really exciting post, and the option that some of these tools might be released as OSS is exciting...

BTW, remember that releasing the tool in open source might also benefit the company by getting free bug fixes and maybe even extra features that might help in this or future games.

Share this post


Link to post
Share on other sites

Great update. This is how things have to be done. What does it say on your badge? "Give example". Oh, btw, love the painted "!!!1" mistake !!!!1

Share this post


Link to post
Share on other sites
Little redbot looks so Zen set against the wild forest backdrop! Supplanting the lumberjack for redbot is a vast improvement regardless of how out-of-place he looks.

Seth

BRING BACK TEH HIPSTERJACK!!!

Share this post


Link to post
Share on other sites
You can encrypt said package and hide the key somewhere in your executable, though a truly determined attacker could probably find that key with enough searching.

That reminds me of how Hard Reset did it, and how the Key was just stored as a plaintext string in the .exe :D

Please don't obfuscate.

Share this post


Link to post
Share on other sites
Out of curiosity since I haven’t worked with Lua or Moai much, is it possible to obfusucate the lua code being used in the final product? Or is it just going to have to be all in clear text?

Yes, depending on how much you care to do so. Easiest is to compile to byte code, though there are good Lua decompilers. You can then take that byte code and package it into a custom format or a zip, though that's more obfuscation. You can encrypt said package and hide the key somewhere in your executable, though a truly determined attacker could probably find that key with enough searching.

A big caveat about Lua byte code though is that unlike other byte codes it isn't portable. So if you for example make a MacOS X version of the game, the same byte code will not work on PPC and Intel. Obfuscating/encrypting the source code instead does not have this problem.

Of course, this is just talking about the default bytecode format for Lua 5.1. It's possible to make a custom bytecode dumper which is portable, or even use a different Lua implementation (such as LuaJit) which already has a portable bytecode format.

Indicentally, the old SCUMM games used to just XOR the data files with 0x13 or something, so you couldn't read the dialogue. It's enough to stop the casual tourist, and you won't stop the dedicated guys anyway. :-)

Share this post


Link to post
Share on other sites

Once 2HB is stable, we'd like to release it under an open source license. That way, anyone who wants to make games in Moai could use all of 2HB’s authoring, tweaking, and debugging capabilities for their own projects. It’d be really nice to be able to give something back as a result of your overwhelming generosity. We still have some legal and logistical issues to work out internally, but if we can make it happen, we will.

I actually started crying like a little girl when I read this!! There goes my office dignity :)

Share this post


Link to post
Share on other sites

Will 2HB be a stand-alone engine(or just used for Moai)?

Share this post


Link to post
Share on other sites
Sign in to follow this