[DM-dev] Re: Suggestions for work on DungeonMaker (Peters reply)
Brought to you by:
acdalton,
henningsen
From: George H. <kh...@op...> - 2004-02-03 04:53:11
|
Here is Peters reply to my first message, this should bring everyone up to data on what we are think. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ Hi George, this sounds like we might actually be able to work together on this. Very neat. I wrote you a second email 3 days after the first, in which I basically suggest the same course of action that you propose. I attach the text at the end of this mail in case it got lost somehow. >I have included some thoughts on how to proceed, sorry if I come of >a little `strong', but as a senior developer much of my work day is >spent evaluating risks and coming up with courses of action and the >such. Our expertise may well match up nicely. I have a PhD in mathematics, and maybe 5 years of experience developing games, which pose their special challenges. One thing I have learned about game development is that it is essential to get the game playable as soon as possible, and then to make sure it is actually fun to play and becomes more so as development progresses. My day-to-day tactics is to make the most essential improvement next. This precludes doing detailed step-by-step pre-planning, and if one gets the basic architecture wrong, one will have to do a total re-write eventually. That's one area where I anticipate you could be of great help:-) Anyway, that describes my style of writing code. >I agree that `playing' in 3D would be very cool, and I suspect it will be >a significant undertaking. Thinking about, I see two issues, > >1. Converting the 2D world into a 3D world and managing movement. Actually, this should not be all that hard. All I have to do is to output a DM-dungeon in the internal Cube-map format, and then *<snap like magic - through the power of using library code>* "managing movement" won't be neccessary: not only will it be possible to play right away in there (fighting MOBs I mean), but we can actually network and play together in the same Dungeon. One thing that will be neccessary (and this will be quite laborious) is to develop a whole new version of the Dungeonmaker which can place all kinds of stuff one might want in CUBE or in PENandPAPER RPGs, such as powerups for Health, Mana, Energy, Money, Whatnot... or Pools of Lava, Water, Blood, Whatever... HiddenTrap Type A,B,C,... etc...etc... this will be quite a job, but I want to do that because I think acceptance of DM may be low because this last step (parts of which must be done specifically for a specific graphics engine) has not been implemented. So that's where I want to go first. However, this potentially meshes very well with what you have suggested. We'd both be providing different "views" of the virtual world, I the 3D-view, and you the Data-Editor-view. The 2D-map-view already exists (in rather rudimentary form but fully functional really) in the current Dungeon-display. The program I want to work on will have data structures of growing (with later versions) complexity, and allow for an arbitrary number of views into this virtual world, each view in its own window, managed by the underlying windowing system. So there's no need (in fact it would be counterproductive) to encapsulate the current SDL-map in another widget or window frame - all the user needs is an option to open this "2D-map-view" from other windows (like the Data-Editor and the 3D-view) - and admittedly the SDL-window must be improved so it can be resized and scrolled and has its own icons (e.g. for opening the data view and dynamically centering the map). >2. Developing the AI for the MOB's. >The second issue is more `risky', there is not as much precedent in the >literature for developing intelligent NPC. Of course, this make this >issue all the more interesting! I am very interested in artificial life, and will be implementing AI as evolving alife entities. However, for the start I plan to implement a "smart-map", where much intelligent info is contained in the map (this will be part of the next version DM-data structure, with precomputed paths to exits, "chokepoints", social hubs, etc). The attempt to develop "intelligent" AI will then start from this relatively high base line. This strategy is also the reason I want to go with grid-based maps, because on such maps pathfinding is so cheap that it is relatively easy to implement "intelligent-looking" behavior. My own "milestone map" btw has always been as follows: 1. MazeRunner, a Pacman-type labyrinth-traversal where one has to avoid being hit by MOBs. This was planned to be 2D, and would be proof-of concept for the SmartMap, also really an essential tool to make SmartMap design decisions. 2. DungeonHack, pure fighting in Dungeons, then develop MOB AI in top of that, later develop code for levelling skills, etc. 3. DungeonRaid after that, going through series of Dungeons/Labyrinths with the possibility that one may revisit Dungeons that already had human parties in them, or encounter other adventurer parties in a dungeon. Also implementing a Diablo-type treasure system with "Einstein's Sword of Hacking" (Einstein = +6 Intell, +2 Dex, Quick Wit; "of Hacking = +3 to strength, +4 to hit, +3 to wisdom(because hackers are cool dudes:-)" etc etc However, now that I want to do "DungeonMaker 3D" next, MazeRunner might not get released as its own game (might suck in 3D). However, if you want to mess with the 2D-SDL-view, we could do that, I'd actually like that. Would also be a very good tool to test Dungeon-designs by test-playing them quickly. >I would think that the first, tentative steps here would be to imbed the >current >DungeonMaker interface into a GUI of some sort. I can see this being a >simple application with a main window and a menu bar. Yeah, but make it a separate window from the existing map-view. I would suggest the following capabilities (all the while keeping in mind that the "data-editor" should in the future also be able to work with AI-files or trap-script-files and other types of files, not just the current design-files). Allow access to all design-files in a specific folder/directory. Select one of these files -> choose to open in modes * Execute = construct a dungeon with this design, show in *2D or in *3D or in whatever... * File-content - Read-only * File-content - Edit-mode (normal text-editor functions dropped in) make it possible to display any set of selected lines, not just adjacent ones (important for design process) In the last two modes *"Help-mode" is available as follows: When a line in the design file is selected (or cursor is in that line) and a *button is clicked, a new help window opens with an extensive commentary explaining that lines data and their use. Also possible: Short data explanation in pop-up window when *right-click on line. Or two buttons for the short/long data version. I could certainly write the explanations... One thing that is in the current Linux version (which uses the command line interface in a second window) is the option to display the number of the current Builder/Crawler-generation during dungeon construction. This is absolutely essential for dungeon design (you have to know what generation has what effect to sensibly edit the files), so that will also have to be available in the editor-view. >This would reproduce the current ability of DungeonMaker, however by using >one of the cross-platform frameworks (QT, wxWindows, FLTK, etc.) the >interface will be the same on all platforms. I have no real preference on >these >frameworks, having worked with them all, however FLTK does seem to be the >easiest to work with (and there is a DevPak for DevC++). I have done a >quick >search and there seems to be precedence for embedding an SDL window into >a widget from any of the afore mentioned frameworks. I've only worked with Qt, and while it is a pleasure to work with, it is expensive to use on Windows, so your choice of FLTK seems astute. I have one point to consider here though, I want to keep the option open of eventually releasing a commercial, closed-code, data-encrypted version of the project, and therefore cannot mix the code with aggressive OS-licenses like the GPL. All has to be LGPL or similarly unencumbered. Is that the case for FLTK?? BTW, what's your take on DevC++? Is it any good? Or do you recommend another gcc-based development environment for Windows? >Once this is done, the next perceived task would be to add a few new >features, >most notably would be a save and open feature for dungeons. This would be >necessary when the move to 3D is made so games could be saved and restarted. >Of course this means defining a DungeonMaker file format. The DM-dungeon data is already in a single data structure which is made from STL-components, so saving/loading it is straightforward. Whatever we do when new data gets added (MOBs, powerups, traps, lavapools, etc) must be well thought out, and as general as possible. I count on you as an experienced Pen-and-paper-RPG dude to come up with ideas on what-all we will want. Hopefully we can define a file format that covers all map elements once and for (all/the next 5 years). >A neat extra >would >be to provide an export feature. As a start, exporting to a bitmap and jpeg >would be great. Because, I still play traditional pencil-and-paper >role-playing >games (e.g. Role Master or Dungeons and Dragons) I make use of a tool >called Campaign Cartographer (CC) and I would like to see a conversion >between DungeonMaker and CC. That would be lovely, and I think I can leave that totally up to you. Anyway, I don't see how it would impact other parts of the project. You should proceed so that things will be easy when new map-items like lava-pools appear on the DM-maps. >Once this is done, we can concentrate on `playing' the dungeon in 2D, >implementing >player movement and MOB's AI algorithms. Of course being able to reload a >dungeon allows for training of the MOB's. We can play it in 2D or in 3D, whatever becomes playable first, and then in both simultaneously. I want the game to be such that the player will use the 2D-map for strategical planning and moves (possibly for fast runs), and the 3D-map for tactical encounters/fights, and just to go sightseeing. As for the 2D-view, the map can already be zoomed to any degree i.e. we can determine how large each square is on the screen. Players and MOBs should be circles with different colors, and their size should reflect the fact that most entities will be able to walk 2 abreast in even the narrowest tunnels. (Otherwise it's too easy to block the player which is no fun). I have in fact a whole book with design ideas, so I will probably have answers to most anything you come up with. It would be supercool if you liked the alifegames-project and would want to participate. Take care, Peter What follows is the second email I sent you, in case it got lost: Hi there, I had an idea what you could do if you wanted to help the DungeonMaker along. This would be a fairly easy and straightforward bit of programming: As you may or may not know, the Linux version has a nice command-line interface, where one can choose to run a new version of the same design, or go on to the next demo-design. In the Windows version, one must manually rename the design file to see different demo-designs. If you'd like to, you could write a windowed interface that runs the user through the different designs in similar fashion. All you'd have to do is write a new main()-function - the Linux main()-function could be simplified quite a bit, it is only so complicated because it is possible to show the design during or after the dungeon-creation-process. Also possible if you want to get into it some more would be to expand the interface so that the user could interactively edit the design files and run the program again with modified design data. (Of course this is already possible by opening the design file in a text editor, so that's not really that useful. But it would be more elegant...) Take care, Peter |