Is anyone planning to continue the necessary improvements for SDT? (1 Viewer)

[RegisNyx]

Interesting discussion here.
stuntcock
I guess the old guys of this board that maybe knew Konashion already tried to contact him and get the source files, without success. But i am wondering, with the flash decompiler around, don't we have the source files that we need? Or am I missing something? I decompiled the STD and now have all as files and can look at every function, only the complete fla is missing.

What i don't completely agree with, is that you can't do much to improve the performance of STD. I have seen more complex and graphically demanding flash games that ran a lot smoother. I'm not experienced when it comes to flash, but i find it hard to believe this is as good as it can get when there are so many counterexamples.

A few days ago i tried to make a swc file from the loader and STD codefiles to get some nice code-completion in CS6. It kind of worked but it was a huge drag. I used FlashDevelop with a plugin but had remove all compiler errors from the sources first. While Loader already had a lot invalid code, mainly some missing type declarations, the STD code base was insane. I guess most it comes from the difference in compiler strictness between as1 and as3 but i found a lot of totally broken methods in the STD files. I don't know if they get ever called but i think some of them could make some problems. Aside from that, while the STD itself is a huge accomplishment, its not very well written and often over complicated, i think many functions could be realized with one quarter of the code lines. But that's also due to the fact that we have now much better tools at hand then Konashion when he started.
In the end, instead of solving hundreds of compiler errors i made a script that removes all function bodies and only returns a valid value, this way i managed to create the swc file. Unfortunately only the one for the loader is working, the STD swc crashes the game^^ (when imported).

My point is, the code base is bad and doesn't get developed anymore. That's why i also think that something new is needed. But i also know just like stuntcock said that almost all ambitious projects to rewrite or completely recreate such a game on another platform or engine will fail for multiple reasons like the ones he mentioned. Every mod community has hundreds of them. Interestingly it's usually a user without coding experience that can't contribute anything to it suggest such projects, why might that be? ;-)

But i also have seen such projects succeed, it depends on how you do it. If say you want to completely rewrite STD you will fail. If you say you want to create a 3D STD you are in wrong forum, no modder here will be able to help you. If say you want to port STD to a new engine you will also fail.

In my limited flash and STD knowledge and also almost no knowledge about this mod community and forum i see two possible ways:
opt 1
If we are able to create a working projectfile for STD that could be modified that would already be a huge success. After that, one could try to implement the loader into the main STD. That would also be a huge success and enable more possibilities for future development.

opt 2
if you want to create something totally new you have to start small, very small. Talk to modders and content creators (like @sby), see what could be used to create a better STD. Dragonbones for example looks very interesting. After you decided what software and libraries to use one would need to work on a little demo. Not much, only needs like 5% of the functionality of the original game (should be hard enough to get to 5%). After that you present it and try to get people motivated. It works much better when there is something to see and grasp, that makes them think its actually worth investing into it.
And there has to be gain! Be it improved performance or better mod support, it should make things easier.

I have seens projects that started out like this actually succeed, but it also depends on the community.

 

[stuntcock]

But i am wondering, with the flash decompiler around, don't we have the source files that we need? Or am I missing something?

We can decompile the source, but we're missing all of the inline documentation and process documentation. There are many "dead" functions in the code which never get invoked, and others which get invoked but never do anything useful (example: the girl has an arousal statistic which is supposed to show vaginal secretions along her inner thighs -- but that doesn't happen because the artwork doesn't exist). There are many possible reasons why these features might be inactive:

• they were partially implemented and left incomplete as a TODO thing (but then @Konashion got bored and chose to work on something else instead, or decided that the TODO thing was low priority)
• the code was partially completed and @Konashion decided that he would defer it until he found time to draw the necessary artwork
• the code was deliberately disabled (and/or partially stripped out) because it caused instability, incompatibility, or unacceptable degradation of runtime performance

Without knowing why a feature is incomplete, we can't know whether it would be a good idea to re-implement it. We might spend a few days reviving a minor feature, and then run into the exact same conflicts which forced @Konashion to remove it in the first place. We might fix all of the code errors, and then realize that there are no actual sprites (so then ... what? do we pause the project for a few weeks while we try to find a volunteer artist to draw the missing stuff?). We might completely revive the feature, and then find that nobody is willing to use it because it chops down the framerate by 20%.

I decompiled the STD and now have all as files and can look at every function, only the complete fla is missing.

