Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

Bug Bomb v0.03.1 (Patreon)

Published:
2017-10-07 13:40:32
Imported:
2026-06
Tags:

Downloads

Content

So I fixed the bugs reported so far, and also made some progress on the issues with time problem. Before the earlier release, I fixed the issue with negative time, but something was still wrong. I found out what it was...

In Twine, apparently calling a function that contains a for loop inside of a for loop, causes Twine to forget about the first for loop.

 I just don't even... really? 

Files

Comments

Cevrik

As someone also using Twine, I feel your pain.

mug (edited)

Comment edits

2026-09-06 11:00 Why is Twine being used, by the way? Creating a new framework with the features Twine provides would probably take some time and be a bit of a pain to make, but at least you'd have full freedom/control over it.
2017-10-08 17:11

ThaumX

There are a fewreasons, but basically I think the pros outweigh the cons. A big factor is that im basing the primary mechanics on time rather than location, but as a text-based game there isn't really a ready-made engine for this, so a lot of things will need to be built regardless. Second is that the writing is a lot more natural in twee format, and therefore easier for implementing user submissions as well. Another is that with css and js, all the main components for text display are relatively easy to work with. Cross compatibility is a plus, as is the flexibility of using media. Actionscript could work, but has its own quirks and takes a lot of extra work to build up a decent text display. C# would be more powerful and straightforward, but similarly would take a lot of work that isn't needed in Twine. Java... Is special. Sure, it's got cross compatibility on it's side, but plenty of headaches elsewhere.

ThaumX

And sorry monokuma, I misread your comment a bit. I was debating using a different approach, and it really came down to either Javascript, Actionscript, or Visual Basic for me. Using a prebuilt engine like Unity went out the window, because that would add another layer of complexity. All have advantages for different types of games. I went with Javascript for a few reasons, namely the ease of doing a lot of things related to text games, and having a solid repository of source code floating around the internet. The need to keep the game "closed source" wasn't high up in my priorities. Once I decided on js, the question became more about function and usability, for example, twine sugarcube already has a built-in parser, save functionality, and other things that are handy. But twine is also completely open source, and that means I can change it and expand it to meet my needs. So while AW is currently based on Twine Sugarcube 2.19, it's my modified version of sugarcube 2.19, with my own expanded functions. For the most part, working in twine has significantly sped up development, except when I run into a hiccup like above. I will likely be doing some other portions of the game directly in js, which will avoid those issues, and probably should have kept the time functions strictly js as well, except for some notion of trying to keep things easier to follow for contribution down the road.

R
>>7638939

Great, thanks for clarifying. If the goal is to optimize possibility for community created content further down the line this makes sense.