Sign in to follow this  
Followers 0
DF Brandon

Programming Update #3: Tools Development

170 posts in this topic

Howdy, folks!

I’m Brandon, one of the programmers on DFA. I’m a systems programmer, which means I specialize in the plumbing: writing low-level systems the game can rely on, optimizing, working on cross-platform compatibility, and - my personal favorite - developing tools.

As Oliver discussed, we’re building the game on top of Moai. It’s an excellent engine from our buddies at Zipline and is proving to be a great choice for DFA. However, one sacrifice we make by not using Buddha – our internal codename for the Brütal Legend engine – is that we can’t use some of the

we’ve built over the years.

Buddha knows lots of neat tricks. Most assets can be hot reloaded, meaning that you can do things like tweak a 3D model, export, and see the game swap in the updated model on the fly. We’ve also accumulated a lot of very helpful tools and in-engine editors over the years.

For example, here are a couple of the embedded Buddha tools running in our beautiful* programmer test world:

1.png

*not actually beautiful

The overlay on the left shows us detailed information about our resource memory budgets. All of the resources are broken into categories so that you can see how much memory is being used separately by characters, the environment, and so forth. The display updates in real time, so you can play through the game and spot problems right as they occur. We have lots of overlays like this that give us detailed information about the game and help us figure out what’s going wrong as soon as problems occur.

You can also directly adjust most objects in the game. The gizmo on the right is a 3D placement tool. You can nudge the positioning of objects in the world or tweak settings like lighting colors and see the effects immediately. If you’re happy with your changes, you can save them back out. Being able to modify everything immediately makes it much easier to tune a gameplay system until it’s fun or tweak an environment until it looks just how you want.

These tools make it a lot easier for us to quickly add something new to the game and then refine it until it’s great. Unfortunately, these tools are built directly into Buddha, so they can’t be directly transplanted into Moai.

We’d be a lot slower without these tools. So, while we’re still in preproduction, I’ve been focusing my efforts on extending Moai and writing a tool that provides a lot of these same features.

The tool is called 2HB. It’s named after our beloved Double Fine mascot. It functions as a traditional text editor for writing Lua scripts. It also contains custom editors for creating game levels and so forth. Additionally, it maintains a direct connection to the running game.

This allows 2HB to function as a debugger, with all the breakpoints, watch windows, and error catching tools programmers crave. It can also issue hot reload commands, drive in-engine editors, and access runtime performance data. This gets us back to a place where people can see their work in the game as fast as possible and continue to tweak it once it’s in there.

Here’s a basic outline of how we build an area in the game to show you how everything ties together.

First, once we have some rough design ideas for an environment and some exploratory concepts have been made, an artist (Bagel) does a rough layout of the environment in Photoshop. The environment is split into separate layers that will be placed at different distances from the camera to create the sense of depth you can see in the Lee’s visual style tests.

2.png

Once the layered painting is ready to try in the game, we will run a script on the Photoshop file to separate the layers into individual files and create an initial scene file in the game’s data format.

An artist can then go into 2HB, tweak the layer distances, walk around in the environment (look at the lil’ Redbot!), and make sure everything’s working to their liking.

3.png

At this point, with a rough scene in place, a programmer can dive in and start adding gameplay objects, hooking up puzzles, and other scripting. All of the gameplay scripting and debugging can take place directly in 2HB.

5.png

In parallel, with 2HB running, artists can keep working and see their changes show up automatically in game. They can dive in and refine the scene, add new objects, paint over textures, and just generally making things prettier.

4.png

Or, if you’re a programmer with no artistic abilities, you can deface the scene with your chicken scratch and claim you’re “testing” the tool.

The tool is still very early in development. We need to build lots of nice editors for all of the major components of an adventure game: a nice editor for writing dialog scripts, more tools for adjusting character and object placement, ways to lay out the geometry that defines where characters can walk, and plenty more. We’ll keep improving the tool over the entire lifetime of the project, but what we’ve already got provides a solid foundation for everything else we need to build.

Spending some of our programming resources to build better tools will definitely help us make a better game. This is the kind of work we wouldn’t have been able to tackle without our funding total wildly exceeding our expectations, so thanks to all of you!

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.

Well, that’s it for now!

Love,

Brandon

Share this post


Link to post
Share on other sites

Nice update!

I was wondering about the factor Lua plays in all this: Will the main "engine" be done in Lua, or will it be set aside for stuff like scene scripting and other smaller tasks?

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.

Awesome!

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.

Awesome!

Indeed!!

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

Share this post


Link to post
Share on other sites

I would love it if all of your tools become open source in the end. I'm hoping this stays true.

Share this post


Link to post
Share on other sites

Thanks a lot for the awesome detail, as always. That fast iteration helps in many more ways than just saving time - I am surprised that so many "pro" toolsets still miss that point. When you can try out ideas that are still "vaporous" and undefined in your head quickly without fighting with the tech you discover things you wouldn't otherwise. Cool stuff.

Awesome to hear you plan on open-sourcing it as well, very kind of you.

-J

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.

I like the sound of that! Interesting update!

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.

Awesome!

Indeed!!