If you really want it then talk to @DaoSoul; he may be willing to send you a copy of his re-constructed FLA.

I have seen more complex and graphically demanding flash games that ran a lot smoother. I'm not experienced when it comes to flash, but i find it hard to believe this is as good as it can get when there are so many counterexamples.

Those games can be optimized -- merging shapes into comoving sprites, resolving dynamic objects (e.g. blood splatters) into static images after a few seconds, and vastly reducing the total number of visible layers.

SDT cannot be optimized in this way, because doing so would remove the potential for runtime customization (e.g. skin tone adjustment, RGB shifting of clothing layers, etc). Refer to the previous page for a minor example involving arm+sleeve.

while the STD itself is a huge accomplishment, its not very well written and often over complicated, i think many functions could be realized with one quarter of the code lines.

Agreed.

If we are able to create a working projectfile for STD that could be modified that would already be a huge success. After that, one could try to implement the loader into the main STD. That would also be a huge success and enable more possibilities for future development.

The performance limitations are almost entirely due to Flash itself. We could workaround some of them (e.g. by merging some clothing layers) but that would also diminish the game's customization/modding potential. And it would still leave us with several of the inherent problems of Flash:

• modding involves licensed software rather than freeware tools - which restricts the pool of available modders
  • imagine what would happen if Skyrim modders needed to use 3dsMax instead of Blender
• Flash has limited support on many platforms (e.g. iOS) and is facing end-of-life on others
  • people are reluctant to get involved with tech and tools which they believe to be dying
• Flash/AS3 allows for extremely unsafe and promiscuous code
  • it's harmless to the host PC (because of the Flash sandbox) but it's detrimental to SDT modding as a discipline
  • if you look at the old (pre-Loader, pre-template) SWF files, they're full of ON_FRAME_ENTER functions which tend to collide with each other and fuck things up
  • nobody bothers with proper object orientation, visibility principles, or APIs ... because mods can freely poke at each other (and at the base game code) whenever they want

If you'd like to tinker with the SDT flash codebase as an archeology project (to learn from it, or get inspiration for new mods based on "dead" features) then please go ahead! But if you're hoping to do so as the basis for an improved sequel then I think you're misguided.

And there has to be gain! Be it improved performance or better mod support, it should make things easier.

It's very unlikely that we'd achieve strictly better mod support. Consider Second Life. It was originally moddable as fuck. You could spawn in an object which would then spawn other objects (including copies of itself). People could get really creative! But a single jackass with a "viral" item could crash any node in seconds. Nowadays the modding potential has been tightened down; the freeform creativity of modders has been restricted in order to deliver a more consistent and enjoyable user experience for regular folks.

A hypothetical SDT successor should probably aim for performance first, and then incorporate modding features in a more structured way (e.g. via some kind of API) which prevents mods from sabotaging core features or significantly disrupting the UX).

 

[RegisNyx]

We can decompile the source, but we're missing all of the inline documentation and process documentation. There are many "dead" functions in the code which never get invoked, and others which get invoked but never do anything useful (example: the girl has an arousal statistic which is supposed to show vaginal secretions along her inner thighs -- but that doesn't happen because the artwork doesn't exist). There are many possible reasons why these features might be inactive:

• they were partially implemented and left incomplete as a TODO thing (but then @Konashion got bored and chose to work on something else instead, or decided that the TODO thing was low priority)
• the code was partially completed and @Konashion decided that he would defer it until he found time to draw the necessary artwork
• the code was deliberately disabled (and/or partially stripped out) because it caused instability, incompatibility, or unacceptable degradation of runtime performance

Without knowing why a feature is incomplete, we can't know whether it would be a good idea to re-implement it. We might spend a few days reviving a minor feature, and then run into the exact same conflicts which forced @Konashion to remove it in the first place. We might fix all of the code errors, and then realize that there are no actual sprites (so then ... what? do we pause the project for a few weeks while we try to find a volunteer artist to draw the missing stuff?). We might completely revive the feature, and then find that nobody is willing to use it because it chops down the framerate by 20%.

i wouldnt even care about the unused and half finished functions. Of course it makes no sense to invest time into it, if you dont know how it was supposed to work or why it was made inactive, i would scrape all that stuff and create a functional and solid base.

Those games can be optimized -- merging shapes into comoving sprites, resolving dynamic objects (e.g. blood splatters) into static images after a few seconds, and vastly reducing the total number of visible layers.

