Windemere Source
- Download Info
-
- Author(s): Merlin
- Categories: Development, Miscellaneous, Source, Dink.exe
- Downloads: 137
- Main
- Reviews
- Versions
- File Discussion
- Contribute
- Add a Screenshot
- Write a Review
In 2003 after much cajoling, Seth of RTSoft decided to release the Dink engine's source upon the world. For those who managed to preserve their sanity after reading through the entirety of dinkvar.h, great potential hung in the air, and the prospect of a community-developed "Dink 2" successor engine was on the cards. With a ton of mind-blowing proposed features such as OpenGL rendering of infinitely scrolling maps complete with backwards-compatibility, "The Dink Project" as it was then called, was hotly anticipated by d-modders and Dink enjoyers everywhere.
Development started off strongly with great enthusiasm. Lead developer Merlin was soon able to recruit several others to the team in the form of "Desplesda" and "DeathWish" who were eager to get to work in writing and implementing the successor to DinkC, as per a language spec written by Desplesda. Intended to be compatible with Dink's existing scripting engine, "DinkC++" was to allow modders to take advantage of Windemere's new features according skill level and overall needs. After attempting to implement DinkC++ with a proper parser using Flex and Bison, things were looking up, and the future was bright.
The changelog provides a brief insight into how Windemere's development was progressing around this time, along with which technologies were to be used. It appears that sound was to be handled by either OpenAL or FMOD, providing support for Ogg Vorbis and MP3 along with traditional General MIDI files. The primary image format was to be PNG, and drawing to the screen was performed with SDL and OpenGL. These choices, along with many others, were an occasional point of contention, and many of the changelog entries are rife with bickering and swearing over some minor reversion, or disagreement over implementation. Although it is difficult to discern whether this was genuine discontent or just banter, the former seems somewhat more likely, and as one starts from the bottom and scrolls up, the entries made by DeathWish and Desplesda slowly dry up due to them presumably losing interest and then moving on by roughly mid-2004.
After the disappearance of the other two devs, the initial promise of backwards-compatibility with the existing engine was declared impossible. Merlin had determined that Dink's engine would be unable to cope with the demands placed upon it by the new proposed features to the point where Windemere was to be rewritten from the ground-up as a sort of spiritual successor instead, with all of Dink's cruft discarded. This particular download is of the rewrite, rather than of the previous attempt which is presumably now lost to the sands of time.
Previously, Merlin had written a brief engine specification describing how every aspect of the engine would interrelate. It's still available on Sourceforge in case one is interested. The document proposed a modular system, in which a central kernel would dispatch tasks to specific servers to handle resource loading, and scripting execution along with the other engine's functions, almost like an operating system. Based upon his own document, Merlin single-handedly set out to rewrite Windemere.
By late 2004, Merlin had been working tirelessly and wrote a post to update the world on the overall state of his solo development endeavour. In his post, he remarks upon the departure of Desplesda and DeathWish, and how DinkC++ had to take upon a new form, christened "Talon". It appears Talon was to receive a few extra features not present in standard Lua, but ended up being little more than Lua 5.1 with ".tal" as the filename extension instead. Overall, the development process was looking less than promising despite the interest level from the community still being quite high. At the same time it appears there were at least a couple of graphic designers continuously rendering new graphics for the vaporware engine who no doubt were able to assist in stringing along the awaiting general public.
Browsing through this archive from early 2006 reveals that the source indeed stayed true to the design document, with each aspect of the engine relegated to a different file path. I could not get it to compile however, and I did not want to download the now antiquated Anjuta IDE to attempt to regenerate the project files, or attempt to use my incredibly poor C++ knowledge to attempt to coax it into building. Even if I had managed to get it to compile, what would be the point? The settings.tal file makes reference to a test.pak "Wmod" demo dataset for launching with, but this isn't included. In the readme, Merlin suggests looking through the relevant header for PAK files in order to make your own packer...
Unlike the town in Dink from which this engine derives its name, there was no valiant hero to save this Windemere from a slow starvation caused by poor planning, infighting, a complete lack of a map editor, or any formalised data specifications which the community could engage with. Although Seth was often been criticised for the poor quality of Dink's source, one thing he did get right was to release his in-house map editor, DinkEdit, to RTSoft staff early on in the development cycle without deviation from the initially established spec. As it stands, the data from the Dink 1.01 pre-release demo will work perfectly fine in every subsequent release, and the initial public release of DinkEdit can still be used today to make d-mods with.
It appears that even at this point Windemere still had a slight amount of life left, and two years after the release of this source archive, Merlin returned briefly to see if anyone was still interested in the possibility of his grand vision reaching fruition along with the prospect of an actual game to go with it. He claimed that "Making an editor isn't *that* much of a deal", despite the overwhelming evidence proving the contrary over the preceding 5 years. Although his post gained several replies telegraphing there still being some apparent interest, nothing came of it, and afterwards Windemere finally succumbed to starvation.
Overall, I feel most sorry for the artists whose creations never truly got to see the light of day in their intended form, other than in a few graphics packs available as separate downloads. Windemere's development (or lack-thereof) may serve as a warning to any aspiring game artist out there. If a C++ dev approaches you with grand offers of a game engine, always make sure there's a map editor to go with it.
As a side note, Desplesda did not die after eating Vegemite as Merlin had assumed, but instead later on used his language spec expertise to develop a dialogue tool called "Yarn Spinner" that has been used in many popular titles and that I was even considering for inclusion in YeOldeDink at one point. It's a small world after all.
Development started off strongly with great enthusiasm. Lead developer Merlin was soon able to recruit several others to the team in the form of "Desplesda" and "DeathWish" who were eager to get to work in writing and implementing the successor to DinkC, as per a language spec written by Desplesda. Intended to be compatible with Dink's existing scripting engine, "DinkC++" was to allow modders to take advantage of Windemere's new features according skill level and overall needs. After attempting to implement DinkC++ with a proper parser using Flex and Bison, things were looking up, and the future was bright.
The changelog provides a brief insight into how Windemere's development was progressing around this time, along with which technologies were to be used. It appears that sound was to be handled by either OpenAL or FMOD, providing support for Ogg Vorbis and MP3 along with traditional General MIDI files. The primary image format was to be PNG, and drawing to the screen was performed with SDL and OpenGL. These choices, along with many others, were an occasional point of contention, and many of the changelog entries are rife with bickering and swearing over some minor reversion, or disagreement over implementation. Although it is difficult to discern whether this was genuine discontent or just banter, the former seems somewhat more likely, and as one starts from the bottom and scrolls up, the entries made by DeathWish and Desplesda slowly dry up due to them presumably losing interest and then moving on by roughly mid-2004.
After the disappearance of the other two devs, the initial promise of backwards-compatibility with the existing engine was declared impossible. Merlin had determined that Dink's engine would be unable to cope with the demands placed upon it by the new proposed features to the point where Windemere was to be rewritten from the ground-up as a sort of spiritual successor instead, with all of Dink's cruft discarded. This particular download is of the rewrite, rather than of the previous attempt which is presumably now lost to the sands of time.
Previously, Merlin had written a brief engine specification describing how every aspect of the engine would interrelate. It's still available on Sourceforge in case one is interested. The document proposed a modular system, in which a central kernel would dispatch tasks to specific servers to handle resource loading, and scripting execution along with the other engine's functions, almost like an operating system. Based upon his own document, Merlin single-handedly set out to rewrite Windemere.
By late 2004, Merlin had been working tirelessly and wrote a post to update the world on the overall state of his solo development endeavour. In his post, he remarks upon the departure of Desplesda and DeathWish, and how DinkC++ had to take upon a new form, christened "Talon". It appears Talon was to receive a few extra features not present in standard Lua, but ended up being little more than Lua 5.1 with ".tal" as the filename extension instead. Overall, the development process was looking less than promising despite the interest level from the community still being quite high. At the same time it appears there were at least a couple of graphic designers continuously rendering new graphics for the vaporware engine who no doubt were able to assist in stringing along the awaiting general public.
Browsing through this archive from early 2006 reveals that the source indeed stayed true to the design document, with each aspect of the engine relegated to a different file path. I could not get it to compile however, and I did not want to download the now antiquated Anjuta IDE to attempt to regenerate the project files, or attempt to use my incredibly poor C++ knowledge to attempt to coax it into building. Even if I had managed to get it to compile, what would be the point? The settings.tal file makes reference to a test.pak "Wmod" demo dataset for launching with, but this isn't included. In the readme, Merlin suggests looking through the relevant header for PAK files in order to make your own packer...
Unlike the town in Dink from which this engine derives its name, there was no valiant hero to save this Windemere from a slow starvation caused by poor planning, infighting, a complete lack of a map editor, or any formalised data specifications which the community could engage with. Although Seth was often been criticised for the poor quality of Dink's source, one thing he did get right was to release his in-house map editor, DinkEdit, to RTSoft staff early on in the development cycle without deviation from the initially established spec. As it stands, the data from the Dink 1.01 pre-release demo will work perfectly fine in every subsequent release, and the initial public release of DinkEdit can still be used today to make d-mods with.
It appears that even at this point Windemere still had a slight amount of life left, and two years after the release of this source archive, Merlin returned briefly to see if anyone was still interested in the possibility of his grand vision reaching fruition along with the prospect of an actual game to go with it. He claimed that "Making an editor isn't *that* much of a deal", despite the overwhelming evidence proving the contrary over the preceding 5 years. Although his post gained several replies telegraphing there still being some apparent interest, nothing came of it, and afterwards Windemere finally succumbed to starvation.
Overall, I feel most sorry for the artists whose creations never truly got to see the light of day in their intended form, other than in a few graphics packs available as separate downloads. Windemere's development (or lack-thereof) may serve as a warning to any aspiring game artist out there. If a C++ dev approaches you with grand offers of a game engine, always make sure there's a map editor to go with it.
As a side note, Desplesda did not die after eating Vegemite as Merlin had assumed, but instead later on used his language spec expertise to develop a dialogue tool called "Yarn Spinner" that has been used in many popular titles and that I was even considering for inclusion in YeOldeDink at one point. It's a small world after all.
Lua? LUA!!?
shoot, I have never met a language spec that I didn't understand... until Lua. I'd rather haggle with shell quoting conventions.
Windemere appears to suffer from Empty Constructor Syndrome and Third Party Dependancy. (While TPD can be a good thing, it should be kept within reason.)
In one header, it appears as if a member is being defined *and* declared. (The "extern" keyword is being ifdef'd.)
And log.cpp scares the shoot out of me.
Overall, a very good attempt, on par with the other attempts I've seen (including my own).
If nothing else, it inspires me to do better on my next revision.
shoot, I have never met a language spec that I didn't understand... until Lua. I'd rather haggle with shell quoting conventions.
Windemere appears to suffer from Empty Constructor Syndrome and Third Party Dependancy. (While TPD can be a good thing, it should be kept within reason.)
In one header, it appears as if a member is being defined *and* declared. (The "extern" keyword is being ifdef'd.)
And log.cpp scares the shoot out of me.
Overall, a very good attempt, on par with the other attempts I've seen (including my own).
If nothing else, it inspires me to do better on my next revision.
Hard to rate this. I would call it a 10, but only about 70% of the minimum is there so far.
What's there is very clean, cross-platform and could rival the big companies games. It needs an editor,(especialy for mapping) and some tweaking from the comunity to realize that potential.
What's there is very clean, cross-platform and could rival the big companies games. It needs an editor,(especialy for mapping) and some tweaking from the comunity to realize that potential.