I learned Lua while on a previous job a year ago so I'm definitely interested in Moai and these programming updates. But also I'll vote +1 to the open source 2HB project idea.

Matt

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.

Very cool!

Share this post


Link to post
Share on other sites

Fantastic! The Double Fine Adventure is now technically something real that exists in the world. Redbot may not be having a wild adventure walking back and forth outside the cabin, but we're under way! :D

I think it's very neat that it all seems to be real time and can be updated on the fly. It's also great that the DFA might help others contribute to a renaissance of adventure games.

Thanks for the update. Perhaps in a future post you could show us some code/script and explain what it's doing?

Share this post


Link to post
Share on other sites

This is sweet, especially the live editing features. I'm really interested in poking around with it once it becomes public (which is awesome of you guys). Thanks for the update! :D

Share this post


Link to post
Share on other sites

Found how much work is being put into what the final product to be amazing and I'm guessing 2HB will become an invaluable tool to Double Fine in the future or one can hope it does. I can just imagine the new stories/adventures being thought up.

Exciting that you're hoping to have 2HB be open source as well. I don't know jack about programming or anything, but it sounds like with AGS, Wintermute, etc. not being as expansive as was for your tastes and many programmers that this could help the entire adventure gaming community.

Share this post


Link to post
Share on other sites

You make it sound so easy!

Share this post


Link to post
Share on other sites
Nice update!

I was wondering about the factor Lua plays in all this: Will the main "engine" be done in Lua, or will it be set aside for stuff like scene scripting and other smaller tasks?

From what I've seen of Moai, the whole game is programmed in Lua. The executable just provides the functions for Lua script to draw/play sounds/load files and etc.

I am very curious about the debugging capabilities because I haven't found any good Lua debuggers...

Share this post


Link to post
Share on other sites

Great update - I love seeing "real" development; actual art files being manipulated, lines of code, etc.... Very cool!

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.

Awesome!

Regarding this post: http://www.doublefine.com/forums/viewreply/214273/ I'm wondering whether you're likely to share this tool with HBS while it's still in early stages...it would be weird if they made their own version of the same tool at the same time!

Share this post


Link to post
Share on other sites

First: I think we need to come up with a backronym for "2HB" as a development tool. Let's see here...

"2nd-tier Heuristic Binding"

"Second-to-second Harmonious Building"

"Doublefine Harbinger Benchtesting"

I think I'm going to go with "Doublefine Heuristic Benchtester".

Second:

It seems like hot-reloading could create problems when you're working on scripting high-level events (like solving a puzzle or working through a dialogue tree), since the gamestate (and saved game) rely on knowing what actions have been completed at that point of the game, so if you're changing those conditions on the fly, the gamestate could get muddled, or you might otherwise overlook a hole in the scripting that was "filled" by a residual variable from a previous iteration.

(Does that make sense? I'm not a developer so I'm sure my terminology is all over the place.)

Share this post


Link to post
Share on other sites

Programming is way over my head, but reading these strange posts from a far-off land is a little like peaking through a keyhole into a room with mysterious contents.

Keep up the good work.

Smiles

Share this post


Link to post
Share on other sites
It seems like hot-reloading could create problems when you’re working on scripting high-level events (like solving a puzzle or working through a dialogue tree), since the gamestate (and saved game) rely on knowing what actions have been completed at that point of the game, so if you’re changing those conditions on the fly, the gamestate could get muddled, or you might otherwise overlook a hole in the scripting that was “filled” by a residual variable from a previous iteration.

(Does that make sense? I’m not a developer so I’m sure my terminology is all over the place.)

It definitely can. It's pretty easy to make hot-reloading "just work" for simple assets like meshes and textures, but more care is required with scripts. Fortunately, it's pretty easy for a given game to come up with rules of thumb for when it's safe to reload a certain kind of script and then the people writing code just stick to those guidelines.

Share this post


Link to post
Share on other sites
Regarding this post: http://www.doublefine.com/forums/viewreply/214273/ I’m wondering whether you’re likely to share this tool with HBS while it’s still in early stages…it would be weird if they made their own version of the same tool at the same time!

We'd like to for sure. I agree it would be a shame to duplicate similar work across two different studios. As Brandon said, we're still navigating some legal and logistical issues about sharing this code outside of DF, so once those are figured out we'll have a better idea what we can do.

In the mean time, we talk periodically w/ folks at Hare Brained and Zipline about what we're working on and try to make sure that we're duplicating as little work as possible.

Share this post


Link to post
Share on other sites

Second:

It seems like hot-reloading could create problems when you're working on scripting high-level events (like solving a puzzle or working through a dialogue tree), since the gamestate (and saved game) rely on knowing what actions have been completed at that point of the game, so if you're changing those conditions on the fly, the gamestate could get muddled, or you might otherwise overlook a hole in the scripting that was "filled" by a residual variable from a previous iteration.

(Does that make sense? I'm not a developer so I'm sure my terminology is all over the place.)

It sounds scary, but that's something that is possible with most powerful tools, usually it's not too hard to fix if you confuse the game, usually you just relaunch the binary and then have to spend a few minutes getting back to where you were working. Similar things happen if you have a penchant for memory address hacking in singleplayer games for fun.

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?

Share this post


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