The Dink Network

Nexis's Profile

2003-07-11 20:08:20
Peasant They/Them
Just happened to browse onto the site and what do I see. Well anyways, I can't afford the time to get involved in another project like this after working on WDE (had to force myself off that project). Besides, I really need to start and finish my own game. But I thought I might give everyone a few suggestions on what might be done.

First off the suggestion of some source control is a very good idea. You definitely don't want the codebase splitting off into multiple directions.

The absolute first thing that should probably be done is clean up the source code. Don't do anything else until this is done. Looking at RTSoft's board I saw that Seth had said that there were 30,000 lines of code in mostly 3 files. 3 files is WAY too few files for that amount of code, especially with C++. You will need to split these 3 files in probably 10 times that to even come close to organising them. C++ classes should also be implemented (moreso at least) to contain the code for these files. Looking at the WDE might help in this regard, but perhaps not.

One thing that should definitely be done is port dinkc to a proper interpretter by using a tool such as lex or yak. I'm sure there's better since from what I've seen of those two they are rather difficult to get to work with without a lot of work. The only one I've worked with is Visual Parse which is simply awesome but at $500 a copy not a viable solution. Unless you've had a class on compiler design this could be a difficult thing to set up.

Graphics: 16-bit/32-bit color. I would recommend supporting both but you should give preference to 16-bit for speed and to reduce download size. Adding jpeg support might be an interesting addition to reduce file size. Higher resolutions are not possible without changing the dink format and so should be probably not be done. You also wouldn't want to switch the code to directx 8 or 9 since you won't be using any of the features in them. Better to keep a wide userbase by not requiring users to install them.

Porting: Since someone mentioned porting to other platforms you must keep in mind the game is coded in directx. If you do intend to make this work on other platforms you'll need a C++ cross platform library such as SDL. Allegro might also work although I don't know anything about it. This change should be done to the base source code if done. Splitting off the source code is not a good idea.

Sound/Music: I'm not sure if I can recommend this or not as it will mean very large downloads. Mp3 support should probably not be considered due to license issues and file size. Ogg vorbis support would probably work well. Those files tend to be half the size of comparable mp3s. It's also license free. For implementation you can either choose to use libraries such as fmod or the ogg vorbis library. The ogg vorbis library would be my choice although using fmod would allow support of many many different formats (mp3s, ogg, mods, midi, etc).

Movie playing: choose a high quality codec like divx (such as xvid). This will still absolutely wreak havoc on download sizes but is much preferrable to using mpegs or old avi files. Make sure to not require the codec to be installed but rather is included with the new game. Also make sure of the licensing before choosing a format.

Also, I would recommend splitting off the exes so that you keep the old dink.exe and create a new one. Unless you want to reproduce all the bugs (and I guarantee this will be problematic if you want to make real improvements to dinkc) this is probably the best solution. Maintaining the buggy old code inside the cleaned up code would just be a nightmare. And I'm not sure you can claim to be cleaning up code if you leave bugs in.

The dink editor: If you make any major changes to the dink file structures you will break both WDE and dinkedit. So are you going to update both or not.

File formats: I would recommend eventually changing the file structures so that the dink.dat and map.dat both fit into one file. Adding support for multiple maps seems like something that is desirable. The map.dat also only utilizes on average maybe 10% of the file efficiently. Whether you want to implement some of the features the extra data was for (sprite rotation, etc) or remove them is up for you to decide. You should probably also eliminate the .ff format (microsoft fastfile actually) in favor of some comprehensive wad format for all files. That would also eliminate the need for .d files which are compressed .c files, not compiled .c files.

Removing the limit on sprites and only using the space necessary would also be good. I would note that unless someone has a lot of time to spend you probably don't want to go messing with these files. The limit on tiles could also be removed (rather easily actually). You shouldn't even think of the possibility of eliminating screen scrolling as that would break nearly everything.

Really though, I'm not sure if it's worth it to change the file formats. Might as well start coding a different game from scratch than make major changes to these.

Well I'll stop here. I'm not in any way saying this is how things should be done rather that these are simply some ideas to discuss. I'm sure many people have other/better ideas since I'm just spouting these ideas off as I type.

This comment message board also really needs a preview option. A wider edit box would also be nice.

Nexis has released 7 files

Prophecy of the AncientsD-Mod, EpicExceptional 9.2February 26th, 2006
WinDinkedit Source CodeDevelopment, SourceExceptional 9.7May 21st, 2003
WinDinkeditDevelopment, UtilityExceptional 9.2May 21st, 2003
Ultimate CheatMiscellaneous, CheatExceptional 9.5July 12th, 2002
Dink.ini IndexDevelopment, TutorialFair 6.9February 5th, 2000
Prophecy of the Ancients v2.00 SourceDevelopment, SourceExceptional 9.5January 1st, 1998
Advanced Graphics TutorialDevelopment, TutorialFair 5.0January 1st, 1990