Okay, so here’s my DevLog for Defender’s Quest 2.
Today:
-Did a lot of paperwork
-Started this devlog
-Felt guilty about not posting updates in a long while 
I’ll be at Steam Dev Days next week, checking out this crazy weird Steambox insanity and the associated controllers. Will be interesting. I’ve got some updates about our progress with DQ2 but that might have to wait until next week.
Oh Lars, you big tease. 
Ok, I’ll try to remember to check back soon. The spammers persist, meanwhile…
Awesome, can’t wait to hear more!
Sooo it’s been three weeks now! How’s it looking? 
They must have either took a break or slowed down for probably personal reasons, because the engine itself was guessed to be completed in early 2014 (Alpha), but hey, as long as it’s going good, we can wait!
I second what MenDude said. After all, that was an estimated date. Stuff happens, so of course chances are things might take longer to complete than what was originally projected! I’m sure that whatever information we’re given in the next dev log will be interesting or good to know!
I’m not asking for the game to be released right now I just want to know what’s going on
NEWS!
http://www.fortressofdoors.com/2014/03/ ... pdate.htmlSorry folks, I’m gonna get better at this!
I hope you keep the name “Enemy City.” That sounds like a good name for a place you would get attacked in a lot.
Hero: “We stopped by Enemy City to get some supplies and a room for a night, but all sorts of people started attacking us!”
Friend: “Well, duh!”
(assuming this is Enemy City)
A Different Hero: “I was looking for a book that was supposed to be at the Enemy City Public Library, but whenever I asked anyone for directions, they would attack us!”
A Different Friend: “Well, duh!”
Does this mean we are going to have JRPG-type towns in this one? (EDIT: Re-read that it will likely be used as an in-game cut-scene.)
The music is sounding good too.
I’ve read it, and I’m really happy with what you are all doing to BOTH games!
@Babaganoosh LOL XD
OMGOMGOMGOMGOMG 3DS PORT POSSIBILITY? I WOULD LOVE IT AND TOTALLY RECOMMEND IT TO MY FRIENDS
Also eeeeee yay so happy to see another update from you guys! if you guys need someone to help proofread the story, I’d be willing to spare my time! :3 (of course, I’ll be torn between knowing the story in detail and being able to play it blind :c)
(Also I think Smug Captain looks kind of cute. You guys will update the website with more in the media and news sections, right?)
Yeah sure, will, as soon as this Humble Bundle madness (and the inevitable post-bundle support burden of bugfixes, etc) calms down:
https://www.humblebundle.com/weeklySo, any updates going on? 
Alrighty folks, so I have some updates.
First of all, I’ve been working full-time on the DQ2 engine for a good little while now, and I finally have something to show. That said, we’re still going a little slow on getting DQ2 “CONTENT” up so what I have to show today is engine work.
One of the biggest reasons for moving to Haxe is that it will let us break the game out of it’s wimpy 800x600 borders it was confined to in DQ1. I’ve been spending a lot of time with that lately, and I have a new build ready to show!
So I want to talk a bit about how we do this. I was thinking that we would share early content with our dedicated testers and our alpha backers, and I’m wondering whether this should count as that, and how’s the best way to distribute it. My testing setup for the last game was very ad-hoc and kind of crappy, but I don’t want to not show testers/alphas what I’ve been doing while I wait to figure out a better system. I also am realizing that between my blog, twitter, and this forum, that I’ve kind of fractured the community. I’m looking into maybe finding some way to unify everything with one general “talking about stuff” platform, but I’m not pulling any triggers just yet. (Looking at Discourse for now).
Hopefully we can chat out some solutions here, I’ll decide something, and then you guys can see the build within 24 hours.
I am calling this an “https://en.wikipedia.org/wiki/Aleph” build for now. (“Aleph” being the letter that corresponds to “A/Alpha” in the Phoenician/Semitic alphabets, which came before the Greek alphabet, thus being the version letter that precedes “Alpha” 
)
So, new build looks like this:
As you can see, it’s using the DQ1 data set for now while we work on building up DQ2’s unique content. So far saves seem to carry over correctly, and you can “step through” most of the game by starting battles. Battles will auto-skip for now as I get the kinks out of the new battle system (not stable yet), but progress is correctly tracked. Cutscenes are also just placeholders for now.
The main thing I want to test is how all the crazy dynamic resolution stuff is going to work. I have a pretty full-featured video menu implemented, and I need to test whether it works on people’s systems, and also work on the UX by collecting feedback from people.
A big part of making DQ2 is ensuring that DQ1’s content runs on the same engine, but this doesn’t mean we’re planning on officially re-releasing DQ1 with the DQ2 engine (though we reserve that option).
Hrm, that’s an idea with a few options attached to it - you could put all of DQ1 in DQ2, and then make it accessible via some menu option or another.
it could be unlocked via a code if you own DQ1… it could be a New Game + sort of thing where beating DQ2 or some DQ-related achievement/challenge would unlock DQ1 as a reward.
Eh, just tossing out random ideas. Still looking forward to hearing more about DQ2 once the ball really gets rolling, so to speak.
Latest “aleph” build of DQ2 engine is up in the usual place. If you have alpha access or are volunteering to put in some testing time, and don’t already have access, ping me and let me know.
Oooh, cool! I’ll pm you to find out where “the usual place” is once I’m on a computer. (Should be tomorrow, I have a long day tomorrow with a long break)
I downloaded this, but still didn’t play it, but from looking at the pic it seems very promising!
Okay, today I just dumped a new build of DQ2 for our testers and alpha backers.
Here’s what I’ve been doing lately.
Right now there are basically three major components to DQ2 development
- Core engine (TDRPG-haxe or just TDRPG for short)
- Defender’s Quest 1 data set
- Defender’s Quest 2 data set
The idea is, the difference between a DQ1 build and a DQ2 build will just be data. Right now we have very little DQ2 data in a finished game-compatible form, so DQ2 builds will be very similar to DQ1 builds until they start to diverge as we start rolling in content. However, we’re making continual progress on the engine, regardless of the data set.
This means that when we’re done with DQ2, reproducing DQ1 in the new engine shouldn’t be too difficult. Also, testing the engine using DQ1 data will be a major part of development while we wait for DQ2 content to be produced. So throughout testing we’ll release some DQ1 builds using the new engine. This does not mean we are publicly committed to re-releasing the original game, but it is a thought that has crossed our minds.
In any case, from now on the title screen of TDRPG games will include a version number for both the game data set AND the engine.
Note the lower-right hand corner – DQ2 version 0.0.1 and TDRPG version 0.0.1. The DQ2 number goes up when data in the DQ2 set is changed, and the TDRPG number goes up when I modify the underlying TDRPG engine. 99.999% of code changes are TDRPG changes.
Also, all builds from now on include an automated crash dumping utility that should catch most (hopefully all) fatal errors and dump useful logging material about them.
(CrashDumper is open-source by the way, fork it on Github!)
If (more like when) the test builds crash you should see a crashdump report like this:
Clicking the “show crash dump files” will take you to the game’s directory and show something like this:
This is as complete a crash dump as we can produce. It logs detailed error information, as well as some info about your system (capabilities.txt), and dumps of your save & config data as they were when you started up the game (locale.xml, options.xml, paths.xml, SAVE_SLOT_(1/2/3).xml). It also includes “replay.fgr” which is a record of all your user inputs, so we can replay your game session. And finally, a screenshot of the crash event.
The “SEND REPORT TO DEVELOPER” button on the crash screen will eventually connect to a server utility and send us the report. Of course, we haven’t finished that bit yet so right now it does nothing.
And of course, all of this is optional. Right now the game can’t actually send us any data, but when it can you will always be asked first. And if you don’t want the game logging this stuff, you can turn off those options in the options menu. I am also looking for feedback on a sane set of default behaviors here.
So if you’re a tester or alpha backer and want to give us some feedback, tell us what you think of the logging and the crash reporting. If you had experienced a crash error in an early build, try to reproduce it and see if a crash report is generated. If so, be sure to include data from the crash dump in any errors you file on our bug report repository.