SDT cannot be optimized in this way, because doing so would remove the potential for runtime customization (e.g. skin tone adjustment, RGB shifting of clothing layers, etc). Refer to the previous page for a minor example involving arm+sleeve.

Of couse you have to change features to optimize a game. For example the cum strains, they eat a lot of fps and dont even look so good imho, changing how cum is displayed in SDT could gain a huge fps boost.

The performance limitations are almost entirely due to Flash itself. We could workaround some of them (e.g. by merging some clothing layers) but that would also diminish the game's customization/modding potential.

Performance limitations depend on how you handle the tools you have. While i am not an flash developer, i got to know some people while working in the Oblivion mod community, that created some awesome looking games and animations in flash, SDT doesnt even compare.
Now you will say, the way SDT works, with all those layers, is what makes the performance so bad, but then it's not flash limitation, but rather a wrong way to implement things on a basic level. At least thats how it looks to me.

• modding involves licensed software rather than freeware tools - which restricts the pool of available modders
  • imagine what would happen if Skyrim modders needed to use 3dsMax instead of Blender
• Flash has limited support on many platforms (e.g. iOS) and is facing end-of-life on others
  • people are reluctant to get involved with tech and tools which they believe to be dying

The best points so far, i totally agree.

• Flash/AS3 allows for extremely unsafe and promiscuous code
  • it's harmless to the host PC (because of the Flash sandbox) but it's detrimental to SDT modding as a discipline
  • if you look at the old (pre-Loader, pre-template) SWF files, they're full of ON_FRAME_ENTER functions which tend to collide with each other and fuck things up
  • nobody bothers with proper object orientation, visibility principles, or APIs ... because mods can freely poke at each other (and at the base game code) whenever they want

This is actually intended. AS3 is still a script language. While its pretty advanced and supports a lot of features like OO and sometimes looks like a high-level programming language its still a script language with all the freedom and pitfalls. Its the same with all the Oblivion, Skyrim etc., mods conflict all the time.

If you'd like to tinker with the SDT flash codebase as an archeology project (to learn from it, or get inspiration for new mods based on "dead" features) then please go ahead! But if you're hoping to do so as the basis for an improved sequel then I think you're misguided.

A hypothetical SDT successor should probably aim for performance first, and then incorporate modding features in a more structured way (e.g. via some kind of API) which prevents mods from sabotaging core features or significantly disrupting the UX).

Ok, from what i read you dont view flash in such positive light, at least when talking about the future of SDT.

Lets give it some thought then. What technology could one consider for a successor? It should be something that addresses some of the problems we are facing right now but preserves some of main features like anime-style 2D graphics, the customizability and that it's easy to handle and install. I read something about unity in the thread but i think that's out of the question. Its too far away from what SDT is right now and i guess there is no willingness to turn to 3D.
As i see it, the only way to get away from flash is to do what adobe did, turn to html5. It would solve some of the problems.
Here is what i think,
Pros:
- It's future-proof technology that actually gains importance as time passes
- Its totally open source, there are a lot of free engines, IDE's and communities with knowledge to choose from
- It uses javascript, a widely used script language, what would make it easy for a lot of people to just jump in and help if they are interested, it lowers the hurdle (even for me, my company developes a web based ERP software and I use a lot of js)
- cross-platform, welcome apple and linux/unix user

Cons:
- Even with all the available gameengine's out there html5 is still years behind what flash can do, some things might not even be feasible
- everything would get harder, from the creation of animations to code mods, things would get alot more difficult than now (until we have established a standard)
- html5, contrary to popular belief, isn't better or more performant than flash, it does some things even slower
- it would be a complete redevelopment (what a surprise)

stuntcock what are your thoughts on this?

 

[stuntcock]

Of couse you have to change features to optimize a game. For example the cum strains, they eat a lot of fps and dont even look so good imho, changing how cum is displayed in SDT could gain a huge fps boost.

The cost is incurred in rendering. Until a semen strand appears on-screen, its FPS impact is zero. Even so, I'm forced to downgrade the physics in my hairstyle projects (reducing the number of "moving parts") because running a moderately detailed dynamic hairstyle introduces a noticeable slowdown -- before we've added a whole bunch of costumes and semen strands into the scene.

There's little that I can do about this slowdown as an animator. If a ponytail consists of seven independent moving parts, then I've implicitly added seven layers to the scene.

