UPDATED: Dungeon Master 2.5
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
UPDATED: Dungeon Master 2.5
Well I think I should say this openly now that I finally have a clear view of what I will be trying to achive.
Since SAR MASTER seems to be dead I'm thinking of undertaking the DM2 clone project myself. I already talked with PaulH, Ameena and Adamo about it, but most people don't bother coming to flashchat to discuss things, so they don't know about it.
Basicly I'm trying to get a new clone up and running that will be greater in terms of graphics and technology than DM2 yet it will still have DM series gameplay. Most people will ask: Why not use CSBWin or RTC? The answer is simple: Both of them were based on an old old game that all of us love, but the gameplay there was simplified than in DM2. I admire both effort and work that George Paul Stevens and George Gilbert put into their works, but I yet have my own vision of Dungeon Mastery.
After my research on DM2 files I've found a lot of intresting things about the enigne that I didn't realise until then. I can't reverse engineer DM2 - it's too difficult concering the DPMI manager used, so I have to rely on two things: My personal findings and thoughts and Paul's CSBWin code. I have to use the latter one due to the fact that both games (DM1 and DM2) use the same damage/experience/world calculations, with minor additions that I worked out myself in DM2.
But what I'm trying to do won't be a direct port... it will have similar gameplay as DM series - same damage/magic calculations. But the general engine will be expanded - scripts added,enchanced graphics, better AI and better file structure.
I'm open for suggestions questions of what you would like to see in this clone. I already noted down some suggestions that won't cripple the gameplay, but i'm open for more.
The project page is here
In few days there will be a major update - New dungeon.dat file structre
Right now the work is advanced - soon I will start to develop a working dungeon/graphics editor.[/url]
Since SAR MASTER seems to be dead I'm thinking of undertaking the DM2 clone project myself. I already talked with PaulH, Ameena and Adamo about it, but most people don't bother coming to flashchat to discuss things, so they don't know about it.
Basicly I'm trying to get a new clone up and running that will be greater in terms of graphics and technology than DM2 yet it will still have DM series gameplay. Most people will ask: Why not use CSBWin or RTC? The answer is simple: Both of them were based on an old old game that all of us love, but the gameplay there was simplified than in DM2. I admire both effort and work that George Paul Stevens and George Gilbert put into their works, but I yet have my own vision of Dungeon Mastery.
After my research on DM2 files I've found a lot of intresting things about the enigne that I didn't realise until then. I can't reverse engineer DM2 - it's too difficult concering the DPMI manager used, so I have to rely on two things: My personal findings and thoughts and Paul's CSBWin code. I have to use the latter one due to the fact that both games (DM1 and DM2) use the same damage/experience/world calculations, with minor additions that I worked out myself in DM2.
But what I'm trying to do won't be a direct port... it will have similar gameplay as DM series - same damage/magic calculations. But the general engine will be expanded - scripts added,enchanced graphics, better AI and better file structure.
I'm open for suggestions questions of what you would like to see in this clone. I already noted down some suggestions that won't cripple the gameplay, but i'm open for more.
The project page is here
In few days there will be a major update - New dungeon.dat file structre
Right now the work is advanced - soon I will start to develop a working dungeon/graphics editor.[/url]
Last edited by Suule on Sat Sep 03, 2005 7:52 pm, edited 1 time in total.
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
Or rather give me time. A lot of it. I'm quite good at programming, and CSBWin source code is a great help. It's the lack of time I have a problem with.
Oh and determination. Determination is the key in programming. So many great projects were abandoned due to lack of it.
If I find something I don't understand in the code, would you be so kind as to explain it to me?
Oh and determination. Determination is the key in programming. So many great projects were abandoned due to lack of it.
If I find something I don't understand in the code, would you be so kind as to explain it to me?
- Paul Stevens
- CSBwin Guru
- Posts: 4318
- Joined: Sun Apr 08, 2001 6:00 pm
- Location: Madison, Wisconsin, USA
- cowsmanaut
- Moo Master
- Posts: 4378
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
png or TGA support allowing for alpha channels would be good for blending when you get higher color depth in the graphics as well as the higher resolution. It simply becomes more of an issue. It's one of the big reasons I gave up on my RTC graphics. I just hated the bad blending of harsh lines I got.
If you plan to implement this though using a 3D engine but still doing it 2D will help, since the alpha channels, color blending(darkness), scales/rotations/translations, and several other things can be done on the hardware instead of needing to write it out in the ever slow software methods. There is a very good article on using 3D hardware acceleration for 2D tile based games..
The only issue there is what mode to use if you use DX you need to look at a wine port for linux. Then there is mac. and what are they to do.. (shrug) depends on how portable you want it to be.
Just some ideas to throw out there.
If you plan to implement this though using a 3D engine but still doing it 2D will help, since the alpha channels, color blending(darkness), scales/rotations/translations, and several other things can be done on the hardware instead of needing to write it out in the ever slow software methods. There is a very good article on using 3D hardware acceleration for 2D tile based games..
The only issue there is what mode to use if you use DX you need to look at a wine port for linux. Then there is mac. and what are they to do.. (shrug) depends on how portable you want it to be.
Just some ideas to throw out there.
Yes. I was thinking of PNG/TGA support from the start. Mostly due to the alpha channels. That would also eliminate the need for transparency bytes.
I'm intrested in reading that article... anywhere I can find it?
And I won't be using DX. I think SDL will do better, since I want it to be multi-platform.
Thank you kindly for the ideas. All ideas can be beneficial to the project, since I can correct issues I've overlooked when I was doing my plans.
I'm intrested in reading that article... anywhere I can find it?
And I won't be using DX. I think SDL will do better, since I want it to be multi-platform.
Thank you kindly for the ideas. All ideas can be beneficial to the project, since I can correct issues I've overlooked when I was doing my plans.
-
- Ee Master
- Posts: 688
- Joined: Mon May 07, 2001 7:00 pm
- Location: Indiana, USA
- Contact:
It's quite simple: create four vertices for each sprite. These serve as the sprite corners. When you want to transform the sprite, transform each of these vertices. You could write your own sprite class that encapsulates transformation and rendering functions, or you could store the vertices raw and transform them manually. The point is to dump as much work as possible on the GPU since it's much better at manipulating graphics than the CPU.
You might want to support JPEG for larger, opaque images to conserve memory. PNG and TGA both support compression, but JPEG by far has the best compression scheme, particularly for photo-realistic images and textures. You can usually get 5-to-1 lossless compression with a good JPEG encoder (i.e., not Photoshop).
Network play isn't necessary, but I wouldn't mind seeing split-screen. Remember that old TG16 game Double Dungeon?
You might want to support JPEG for larger, opaque images to conserve memory. PNG and TGA both support compression, but JPEG by far has the best compression scheme, particularly for photo-realistic images and textures. You can usually get 5-to-1 lossless compression with a good JPEG encoder (i.e., not Photoshop).
Network play isn't necessary, but I wouldn't mind seeing split-screen. Remember that old TG16 game Double Dungeon?
Okay... I finished designing the script language today... the script language will resemble BASIC since it's kind of easy enough to learn.
The script language will have 8 global registers, 8 global counters and 8 script-accessed timers.
The very first script language version will have 64 limitations of 64 lines of code per script... it will be later expanded to up to 1024 lines of code as Zyx suggested.
The list of the Script code commands will be available soon. The editor will have a built in Script Editor similar to that in Starcraft.
Also... since I finished my work on the new Dungeon.Dat I can start coding the map editor...
The script language will have 8 global registers, 8 global counters and 8 script-accessed timers.
The very first script language version will have 64 limitations of 64 lines of code per script... it will be later expanded to up to 1024 lines of code as Zyx suggested.
The list of the Script code commands will be available soon. The editor will have a built in Script Editor similar to that in Starcraft.
Also... since I finished my work on the new Dungeon.Dat I can start coding the map editor...
- cowsmanaut
- Moo Master
- Posts: 4378
- Joined: Fri Jun 30, 2000 12:53 am
- Location: canada
http://www.gamedev.net/reference/articl ... le1972.asp
that's the article.. but there are lots more on game dev along the lines of optimising and such..
just thinking of rotation and scale on a fireball to make it look like it's twisting and flying smoothly into the distance. (as an example of what this could help with)
moo
that's the article.. but there are lots more on game dev along the lines of optimising and such..
just thinking of rotation and scale on a fireball to make it look like it's twisting and flying smoothly into the distance. (as an example of what this could help with)
moo
Game optimising is an Art I've learnt through my programming carrer... cause back when I started in the books it was written - ALWAYS optimize your code. So I've got it in my blood.
I think SDL could handle what is being said in the article... but instead of D3D, OpenGL will be used.
OpenGL and SDL will ensure portablity on other platforms
I think SDL could handle what is being said in the article... but instead of D3D, OpenGL will be used.
OpenGL and SDL will ensure portablity on other platforms
- Sophia
- Concise and Honest
- Posts: 4239
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
Here are my suggestions, that we talked about in the chat--
Relative teleporters: You can specify the destination as 1N, or 4W, for example, or even 1B (F for forward, B for Back) which, when operated only by monsters, makes a quick and easy way to set up perimeters.
RISC-approach to actuators: Basically, as few actuator types as necessary.
Multiple targets for actuators: RTC can do this, but DM couldn't. It's handy, though.
Lots of actuators: Unlimited would be best but if that's not possible at least make it so we won't run out designing our magnum opus dungeons.
Relative teleporters: You can specify the destination as 1N, or 4W, for example, or even 1B (F for forward, B for Back) which, when operated only by monsters, makes a quick and easy way to set up perimeters.
RISC-approach to actuators: Basically, as few actuator types as necessary.
Multiple targets for actuators: RTC can do this, but DM couldn't. It's handy, though.
Lots of actuators: Unlimited would be best but if that's not possible at least make it so we won't run out designing our magnum opus dungeons.
Relative teleporters - added to the database.
RISC-approach: I want to avoid as many workarounds and hacks as necessary. I'll try to have as few accutator types as necessary in order to do this
Multiple targets: I'm afraid that's not possible to do right now, since I'm basing things on DM1.
Acutator limit for now is 65356. That's a LOT...
RISC-approach: I want to avoid as many workarounds and hacks as necessary. I'll try to have as few accutator types as necessary in order to do this
Multiple targets: I'm afraid that's not possible to do right now, since I'm basing things on DM1.
Acutator limit for now is 65356. That's a LOT...
could you give more details about your project on your site (I mean what are you working on at the moment? what have been done so far)? Thanx
Spoiler
(\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/) (\__/)
Spoiler
(@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@) (@.@)
Spoiler
(>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<) (>s<)
Yes.... Sorry for the LONG waiting for an update but real life kicked in (ISP defects...), as well as school. I've been preparing a massive update on the project documentation and i had to cut it short due to the labwork in the first weeks... now that I'm finally settled with my timetable I can get the update done.
Once again: Sorry for the delays
Once again: Sorry for the delays