- Dec 22, 2017
- 216
- 157
Sure yet here we are, wondering why it's not better than it is.
HTML What's wrong with most HTML games, how to improve them?
- Thread starter SerokMinmas
- Start date
Why not? We're talking about games that consist of text, images and, in some cases, videos. Then add a bit of link navigation and you're done. HTML + JS is absolutely fine.
I'm surprised every time someone comes around the corner with Unity, for example, but the game is basically just text and pictures, too.
- Dec 22, 2017
- 216
- 157
I honestly don't think I can respond to this in a single post, nor do I think I can convince you of my reasons why.
Long story short: it's based on my own experiences, talking to web developers and having been on the internet since the beginning (back before the browser ate everyone's ram). But primarily it comes down to things I personally value, like the development environment, user experience, reliability and performance. If you're used to clicking on a button and having to wait a second for something to happen then yeah, I guess it's fine.
There is value in allowing people to play games in a browser, but the price (in effort, performance & quality) for that convenience is too high for me. I don't mean to rain on your parade. I'm just over here, shaking my head.
Yeah I wouldn't exactly describe my game as "just text and pictures" but I clearly must've hit a nerve so I'll leave it there.
Your experiences are obviously not something anyone but you can speak to with authority, but this is ridiculous and just bad reasoning in my opinion. It's like me saying 2D platformers will never work on PC because background tile scrolling was too performance intensive for PCs back in the nineties. Your experiences on dial-up internet and ancient browser-war era HTML are not relevant to this topic.
If you're making a platformer or a very visually intensive game, because of the way downloading works and because of the overhead of the browser, you obviously don't want to use the web. Could you? Sure, but there's definitely significant issues with performance there, and you're gonna have to make compromises. But we're not talking about that, we're talking about text-based games with multimedia elements, which the web is extraordinarily good at, and was more-or-less designed for.
As far as user experience and reliability, I think you're just completely wrong. UX on browsers is much better than whatever UI you can string together on a traditional game engine. Users have access to assistive technologies like screen readers, high contrast modes, and more, just by virtue of it being in the browser. And you'd be hard pressed to find anything users are more comfortable navigating than an interface that looks like a website running in a browser. On top of that, CSS and HTML have there issues, but as languages for designing UIs, they're more than good enough, and you won't find better-documented languages anywhere else, so whatever you want to do, you can find resources to help.
As far as environments, this is subjective but also there is no singular web development environment, and there are so many to choose from and so many tools and transpilers, if anything, the issue is there's too much choice. What sort of tools did you use? VSCode is very good for web development, and really for development of anything. If it's dynamic typing that's got you down, you can use TypeScript. If it's HTML that you hate, we have HAML or Markdown. There's SASS and LESS for CSS. Also if you're the kind of psychopath that likes Python you've got CoffeeScript. There are so many options for how to set up your environment, it's hard to believe you would ever run out before you found one you liked.
Reliability and performance can be issues in browsers, and it is important that devs write performant code. This is hard, but it's not enough to turn most people off the platform. Again, we are talking about text-based games, not WebGL games, so while most of us need to write code with performance in mind, we aren't like optimizing until our fingers fall off. And really, the basic optimizations we do are not much different than the best practices you'd adhere to in any game engine or programming language.
I wonder if you've ever played a modern browser-based game. Hell, have you seen Google docs? It's like a whole word processor in your browser. It's crazy how when you hit the buttons, things don't take a second because it's not the nineties. I think you're just wrong. Which is fine, but still, condescension and confidence don't pair well with any level of wrongness, and I think that's what we're mostly reacting to. Case in point:
You're really not "just over there, shaking your head" because you're certainly engaging in the topic. You've also clearly not read much of the thread, or are not as familiar as you seem to think you are with modern web development. I also think the idea that you're shaking your head at us like we're the idiotas for even daring to use HTML is kinda insulting, like I didn't make an educated choice based on the available options, but that's just my personal reaction. I simply don't think you know what you're talking about, and it's annoying to be condescended to by you when that's the case. Also,
You must be registered to see the links
.I don't think you hit a nerve, and you can describe your game as whatever you want, we're talking about our games, which are just text and pictures (and scripting, of course) and don't need to be in Unity, and are a good fit for the web.
- Sep 4, 2020
- 91
- 47
Hahahahahaha!
OK, yeah, I totally get that. But I also think Outsider makes excellent points throughout the post. Anyone who denigrates HTML/JS/CSS as a gaming environment has probably not been exposed to good examples. And the low cost of entry into HTML/JS/CSS development (literally, anyone can do it for absolutely zero cost) means there are a lot of poor examples.
No, no, if you're that kind of psychopath - you write your html game in Python and use Brython to compile your code to javascript on-the-fly. Like me. You can write your custom vn engine (and toolset) in about 2 months like that.
Let's dive a bit deeper into the reasons why lots of Twine/HTML games "suck".
1. Twine is essentially designed for "choose your own adventure" style novels. That's why lots of purely text-based VNs don't need a customized UI and work fairly well.
2. Things start to get more complicated, once you add some sort of "time loop". The day/week loop is really popular in lots of VNs as it provides a sense of realism. Lots of games have some kind of hub area, "time" either simply passes after a turn or after a trigger. Lots of games have different increments for time changes, like "activity x takes 1 hour" or "activity y takes 2 hours". So far, so simple. But we'll get back to that.
3. Now there's the big question on how the player moves through the story. As soon as you disconnect story progression from passage-to-passage links (think of a basic tree structure), you need to have a suitable data structure to handle this.
4. If you want the player to be able to "navigate" through the game's world by moving through passages, the easiest way is a link tree, but these are terrible to navigate. ("Kitchen -> Hallway -> Street...") So lots of games try to circumnavigate this problem by adding a world map which is a decent solution. But...
5. Remember 2.? Lots of games use a time-slot based trigger system. ("Meet character x in room y at time z to see event.") This is is a problem as it requires the player to memorize all NPC schedules. Things get even worse if travelling between locations takes in-game time. Let's say I'm at the "home" location at 6 pm and want to meet NPC A at the gym at 7 pm. I need to travel there, which takes 30 minutes. So now I've got to waste 30 minutes to play "efficiently". In lots of games you'll reach this point. You'll end up skipping through entire days just to reach the next slot for a new event.
6. Then there's character / story progression. Most games use some kind of leveling system, i.e. each event progresses the NPC's level. New events unlock at certain level thresholds. But that's not gamey enough, so let's add character stats and link event unlocks to stat thresholds. Sounds convoluted? Maybe, but hear me out: How do I increase character stats? Correct: By repeating time-slotted events. More skipping ensues.
Alright, I think you see the problem: Sandbox mechanics do NOT work well in text-based VNs without serious tweaking. Let's break things down from a design perspective and ask some simple questions.
1. What are the goals of the game?
2. Which tools can the player use to reach those goals?
3. How does the player navigate through the virtual world?
4. Are there stats / values governing progress?
5. If yes, how is new content gated?
6. Does the game communicate how the goals can be reached?
Let's think of a non-descript VN in Twine/Sugarcube. We want some sandbox elements (i.e. "open world") with a loose time system. (days of the week / morning, lunchtime, afternoon, evening, night) We do not want time skipping to be mandatory. Here are a few ideas:
1. Disconnect the event management from locations/time slots and link it purely to triggers (= player decisions).
2. Create a system for different types of events, i.e. events that progress the story and and events that don't.
3. Let the player access characters directly. Skip navigating through the world by adding a menu with character portraits or sth similar. Communicate clearly (e.g. by color codes) if new event is available. Auto-skip time if an event is accessed - this is especially helpful if you insist on having a time slot system with different times of day. Once an event is unlocked it stays unlocked until it "happens".
Now let's tackle the grinding problem. We don't want to repeat events to unlock new content. What can we do?
1. Don't link stat thresholds to event unlocks. Instead, add depth to conversations with NPCs by adding options depending on stats. Let's say the MC is highly intelligent. Why not add some unique dialogue trees with "smart" answers? That's how lots of CRPGs (think of sth like Fallout:NV or Disco Elysium) do it and imho it works really well.
There is one problem with this solution: It takes A LOT of work to add these layers to dialogue trees which is why lots of devs shy away from doing that. But it is doable. Even for small teams. But...
2. You need a solid stat system. Don't just add stats like "strength" or "intelligence" and make them grindable. Instead, stats should increased based on player decisions as well. If you want to play as a dominant person, choosing the dominant option should slowly boost the according stat until you start to see special dialogue options pop up. Another option for stat increases is an XP/leveling system, which has to be balanced of course.
3. Of course, we don't want things to escalate completely, which is why we need a tight narrative framework. Some points in the story should be fixed. The player can reach those points in different "states", e.g. as a super-smart dude or a strong jock-type person. There has to be a well-defined limit of available branches. Routes have to be managed, both for NPCs and the main story itself. The player should feel "free", but only as much as we allow it. In the end, it's about the tricking the player.
4. Now let's talk about the new unlocks: As I've said, imho player decisions should govern unlocks. Let's say I've talked to an NPC who gave us some kind of task / a list of tasks. (Buy something, unlock something else, talk to someone etc.) As soon as all requirements are met, the next event unlocks. If needed we can add an "event delay" system, but this should be linked to the story. Arbitrarily locking content behind messages like "wait 3 days before you talk to her again" is dumb. Instead, you can create a little story element that makes the character unavailable for 3 days, e.g. a weekend trip or a medical leave.
Let's summarize:
The main issue of sandbox style HTML VNs is (imho) the convoluted way of handling story progression. Repetition and skipping should be avoided at any cost.
If you get these problems out of the way, creating a decent UI becomes easier.
1. Twine is essentially designed for "choose your own adventure" style novels. That's why lots of purely text-based VNs don't need a customized UI and work fairly well.
2. Things start to get more complicated, once you add some sort of "time loop". The day/week loop is really popular in lots of VNs as it provides a sense of realism. Lots of games have some kind of hub area, "time" either simply passes after a turn or after a trigger. Lots of games have different increments for time changes, like "activity x takes 1 hour" or "activity y takes 2 hours". So far, so simple. But we'll get back to that.
3. Now there's the big question on how the player moves through the story. As soon as you disconnect story progression from passage-to-passage links (think of a basic tree structure), you need to have a suitable data structure to handle this.
4. If you want the player to be able to "navigate" through the game's world by moving through passages, the easiest way is a link tree, but these are terrible to navigate. ("Kitchen -> Hallway -> Street...") So lots of games try to circumnavigate this problem by adding a world map which is a decent solution. But...
5. Remember 2.? Lots of games use a time-slot based trigger system. ("Meet character x in room y at time z to see event.") This is is a problem as it requires the player to memorize all NPC schedules. Things get even worse if travelling between locations takes in-game time. Let's say I'm at the "home" location at 6 pm and want to meet NPC A at the gym at 7 pm. I need to travel there, which takes 30 minutes. So now I've got to waste 30 minutes to play "efficiently". In lots of games you'll reach this point. You'll end up skipping through entire days just to reach the next slot for a new event.
6. Then there's character / story progression. Most games use some kind of leveling system, i.e. each event progresses the NPC's level. New events unlock at certain level thresholds. But that's not gamey enough, so let's add character stats and link event unlocks to stat thresholds. Sounds convoluted? Maybe, but hear me out: How do I increase character stats? Correct: By repeating time-slotted events. More skipping ensues.
Alright, I think you see the problem: Sandbox mechanics do NOT work well in text-based VNs without serious tweaking. Let's break things down from a design perspective and ask some simple questions.
1. What are the goals of the game?
2. Which tools can the player use to reach those goals?
3. How does the player navigate through the virtual world?
4. Are there stats / values governing progress?
5. If yes, how is new content gated?
6. Does the game communicate how the goals can be reached?
Let's think of a non-descript VN in Twine/Sugarcube. We want some sandbox elements (i.e. "open world") with a loose time system. (days of the week / morning, lunchtime, afternoon, evening, night) We do not want time skipping to be mandatory. Here are a few ideas:
1. Disconnect the event management from locations/time slots and link it purely to triggers (= player decisions).
2. Create a system for different types of events, i.e. events that progress the story and and events that don't.
3. Let the player access characters directly. Skip navigating through the world by adding a menu with character portraits or sth similar. Communicate clearly (e.g. by color codes) if new event is available. Auto-skip time if an event is accessed - this is especially helpful if you insist on having a time slot system with different times of day. Once an event is unlocked it stays unlocked until it "happens".
Now let's tackle the grinding problem. We don't want to repeat events to unlock new content. What can we do?
1. Don't link stat thresholds to event unlocks. Instead, add depth to conversations with NPCs by adding options depending on stats. Let's say the MC is highly intelligent. Why not add some unique dialogue trees with "smart" answers? That's how lots of CRPGs (think of sth like Fallout:NV or Disco Elysium) do it and imho it works really well.
There is one problem with this solution: It takes A LOT of work to add these layers to dialogue trees which is why lots of devs shy away from doing that. But it is doable. Even for small teams. But...
2. You need a solid stat system. Don't just add stats like "strength" or "intelligence" and make them grindable. Instead, stats should increased based on player decisions as well. If you want to play as a dominant person, choosing the dominant option should slowly boost the according stat until you start to see special dialogue options pop up. Another option for stat increases is an XP/leveling system, which has to be balanced of course.
3. Of course, we don't want things to escalate completely, which is why we need a tight narrative framework. Some points in the story should be fixed. The player can reach those points in different "states", e.g. as a super-smart dude or a strong jock-type person. There has to be a well-defined limit of available branches. Routes have to be managed, both for NPCs and the main story itself. The player should feel "free", but only as much as we allow it. In the end, it's about the tricking the player.
4. Now let's talk about the new unlocks: As I've said, imho player decisions should govern unlocks. Let's say I've talked to an NPC who gave us some kind of task / a list of tasks. (Buy something, unlock something else, talk to someone etc.) As soon as all requirements are met, the next event unlocks. If needed we can add an "event delay" system, but this should be linked to the story. Arbitrarily locking content behind messages like "wait 3 days before you talk to her again" is dumb. Instead, you can create a little story element that makes the character unavailable for 3 days, e.g. a weekend trip or a medical leave.
Let's summarize:
The main issue of sandbox style HTML VNs is (imho) the convoluted way of handling story progression. Repetition and skipping should be avoided at any cost.
If you get these problems out of the way, creating a decent UI becomes easier.
- Sep 1, 2017
- 384
- 785
And I was on BBSes and
You must be registered to see the links
, plus my first experience with using the Internet was on a
You must be registered to see the links
, where I used
You must be registered to see the links
,
You must be registered to see the links
, and
You must be registered to see the links
.So what? Being old doesn't necessarily mean you know anything about whether games in browsers can succeed or not. It's a logical fallacy to imply otherwise.
And this just means that you're giving your entirely subjective opinion.
Again, so what? Anyone can give an opinion. They're worthless when talking about how things are in general.
A discussion about things like this should be based on objective evidence, not logical fallacies and personal opinions.
Wow. There's just so much wrong packed into that.
The development environment doesn't necessarily have anything to do with the end product, since it's entirely possible for one of them to be great while the other one sucks.
User experience is mostly a product of the developer, not the programming language (though, the degree to which that's true will vary from one language to another).
Reliability is, again, mostly the product of the developer. (Though, admittedly, there are some buggy game engines out there.)
And performance, well... yeah that's dependent on the execution environment, but as long as the reaction time is under a quarter of a second, humans won't notice in most cases (not all, just most). Also, the need for that performance really depends on the kind of game. Honestly, this is the only point where you have a case in some specific instances, but most games here don't actually need a lot of performance, so this point is mostly irrelevant in this context.
Furthermore, those aren't even all of the measures by which people pick games to play. For example, numerous people like HTML games because they're safe (little or no risk of malware, especially compared to executables) and they can easily play them on their mobile devices through their browsers. Through my time being a moderator over at TFGames.Site and the r/twinegames subreddit over the last few years, I've found that there are a number of users who exclusively play HTML games for just those reasons.
As far as game developers go, the portability of HTML games is quite high and usually quite simple, and that's a huge plus. Yes, there's some tweaking which may need to be done to make sure that most browsers are supported (believe me, I know that pain), but for the most part, you make a browser game and then you've supported every OS that has a web browser. That's quite an advantage to a game developer, where they don't have to make different builds, packages, and download links for each OS like you'll find with most other game engines (supposing that those other game engines even support more than one OS, which not all do).
Finally, if you think that you have to wait a second for something to happen after you click a button in a web game, then I'd recommend that you purchase a computer from this century, because otherwise that claim is just so blatantly absurd and untrue that it only serves to further undermine your own argument.
"Allowing"?
Shake your head all you want, but it just sounds like you don't know what you're talking about.
Not everyone likes what you like or wants what want. Please stop pretending that they do, it's just self-centered and narcissistic.
Honestly, I don't even know what you mean by the "price in effort" there. Basic Twine CYOA games are extremely easy to both make and play. You can make one without even knowing how to code, you just need to know how to write a branching story and how to distribute an HTML file, and playing one is as simple as clicking links. The hurdle for that is far smaller than in almost all other engines. (And "quality" is a product of the time and effort of the developer here, so that's irrelevant as well.)
Regardless, the simple fact is that there are plenty of HTML games out there which are well done and that lots of people do like. This site currently lists over 500 HTML games. Only the Ren'Py (3620), RPGM (1836), and Unity (1716) engines boast more games here, with HTML beating out other engines like Flash (295) and Unreal (249) by a large margin. Are you honestly going to argue that none, not one, of those HTML games are popular and well-made and none will ever be popular? If not, then you admit that the issues aren't inherent to the engine, at least not entirely.
And it's not just here, Itch.io has
You must be registered to see the links
. Hell, some browser games, like
You must be registered to see the links
and
You must be registered to see the links
, are practically famous.Furthermore, it's estimated that in 2021 alone, browser games have netted about $25 billion USD (
You must be registered to see the links
), and that number is only continuing to go up (~8%) with each year. That's not chump change, buddy.The fact that you don't see the popularity or potential of HTML games just tells me how out of touch you are with how things are today. You've apparently let your age blind you to how things have changed.
Look, I'm not going to BS you and pretend that there are no drawbacks to HTML games, but, depending on the kind of game you're making, those drawbacks can be mild or nonexistent. I agree that some games are totally not practical as browser games currently (mainly those with mid- to high-3D graphic rendering requirements), but the boundaries of what kinds of games can be supported within browsers is only continuing to grow.
I'm rolling my eyes so hard right now.
Who cares about your game? We're speaking in general here.
And yeah, some people don't like lies or the people who tell them, thus lies tend to hit a nerve. Don't pretend that you've "hit a nerve" because you said something true, when all you've really done is ramble on about your personal preferences, with no actual regard for what the real world is like today.
I'd recommend you do some actual research on the subject, rather than merely blindly opining, because it seems like your distain for browser games has left you woefully uneducated regarding both what's currently possible with browser games and what the current game market looks like.
Believe it or don't, but you can't know the truth if you've got your head in the sand.
Last edited:
- Sep 4, 2020
- 91
- 47
Though the name "passages" suggests a spatio-temporal model, it's really just the div into which the game engine injects HTML that reflects the current state of the game. There is nothing that stops you from writing JS code that updates "passages" with a clickable map UI. Buttons update the state, and those state changes can cause new UI code to be injected into the passage, or can cause control to be handed back to the standard SPA code. As long as the <a> tag doesn't have a "link-internal" or "passage" class, the SPA code ignores it. So you can create links or button-like links that have your own classes that take control when clicked to update the "passages" div with whatever you want, or returns control to the SPA.
Or leave "passages" alone, and have a multi-page web application, where Twine/Sugarcube controls one page is the normal way, but you have other pages for sandbox maps and other such bits. The game framework moves you from page to page based on state and user interactions.
Or multiple divs inside the same page. Sibling divs that exist side-by-side with "passages", swapping which is visible when the game requires it. That's what the sliding sidebar is essentially.
I'm talking Twine/Sugarcube specifically. And this is all speculative, as I've not tried to specifically build something like this, but I'm pretty sure I could get it to work.
Basically I use Twine to create the network of links between story segments. The syntax makes that quick and easy. Just about everything else I cook my own solution.
But PTSdev has a point in that you gotta have a good idea of what you're aiming for. Is it a sandbox? Does the passage of time matter? Is game state a function of the history of divs you've visited (CYOA++), or a function of your character's stats (RPG++), or something that merges the two?
(I would point out that your character's stats are probably a function of the passage choices you made, at least in part, so it's likely always a mix when you think about it.)
None of those choices precludes using HTML/JS/CSS. It's a perfectly good solution for any of these gaming models, with the possible exception of a heavy 3D experience, but those aren't the sorts of games represented here by and large (there are a few exceptions like Lifeplay). I'd be happy to put up an HTML-based solution (written by a talented developer) against anything RPGM or Unity or Ren'Py can come up with.
HiEv is quite right in his assertion that the benefits of browser-based development are difficult to ignore. Portability is getting easier and easier all the time, what with auto-prefixing and polyfills and all the other techniques used to gloss over browser differences. What is even more compelling is that the convergence of browsers such that the variations in their behaviors are fading (the nightmare days of programming for IE and then programming for everyone else are long gone) is being driven by market forces, not top-down fiats. Developers and users are demanding a consistent experience regardless of the platform, and the browser community is responding. Browsers that get it right are being rewarded with market share, which is the way it's supposed to work.
Last edited:
- Oct 31, 2020
- 37
- 26
For my part I've really enjoyed games like Degrees of lewdity, The Company and Secretary but I've always found stuff lacking.
DoL adds a lot of things in their updates yet they rarely leads to anything.
The Company updates three times a decade with a half path.
The Secretary has so much stuff that it takes 20+hours of playtime to reach new content.
And so I've found myself wanting to try and "scratch my own itch", which led me to html/twine/sugarcube.
I have next to no experience in programming and even the stick figures I draw in paint weep at their own existence. My biggest strength is writing and a filthy mind.
From what I could find, html had the lowest bar of entry. That in turn makes people like me jump in balls to the wall, make a sloppy mess and call it a day.
I wish I had the mental capacity to look at a line of code and not go into stage 4 caffeine withdrawal. I envy those who can communicate with their smart-fridge using nothing but morse-code-macros but most of us peasants don't have that service pack installed.
So, what can be done to improve the html experience?
For people like me, help!
Tutorials, templates, easy to use copy paste lines, recommendations and clear tools.
Sure, there are plenty of guides on "How to Hello World" but they don't mention how you insert NTRshitpost.mp3 or how to resize NasalProlapse.png into the proper shape of a milf tentacle.
Many html games use more or less the same/similar UI because it's simple but if I could copy and paste a UI where it has a clear (insert color here), (set font size here) and (activate comic sans here) I would. A list of useful lines of code ex.: here is a standard set of value counter for strength, stamina, intellect and charisma, here is the line to change a value and here is the line to check value if you fail or succeed.
It could very well be that none of that is possible, but if it is, then a small archive/thread would help people to not get stuck on their weakness but lets them focus on their strength and so to make better games.
But these are just my 2 cups of kerosene that comes from someone who will copy paste the entirety of rule34.
DoL adds a lot of things in their updates yet they rarely leads to anything.
The Company updates three times a decade with a half path.
The Secretary has so much stuff that it takes 20+hours of playtime to reach new content.
And so I've found myself wanting to try and "scratch my own itch", which led me to html/twine/sugarcube.
I have next to no experience in programming and even the stick figures I draw in paint weep at their own existence. My biggest strength is writing and a filthy mind.
From what I could find, html had the lowest bar of entry. That in turn makes people like me jump in balls to the wall, make a sloppy mess and call it a day.
I wish I had the mental capacity to look at a line of code and not go into stage 4 caffeine withdrawal. I envy those who can communicate with their smart-fridge using nothing but morse-code-macros but most of us peasants don't have that service pack installed.
So, what can be done to improve the html experience?
For people like me, help!
Tutorials, templates, easy to use copy paste lines, recommendations and clear tools.
Sure, there are plenty of guides on "How to Hello World" but they don't mention how you insert NTRshitpost.mp3 or how to resize NasalProlapse.png into the proper shape of a milf tentacle.
Many html games use more or less the same/similar UI because it's simple but if I could copy and paste a UI where it has a clear (insert color here), (set font size here) and (activate comic sans here) I would. A list of useful lines of code ex.: here is a standard set of value counter for strength, stamina, intellect and charisma, here is the line to change a value and here is the line to check value if you fail or succeed.
It could very well be that none of that is possible, but if it is, then a small archive/thread would help people to not get stuck on their weakness but lets them focus on their strength and so to make better games.
But these are just my 2 cups of kerosene that comes from someone who will copy paste the entirety of rule34.
You might wanna check this out:
https://f95zone.to/threads/sluted-v0-7-shark-in-a-hat.97373/
It's a game of mine, using html (single page web app) but none of the sugarcube/twine stuff, in fact it's written in Python and using a little fun thing called Brython that translates the python to javascript. It's made to be more in Ren'py style when it comes to gameplay/presentation - a big background image, some NPC sprites and a bit of text at the bottom, not a wall-o-text-with-gif, click-a-link twine style.
All the code is plain to see and most of it is documented (at least with docstrings, no real manual exists yet).
It uses simple css for presentation in a everything-is-a-class approach, so if you want to change a font, size color, shape, icon, alignment, etc just use the browsers dev tools to tweak in and copy/paste it back to the style.css stylesheet.
You don't need to write a program to make a game, just lines of code (eg.
It comes with a visual editor, that may be a little janky, but works.
Currently there are no tutorials and the docs suck - but that's because so far nobody wants to make their own games with it. If there'd be people interested in developing their own games with it (as in pay-me-$10 kind of interested) I could focus on making tutorials, documentation and implement features by requests.
It's also open-source, MIT style license, so one can always steal bits and pieces if not the whole thing.
https://f95zone.to/threads/sluted-v0-7-shark-in-a-hat.97373/
It's a game of mine, using html (single page web app) but none of the sugarcube/twine stuff, in fact it's written in Python and using a little fun thing called Brython that translates the python to javascript. It's made to be more in Ren'py style when it comes to gameplay/presentation - a big background image, some NPC sprites and a bit of text at the bottom, not a wall-o-text-with-gif, click-a-link twine style.
All the code is plain to see and most of it is documented (at least with docstrings, no real manual exists yet).
It uses simple css for presentation in a everything-is-a-class approach, so if you want to change a font, size color, shape, icon, alignment, etc just use the browsers dev tools to tweak in and copy/paste it back to the style.css stylesheet.
You don't need to write a program to make a game, just lines of code (eg.
save.strength += 1 or if 'holy_grail' in inventory: save.xp+=1000)It comes with a visual editor, that may be a little janky, but works.
Currently there are no tutorials and the docs suck - but that's because so far nobody wants to make their own games with it. If there'd be people interested in developing their own games with it (as in pay-me-$10 kind of interested) I could focus on making tutorials, documentation and implement features by requests.
It's also open-source, MIT style license, so one can always steal bits and pieces if not the whole thing.