It's theoretically possible to ameliorate this problem as a programmer. I could rotate the ponytail sub-sprites into the correct orientation, render them into a single bitmap, and then add that bitmap to the scene. I'd need to repeat this operation for every single frame of gameplay. Would it improve FPS? Possibly. Would the reduction in graphical fidelity be acceptable? Probably. Is it worth the time investment? Meh. Even if it works, it would ameliorate only the dynamic-hair slowdown. Detailed clothing items, semen strands, etc... would still incur significant FPS penalties.

I'd rather do actual animation work instead of spending hours trying to kludge together a clumsy workaround for a small aspect of a systemic problem.

Now you will say, the way SDT works, with all those layers, is what makes the performance so bad, but then it's not flash limitation, but rather a wrong way to implement things on a basic level. At least thats how it looks to me.

Flash cannot selectively reduce graphical quality for specific elements while retaining high quality for others. That's a Flash limitation. AS3 has poor set operations. That's a Flash limitation (although it's not very significant for SDT). Flash does not employ hardware acceleration when compositing a multi-layer scene with incomplete occlusion. That's a Flash limitation.
The last problem is the most important one, and veteran Flash developers can work around it by carefully planning and limiting their use of layers. @Konashion did not do so. He added layers very liberally, which allows for subtle animation details (e.g. iris shrinkage) and heavy runtime customization (such as skin tone + skin HSL tint + tanlines). Perhaps he was unaware of this performance compromise when he began writing the game. Perhaps it was the looming spectre of a (very tricky!) refactoring & optimization pass which caused him to abandon the project.

We could rebuild SDT from scratch in Flash with careful planning of layer allocation. But it would be smarter to just build on a platform which actually uses the GPU - instead of leaving it idle while the CPU struggles desperately to cope with an inappropriate workload. Artists and animators would then be free to fulfill their high-fidelity fantasies instead of constraining themselves to the onerous limits of the tech.

Lets give it some thought then. What technology could one consider for a successor?

You've made some good points here. I need to run some errands at the moment; will reply later.

 

[aztlan]

"example: the girl has an arousal statistic which is supposed to show vaginal secretions along her inner thighs -- but that doesn't happen because the artwork doesn't exist"

That would be a cool mod - is the "only" think holding it back the lack of animations?

 

[Faceless]

Well, also the fact that the side-view reduces the visibility of vaginal secretions.

 

[frenchtoast]

iCons:
- Even with all the available gameengine's out there html5 is still years behind what flash can do, some things might not even be feasible
- everything would get harder, from the creation of animations to code mods, things would get alot more difficult than now (until we have established a standard)
- html5, contrary to popular belief, isn't better or more performant than flash, it does some things even slower
- it would be a complete redevelopment (what a surprise)

JS is still single threaded. 3D FPS games coded in HTML5 have to be very careful about how many things they do at once. It currently has no mechanism for syncing sound and video as reliably as compiled runtimes do. There is also no guarantee of comparable performance across multiple platforms due to multiple JS engines and in the case of mobile devices, limited memory/highly variant CPU speeds that suffer when code isn't native.

Sooner or later SDT will have to be recoded in another environment designed to leverage GPU (and possibly multithreading) and compiled to native/native-ish code. HTML5 isn't snake oil but it brought a lot of promises without the necessary underpinnings to dethrone runtime animation engines.

 

[DKOC]

Interesting continuation of this discussion.

If Flash has limitations that cannot be overcome, and a complete new advanced engine, like UE4/Unity 5, isn't acceptable, then the only workaround would be able to use another engine that is designed from the ground up to support 2D Vector graphics (like Flash does) almost exclusively.

Some examples I found are: (I'm not great at understanding the specifics of what Flash does or doesn't do, so forgive me if these suggestions wouldn't work at all)

1) Skia Graphics Engine
2) OpenVG
3) XNA Game Engine
4) Spinel
5) Cairo
6) GameSWF
7) MonkVG
8) NAS2D

Any of these possibly work or at least provide features that could be used?

 

[MyNameIsChef]

I wanted to rework SDT in Unity 5 in C#. I am terrible at drawing so I was planning on taking all the original assets by converting the vector graphics into pngs. The problem is, that the decompiled version of SDT contains files like: shape 820, shape 897 etc. It's impossible to efficiently find all the basic stuff I need to begin working on the code. Does anyone know of a better structured decompiled SDT with proper file names?

 

[stuntcock]

I am terrible at drawing so I was planning on taking all the original assets

