Creating an IDE (and other tool sets)
digz
be still, maggot Join Date: 2002-05-07 Member: 588Members, NS1 Playtester, Forum Moderators, Constellation
be still, maggot Join Date: 2002-05-07 Member: 588Members, NS1 Playtester, Forum Moderators, Constellation
in Decoda
<div class="IPBDescription">Open questions to Max!</div>Max,
I've decided to post and ask this openly, as I'm sure someone will be interested/learn something from your experiences. I hope you don't mind if I steal you away for a few minutes for your insight. (Maybe Charlie can answer too... maybe.)
When developing a tool set (like Decoda), is there a framework or existing program you build off of or do these kinds of projects usually start from scratch?
Is it strange developing an IDE, inside an IDE? For instance, is it difficult to debug a program that... needs to debug a program? How do you work around obstacles where you know you need to test a feature, but you can't test it (or has this situation ever come about)?
How does creating a tool like the NS2TR, which needs the major framework of the game (I assume), compare to creating a tool like Decoda?
When you decide to develop a tool (for whatever reasons, maybe none exists or some do that simply don't satisfy your requirements), where do you draw the line and say "This is all I need this tool to do" and stop adding the "It be nice to have..." features?
Thanks for taking the time to read this, and I hope for some good responses! And if this topic takes off, I invite other community members to get involved and fire off questions (and probably pull you away from more important things!).
I've decided to post and ask this openly, as I'm sure someone will be interested/learn something from your experiences. I hope you don't mind if I steal you away for a few minutes for your insight. (Maybe Charlie can answer too... maybe.)
When developing a tool set (like Decoda), is there a framework or existing program you build off of or do these kinds of projects usually start from scratch?
Is it strange developing an IDE, inside an IDE? For instance, is it difficult to debug a program that... needs to debug a program? How do you work around obstacles where you know you need to test a feature, but you can't test it (or has this situation ever come about)?
How does creating a tool like the NS2TR, which needs the major framework of the game (I assume), compare to creating a tool like Decoda?
When you decide to develop a tool (for whatever reasons, maybe none exists or some do that simply don't satisfy your requirements), where do you draw the line and say "This is all I need this tool to do" and stop adding the "It be nice to have..." features?
Thanks for taking the time to read this, and I hope for some good responses! And if this topic takes off, I invite other community members to get involved and fire off questions (and probably pull you away from more important things!).
Comments
When creating GUI applications you usually build off of some sort of framework that handles the basic user interface stuff. In the past I've built tools with Win32, MFC and .NET, but for Decoda I decided to try out the cross platform wxWidgets library. That was definitely the right decision for Decoda, and I'm also planning on using it for any other tools I create in the future. For Decoda I also used the Scintilla control which handles a lot of the common things you would want when editing source code. That's pretty much as must have if you're doing something like this.
<!--quoteo(post=1658164:date=Oct 27 2007, 11:02 PM:name=digz)--><div class='quotetop'>QUOTE(digz @ Oct 27 2007, 11:02 PM) <a href="index.php?act=findpost&pid=1658164"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Is it strange developing an IDE, inside an IDE? For instance, is it difficult to debug a program that... needs to debug a program? How do you work around obstacles where you know you need to test a feature, but you can't test it (or has this situation ever come about)?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes it's very strange. What makes it troublesome is that Decoda is made up of two pieces, the frontend and the backend. The frontend is like a normal program, but the backend actually executes inside of the application being debugged. This means that to debug Decoda I have to setup two debuggers, and unfortunately Visual Studio sometimes has issues with the debugger connected to the backend.
<!--quoteo(post=1658164:date=Oct 27 2007, 11:02 PM:name=digz)--><div class='quotetop'>QUOTE(digz @ Oct 27 2007, 11:02 PM) <a href="index.php?act=findpost&pid=1658164"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->When you decide to develop a tool (for whatever reasons, maybe none exists or some do that simply don't satisfy your requirements), where do you draw the line and say "This is all I need this tool to do" and stop adding the "It be nice to have..." features?<!--QuoteEnd--></div><!--QuoteEEnd-->
When I've created tools in the past I've always had to stop once the basic functionality was there, since there was never enough time in the schedule to implement non-essential features. On Titan Quest we were short a tools programmer the entire project, so we just snuck the tools work into the engine programmer's schedules wherever we could. The problem is that a lot of those features that aren't technically essetial can still make a huge difference. Take undo for example; sure it's not necessary, but that's a huge time/sanity saver for whoever is using the tool.
One nice thing that happened once we decided to commercialize Decoda was that all of the sudden it made sense to implement all of those "nice to have" features and make the whole thing really polished. There's lots of stuff in there I never would have done if it was just for our internal use, but when I'm using Decoda I'm sure glad those features are there.