Delores Source Code Released!
Oh crap!
I accidentally pushed the wrong button and made the
Delores source code available on GitHub.
I guess there is no putting Delores back in the bottle now...
(wait for laughter)
I'm only half kidding.
(wait for Todd in the third row, who laughs at anything, to stop laughing)
I did publish all the
source code to Delores on GitHub, but it wasn't an accident. It was a well planned endeavor to give you even more to do during pandemic lock-down. I'm sure everyone is getting tired of playing Animal Crossing, and what better way to exercise your grey-matter than modding your favorite game.
But wait... there's more...
(wait for oohs and ahhs)
Not only did I upload all the source, but I also uploaded all the art and the entire FMOD project (many thanks to FMOD).
But wait... don't hit the back button yet...
I also uploaded the dev build of the Delores engine (including the complete debugger) so you can run all your edits and changes. Also included is Wimpy, the executable that allows you to add and edit objects in Rooms.
"Holy crap-a-reno! What's the catch Ron?"
While you can do pretty much anything you want to the game, including writing a whole new UI, or translating into any language, or returning it to the verb matrix, you can't release or publish a game. This is intended for personal and hobby use only.
The other downside is these really are the dev tools we used to make the game, and like most in-house dev tools, they are poorly documented and very crude around the edges. While I do provide some help documentation it is mostly limited to an index of Dinky commands, not a tutorial.
What? You want a Hello World example? OK, fine.
local image = createTextImage(FONT_SYSTEM, "Hello World", 48)
There is a fairly high degree of technical and programming knowledge needed. I've always skewed away from visual programming and dialogue engines. While they are great for beginners, getting real work done is problematic. Again, these are the real tools we used, not watered down "consumer" tools.
I've been using Git for 10+ years, but this is the first time I've ever had a public repo and had to deal with pull requests, etc. This will be a big learning curve for both of us.
I generally won't be accepting pull requests just for modifications to the game unless they fix bugs related to getting this repo working. I might accept pull requests for documentation and new translations and if they are good they maybe-might be integrated into the shipping game.
"But Ron, why won't you accept my bug fixes and improvements to the game?"
Good question little Timmy... let's dive into that...
A game that goes on Steam, Epic, or GOG requires a great deal of testing. Delores had/has two full-time paid testers and before any build was uploaded to a store, it got a good deal of testing around the fix, plus a complete play through of 30 photos was required on each platform. Each of the stores uses the same "bits", but we still had to download each platform from each store and do a run through.
And that was for an easy fix. If the fix was more involved or changed logic significantly it could require 20-40 hours of testing. If we broke a store build, it would be hours of tech support emails.
I believe a lot in testing and testers and much of that came from my time at Lucasfilm and dealing with hard media. To even put a build of Monkey Island into test required over an hour of work as I made and verified 5+ floppies. Just rebuilding the SCUMM scripts to Monkey Island took over an hour (a job that takes a fraction of a second for Delores).
Releasing a build going to manufacture was nerve wracking and very expensive. If you introduced a stupid bug, you'd remake 200,000 floppies. While Monkey Island was in final testing, any change had to live in test for two weeks. If we found a bug and made a new build, we'd reset the clock.
Today it's easy. I start a shell script, wait 15 minutes for the CI machine to build the new engines and 5 seconds later it's on Steam and I can push the "publish" button. It's too easy.
BONUS NOTE: Don't believe the myth that programmers can test their own code. They can't. Programmers will test for all the conditions they can imagine, but a good tester will imagine many many more and players will try things programmers never even considered. Knowledge of their code is the achilles heel of programmers. I've had code I was 100% sure was rock solid, only to have one of our testers reduce me to tears. A good tester excels at poking your code in places you never considered. I'm not talking about your unit tested sort routine, I'm talking about complex puzzle logic and odd UI uses. It's the stuff unit tests will never catch, but a good tester will. Testers are the unsung heroes of your team, treat them very well.
Every time you do a build, you also run the risk of accidentally introducing an error. Once I did a build from the wrong branch, everything looked fine but after a few bugs came in, I realized something was very wrong. I'm glad I didn't just build and hit "publish". Even fixing a typo requires testing.
"Hey Ron, little Timmy again... why don't you release the source to the engine?"
Another great question.
Releasing the engine source (c++) is problematic for a few reasons. The first is that it uses a very large library of mine, most of which is not used in this engine, so I'd have to go though and cull out all the cruft, not to mention all the proprietary console crap. I also use some third party source I don't have the rights to release. It's a big job and would split my main engine off from the released engine, which becomes a merge catastrophe (either that or a million #if's).
"Little Timmy again, I have a followup question... Why don't you license the executable for us to use in our shipping games?"
Allowing others to release games using the engine is a support nightmare for me. A game would be released and then customers would have issues, or it wouldn't work on specific hardware, and then I'd be stuck (indirectly) supporting it. I could charge money, but unless hundreds (if not thousands) of people licensed the engine, I fear the cost would be more than a game is likely to make.
But the most important reason is that I like to make games and want to dedicate most of my time to making new ones, not supporting an engine.
Once you've had a chance to look at all the source, I think you'll realize there is no "secret sauce" here. It's just an adventure game engine. Why did I create a new one? Because I enjoy it.
This post ended up being longer than I expected. I hope you enjoy looking through my and David's crappy code. Happy modding. I'm excited to see what you do.
(wait for laughter from todd)
Keep in mind, the Delores source is intended solely for personal use to learn and explore. Please respect our choice to release the source by using it as intended.
P.S. The dev engine has all the same limitations as the game, so Mac 10.10, Win 10 (dx12) and unfortunately (at this time) no Linux build. As soon as the Linux version is done, I will upload that as well. It might be a month, or months, or longer.
P.P.S If you have questions or want to help others out, visit
the Thimbleweed Park Forums