You don't own that artwork, it isn't in the public domain, and @Konashion has not formally given permission for anyone to repackage or redistribute his work.

We offer download links for the Loader, but we strive to explain that it's an unofficial extension to the game. We tolerate the Loader bundles because they leave SDT.swf intact. We host the templates because @Konashion created most of them (users have since extended and improved them, of course).

Please ensure that you're familiar with the website rules. You're free to tinker with ripped art assets, but remember that any resulting products (such as demo/alpha builds of a game) must not be hosted on Undertow.club. You can link to them, but please don't upload them as attachments.

by converting the vector graphics into pngs.

Why bother? PNG files are huge compared to SVG, and have inferior quality. There are many options for using SVGs within Unity.

The problem is, that the decompiled version of SDT contains files like: shape 820, shape 897 etc... Does anyone know of a better structured decompiled SDT with proper file names?

I don't think so.

Flash doesn't really work that way. When you're drawing and assembling a complex image (such as a human body with various limbs, or a suit of clothing with various layers), you're not required to assign meaningful names to anything. So there's no guarantee that the names exist anywhere in the compiled game. Modders rarely need access to "complete and organized" set of sprites; we usually just hunt through the file for one or two items (which we'll recognize at a glance), extract them as SVGs, and then import them into Flash to serve as references.

For example: skin tones are implemented via named keyframes within a Shape definition. You could extract a set of fills (which collectively compose "Female Right Forearm - Pale Skin Tone"), but as far as SDT is concerned, that's her.rightForeArmContainer.upperArm.foreArm:2. There's no obvious and easy way to attach meaningful names to these items.

--------------------​

If you leave SDT running in a small window, then it's pretty straightforward to glance over the extracted shapes and cross-reference each item. You should be able to quickly identify something as a forearm, or a thigh, or whatever. It gets tricky when you're dealing with some of the weird layering elements (e.g. Underboob or LShoulder) ... but you can always just start assembling your character in Unity and then look for "gaps" in the body.

You can also use Faceless' FLA template to help identify the various shapes and understand their position (coordinate and layering) within the body. You won't be able to use these sprites directly (because they've been reduced to monochrome) but they might provide a handy "map" for some of your work.

 

[MyNameIsChef]

You don't own that artwork, it isn't in the public domain, and @Konashion has not formally given permission for anyone to repackage or redistribute his work.

We offer download links for the Loader, but we strive to explain that it's an unofficial extension to the game. We tolerate the Loader bundles because they leave SDT.swf intact. We host the templates because @Konashion created most of them (users have since extended and improved them, of course).

Please ensure that you're familiar with the website rules. You're free to tinker with ripped art assets, but remember that any resulting products (such as demo/alpha builds of a game) must not be hosted on Undertow.club. You can link to them, but please don't upload them as attachments.

Why bother? PNG files are huge compared to SVG, and have inferior quality. There are many options for using SVGs within Unity.

I don't think so.

Flash doesn't really work that way. When you're drawing and assembling a complex image (such as a human body with various limbs, or a suit of clothing with various layers), you're not required to assign meaningful names to anything. So there's no guarantee that the names exist anywhere in the compiled game. Modders rarely need access to "complete and organized" set of sprites; we usually just hunt through the file for one or two items (which we'll recognize at a glance), extract them as SVGs, and then import them into Flash to serve as references.

For example: skin tones are implemented via named keyframes within a Shape definition. You could extract a set of fills (which collectively compose "Female Right Forearm - Pale Skin Tone"), but as far as SDT is concerned, that's her.rightForeArmContainer.upperArm.foreArm:2. There's no obvious and easy way to attach meaningful names to these items.

--------------------​

If you leave SDT running in a small window, then it's pretty straightforward to glance over the extracted shapes and cross-reference each item. You should be able to quickly identify something as a forearm, or a thigh, or whatever. It gets tricky when you're dealing with some of the weird layering elements (e.g. Underboob or LShoulder) ... but you can always just start assembling your character in Unity and then look for "gaps" in the body.

You can also use Faceless' FLA template to help identify the various shapes and understand their position (coordinate and layering) within the body. You won't be able to use these sprites directly (because they've been reduced to monochrome) but they might provide a handy "map" for some of your work.

Thanks for your detailed reply. After what you've said about me not owning any of Konashion's artwork, I guess it's probably the best idea to not publish any of my work. Faceless' template will be a big help. Also I just found a Windows extension to preview svg files in Windows Explorer which should speed things up.

 

[DKOC]

I have a new question. A friend of mine had mentioned last month to me that he was learning WebGL, which is a version of OpenGL for web browsers that doesn't require other plugins to use the content but provides GPU rendering for browser applications. I bring this up as I had a continued discussion with stuntcock in the "bukkake" thread and wanted to ask something related to WebGL:

According to this link (https://helpx.adobe.com/animate/how-to/export-webgl.html) you can convert a Flash file to a WebGL format, and thus have all the visual elements rendered via the renderer used by WebGL which is GPU driven and then play the converted file within a supported browser that supports WebGL. Would something like this be able to "fix" the rendering bottleneck, or would it introduce new problems, namely mod compatibility? Also, would this require a FLA or a SWF file in general? I'd try it myself but I lack CS.

 

[stuntcock]

According to this link (https://helpx.adobe.com/animate/how-to/export-webgl.html) you can convert a Flash file to a WebGL format

There are a few complications here:

• "export to WebGL" is similar to the "export movie" function that's been in Flash since forever.
  • the point is that you're exporting a single pre-defined animation. You're not exporting an interactive game.
• it's theoretically possible to port the entire game into WebGL, but we'd need to rewrite most of the code (AS3 ≠ JS).
  
  • any rewrite project would be a challenge, because we don't actually have the original source code.
  • even if we had the original source code, there's a lot of information which doesn't appear in code but is instead defined in the FLA (such as the x,y coordinates of the eyebrow w/r/t the face, or the names of important keyframes). We can "recover" some of the source code via decompilation, but recreating the full FLA is much more difficult.
    
  • we also don't have permission from @Konashion to create derivative works. The whole project would be illegal.
• WebGL does not support all of the shading and blending options provided by Flash.
  • part of the reason why it's able to achieve much higher performance is that it simply disallows some of the fancier operations which cannot easily be hardware accelerated.
  • we'd need to rewrite the semen strand shader at a bare minimum, and probably several others as well.
  • WebGL can't do radial gradients. I'm not sure how popular they are among SDT modders; I've used a few of them in modding projects (example). All such elements would need to be redrawn.

would it introduce new problems, namely mod compatibility?

That's a major challenge. Every existing SWF would need to be repackaged into a newly-defined archive format (containing TXT, SVG, PNG, MP3, JS, etc). The new WebGL game would need to load these files, extract the contents, and then apply them to the appropriate places within the scene (or splice them into the game code at the appropriate hooks).

It's probably technically feasible, but it would take a lot of work to manually repackage thousands of SWF files.

------------​

Anyways, it wouldn't make much sense to merely port the game onto a more powerful graphical framework (even if we could magically fix the SWF-import problem). If you're going to put a significant amount of development work into a project, then you might as well do a ground-up rewrite on a proper game-development platform.

 

[DKOC]

I was worried you were going to say that :)

Clearly there is no "easy" button to solve the rendering issues and yes if one were to put the effort into doing a good port, they'd probably have fewer headaches if they just did it almost entirely from scratch with brand new code, assets, and no legal concerns with Konashion, assuming he ever returns. Hence, why no one has done a port and those that has suggested they'd undertake it have failed as well. Those that understand the work involved won't do it and only those who don't know the work involved will volunteer to do it without any idea of the shitstorm they are getting themselves into. Even designing and creating a "simple" (relatively) game takes an enormous amount of effort and SDT is not simple by any stretch of the word; rather I'd say its one of the most complex H-games out there only overshadowed by say the Klub-17 Sex Villa 2 with Hook 5.

---

I for one do know the difficulties of game making; I've been working on a commercial RTS in UE4 with a combination of Blueprints and as little C++ as I can muster (I hate Epic's Source code with a passion; spaghetti code, no comments, non-black-boxed functions and classes, and variables, functions and classes with terrible naming schemes) and it takes a lot of work to do what some might think is a trivial step. A good example for a RTS is panning, rotating, or zooming with the camera; takes quite a bit of code to implement those features. I also had a few failed projects where I bit off more than I could chew, promising much but failing to deliver. I feel bad for the promises I made with the projects, but, I learned from them and thus the RTS in UE4 is now possible after what I learned from them, so it wasn't a complete loss.

Don't make promises you can't keep!

 

[doesnotbuy]

Has anyone considered that the brainpower in this thread multiplied by the total time spent on posting in it could have produced a standalone open source SDT from scratch? It's not a very complex game. Why not just make a new one that doesn't bring my dual xeon, 64-gb RAM, triple SLI machine to its knees like it was the titular guest of honor?

 

[Pim_gd]

Because there's a worry that if you don't make it compatible with the currently existing content, it will fail due to lack of community support.

But just making a clone inherits all of the flaws of the original, so it'd be just as bad (just not as slow). So there's a question that you might want to include other "fixes".

Basically, the coding is easy, the requirements are hard, and thus we are stuck; nobody wants to spend a significant amount of time on something that might not work. ... Probably all it'd take is someone with a working basis, a good vision and the will to just do it all by themselves if no-one will help them - but then the question remains if it'd succeed with regards to inheriting the community that SDT seems to have.

 

[stuntcock]

It's not a very complex game. Why not just make a new one?

The game doesn't appear very complex on the surface, but it involves several different tasks:

• artwork
  • the game requires a significant amount of artwork (bodyparts, UI elements, clothing layers, etc).
  • existing SDT artwork cannot be reused in an open-source game because it was never released or licensed for such purposes
  • the artwork would need to become more complex for the sake of anatomy. For example: the girl's ankle should probably be able to bend.
  • therefore we can't just directly reuse artwork from existing SDT mods, not even if we got permission from the artists. We'd still need some artistic skill in order to allow those sprites to flex and bend in ways which they weren't originally intended to.
• animation
  • the new artwork must be rigged onto a new armature which can accommodate a large set of gestures and poses.
  • the armature must support more flexible and complex sexual positions (interaction with furniture, interaction with multiple characters, simultaneous handjob + fellatio, etc). There's little reason to do a "direct remake" which can handle only fellatio, because it would be inferior to the already-existing animtools mod.
  • the game will probably need to support multiple armatures (e.g. different body proportions for men vs women), while still retaining enough flexibility in its IK systems to allow for swapping (i.e. you could switch a M/F scene into a M/M scene without needing to redo all of the posing work from scratch).
  • the animation work can be greatly simplified if you use an existing animation suite ... but then you run into licensing complications. If you want the new game to be as mod-friendly as possible, then you can't expect apprentice modders to buy expensive software licenses.
• UX design
  • Flash has terrible or nonexistent support for mobile devices.
    
  • the new game should probably support mobile devices. That's easy from a coding/artwork perspective; very little additional work is needed in order to publish the game for multiple platforms. But it requires a lot of thought (or preferably: experience) to craft a user experience which can be replicated using only tap, pinch, and swipe gestures.
  • SDT has historically relied heavily on keyboard shortcuts; a heavily modded game might employ hundreds of them. It also relied on manual editing of external TXT files. Modders would need to abandon both of these approaches; they'd need guidance from a competent UX designer in order to ensure that their work is accessible to all users.
  • the UI and UX design should also give some thought to localization. This aspect of SDT was so badly neglected that the game's inability to display Cyrillic text was employed deliberately as a timing mechanism.
• coding
  • the SDT game has many minor features (such as blinking) which could be re-implemented with straightforward code-monkey work. But it includes a few core features which cannot be half-assed.
  • example: the game must include substantial modding capabilities, and that demands subject-matter expertise (i.e. the ability to import, inspect, compile, and integrate foreign code, allowing as much modding flexibility as possible but without exposing the host PC to any risk of intrusion or damage).
    
  • almost none of the existing SDT code can be reused ... and even if it could then it would be a bad idea to do so (because the code was never released or licensed for use in an open-source game).

There are very few people who can manage all of these tasks competently. @Konashion's game is notable because he was skilled enough to create the initial artwork, animations, design, and code by himself. He subsequently incorporated material written by others (such as the mod-loading system). And some of his code was of questionable quality (such as the bespoke physics stuff). Yet the game was playable and entertaining, even as a one-person project.

If there's another multi-disciplinary genius out there, then they could certainly undertake the creation of a similar new game. But we've seen few volunteers, so those geniuses are presumably busy with other stuff (like curing cancer, or proving P=NP, or just writing their own cool games based on original ideas). Therefore it probably needs to be a collaborative effort by several people (programmers, artists, designers, etc). It's probably not something that can be finished by one nerd in a basement somewhere. A lone nerd could create a shitty tech-demo (heck, I've done that), but the result wouldn't be a worthy successor to the SDT game.

 

[Vxr]

Man this really killed my mood. Sub-30 fps for a game like this is really a let down. I'm also kinda sad that the author didn't publish the code, I mean, if you don't want to work on it anymore, give others the possibility to do so.

That said, this is my first hentai game, can anyone recommend me something similar without these problems?

 

[stuntcock]

Man this really killed my mood. Sub-30 fps for a game like this is really a let down.

Any Ubisoft developer can tell you that 30 fps is much more cinematic! Seriously, though - the shitty framerate is a serious problem and we can totally understand if you find it intolerable. There are a few performance tweaks available, but if you're hoping for extremely smooth animations then it might be wiser to skip SDT entirely.

I'm also kinda sad that the author didn't publish the code, I mean, if you don't want to work on it anymore, give others the possibility to do so.

We don't know the circumstances behind @Konashion's departure. He may have lost interest and decided to stop working on the game -- or he may have suffered a sudden accident.

In the context of this thread, the source code isn't especially important. The availability of FLA project files would have simplified some modding tasks and enabled us to publish some official patches/bugfixes to the core games. But those files aren't especially useful in the context of a new development project which uses an entirely different game engine. Very little of the code could be directly ported or reused. And we have most of the game's code anyways; it's just in decompiled form (and therefore undocumented).

That said, this is my first hentai game, can anyone recommend me something similar without these problems?

There isn't an obvious answer to your question. If there was an improved version of SDT available (i.e. all of the features, none of the bugs, at 60fps) then everyone would already be playing that game and we wouldn't even be having this conversation :)

If you're looking for Flash sex games then there's stuff like Kasumi Rebirth. If you're looking for a well-animated sex simulator using anime character designs then check out Illusion.jp. If you like extensive modding and customization then there's TK17 and Skyrim Sexlab. If you're really interested in bondage and breathplay then I don't know ... but there's probably someone on Undertow who shares your tastes. Some of the available games appeal to mainstream sexual tastes; others delve more deeply into specific pairings and fetishes. Some games have very high system requirements; some can be played on your smartphone; some support VR headsets; some employ complex control schemes while others can be played hands-free; some games require expert technical knowledge in order to get the various mods and patches to cooperate. Some games are still being actively developed/modded while others are inactive but still have tons of content available. Some games parody well-known fictional characters or celebrities, while others allow you to invent your own characters.

Give us more information and we can try to make some useful recommendations. If you don't get the response that you're looking for, then you might find more luck by posting this question elsewhere.

 

[Vxr]

Any Ubisoft developer can tell you that 30 fps is much more cinematic! Seriously, though - the shitty framerate is a serious problem and we can totally understand if you find it intolerable. There are a few performance tweaks available, but if you're hoping for extremely smooth animations then it might be wiser to skip SDT entirely.

We don't know the circumstances behind @Konashion's departure. He may have lost interest and decided to stop working on the game -- or he may have suffered a sudden accident.

In the context of this thread, the source code isn't especially important. The availability of FLA project files would have simplified some modding tasks and enabled us to publish some official patches/bugfixes to the core games. But those files aren't especially useful in the context of a new development project which uses an entirely different game engine. Very little of the code could be directly ported or reused. And we have most of the game's code anyways; it's just in decompiled form (and therefore undocumented).

There isn't an obvious answer to your question. If there was an improved version of SDT available (i.e. all of the features, none of the bugs, at 60fps) then everyone would already be playing that game and we wouldn't even be having this conversation :)

If you're looking for Flash sex games then there's stuff like Kasumi Rebirth. If you're looking for a well-animated sex simulator using anime character designs then check out Illusion.jp. If you like extensive modding and customization then there's TK17 and Skyrim Sexlab. If you're really interested in bondage and breathplay then I don't know ... but there's probably someone on Undertow who shares your tastes. Some of the available games appeal to mainstream sexual tastes; others delve more deeply into specific pairings and fetishes. Some games have very high system requirements; some can be played on your smartphone; some support VR headsets; some employ complex control schemes while others can be played hands-free; some games require expert technical knowledge in order to get the various mods and patches to cooperate. Some games are still being actively developed/modded while others are inactive but still have tons of content available. Some games parody well-known fictional characters or celebrities, while others allow you to invent your own characters.

Give us more information and we can try to make some useful recommendations. If you don't get the response that you're looking for, then you might find more luck by posting this question elsewhere.

Thanks you so much for the quick and detailed answer, especially to such an old thread.

I guess we're screwed then, unless a legit team or game dev studio decides to do something similar.

I'll look up your suggestions, thanks!