Forum:Village pump

From Blooncyclopedia, the independent Bloons knowledge base
Latest comment: Monday at 23:57 by Polavux in topic Organizing BTD6 roundsets
Jump to navigation Jump to search
Forums: Index → Village pump

Welcome to the Village pump. This page is for general discussion regarding Blooncyclopedia itself, such as formatting, policies, and guidelines.

  • For help with editing, see the help desk.
  • For issues that require the attention of staff, see the staff noticeboard.
  • Non-wiki-related topics and discussion of Bloons games are hosted on the Discord server.

To view older topics, check the archives:

To add a new topic, please write the title in the box below and click "add topic".

Looking Forward sections for Update History

At the end of update notes for every major BTD6 update, there is a looking forward section for upcoming content. Is it worth including?

Overclockbtd (talk) 00:07, 23 April 2026 (UTC)Reply

i like the idea:) 4D Hyper Glitch (talk) 00:15, 23 April 2026 (UTC)Reply
Maybe we could include transcripts of those in the "descriptions" sections, and also list in the notes if something was planned for that update but got delayed. For example, the 51.0 page would include a transcript of the "looking forward" section from its official patch notes, while the notes section would mention that a new boss (presumably Diamondback) was planned for that update according to the 49.0 update notes, but got delayed to 52.0. Polavux (talk) 00:32, 23 April 2026 (UTC)Reply
I should say on the whole that I don't think update pages should be a copy-paste of the official patch notes, they should focus on what actually changed in the update in as much detail as possible. Developer comments, jokes, and errors should be treated as supplemental, not actual parts of the update. Polavux (talk) 00:34, 23 April 2026 (UTC)Reply

How should we cover development versions? And how does this affect how we cover update histories?

So, when I started this wiki, I made the executive decision to use the term "update history" instead of "version history" because "version history" implies things that I consider unnecessary. For example, there's no reason to make pages for the launch versions of games, because it's hard to define what is an "addition" if it came in the base game. Technically everything pertaining to the game at launch is an "addition". Every sound effect, texture, item, menu, glitch, line of text, etc could be considered an addition, and I think it's an exercise in frustration to try to narrow down what is worth counting and what isn't. Even if you did narrow it down to just interactive elements (items, levels, etc), I don't see the value of having a page that just lists what was in the game at launch. Also, having "version history" sections on pages would necessitate listing the version when the subject was added to the game, which I think is unnecessary. It makes sense for the Minecraft Wiki to use the term "version history" because most of that game's entire development cycle was released publicly, so they can document everything that was added to the game bit by bit since the game's inception as Cave Game, but for most Bloons games, this just isn't the case.

However, there are now more than a few Bloons games that have development versions that made their way onto the internet. Some are publicly released beta tests (Bloons Monkey City Flash, Bloons Card Storm, and now Bloons Blitz), some are pre-release builds that weren't meant to be publicly released (development builds of the original Bloons saved by the Wayback Machine, Bloons TD 5 Mobile builds found on TestFlight CDNs, a near-final build of BCS, and version 0.5 of Bloons Blitz), and some are development builds of content updates (asset bundles from builds of Bloons TD 6 updates, closed beta tests of BCS updates on Steam, and I think there was a TestFlight build of a BTD5 update, but I'm not sure). For Bloons and BCS, we have builds close to the game's inception, kind of like Minecraft.

My idea is for development versions to cover their differences from whatever came next, while we still refrain from having a dedicated page for the launch versions of games. For example, for BCS, the build 1050 page covers the differences from 1.0, the full playable test page covers the differences from build 1050, and the firstlook test page covers the differences from the full playable test, while the pages for every version post-1.0 remain the same. This would essentially be the opposite of how we cover updates, which focus on what changed from the previous version. Theoretically, this would also apply to development builds of post-release updates; for example, there are leaked asset bundles of development builds of version 6.0 of BTD6 that have a different version of Quad and different Scientist Gwendolin voice lines, but honestly, the differences are small enough that I think you could cover those under a "development" section on the 6.0 page instead of giving it its own page. Same thing for the playtester builds of BCS updates.

I think this makes the most sense in terms of covering development versions on this wiki... in a vacuum. I have no idea how that would extend to the update history sections on pages in the mainspace. Like, would you continue to list changes in the development versions of BCS under update history? Would you move those under a "development" section instead and list them in reverse chronological order too, just for the sake of consistency...?

I'm also not sure if we should count the soft launches of Bloons Blitz and BATTD as development versions. Technically, they could be considered beta tests, and the soft launch versions of Bloons Blitz are numbered 0.x instead of 1.x, but they feel more like launch versions than development builds to me. Covering version 0.7 of Bloons Blitz falls into the same trappings as covering the launch version of BTD6, where it'd just be a list of what was in the game at release. Maybe that'll feel different once the full game is out, but for now I think we should treat Bloons Blitz's update history the same way as a fully released game. I feel the same way about the soft launch of BATTD.

Finally, where do we cover development versions? Do we create a new namespace for them, or do we add them to the update history namespace and rename that to cover development builds as well? Personally, I see namespaces as a way to denote pages that are structured differently from pages in the main namespace. Galley pages are just collections of images, strategy pages have a different writing style, and stats/event history/update history are mostly tables of data. I feel like development versions have enough of an overlap with our style of update history pages to warrant covering them in the same namespace. I can't decide what the namespaces should be called, though. If separate, I think "Development:" is too broad because there's more to game development than just builds, and I don't want to rename to "Version history" for reasons I already mentioned. Polavux (talk) 22:48, 23 May 2026 (UTC)Reply

Forgot to mention. If we do make a new namespace just for development builds, then the number of pages in it would be very small. Like, even smaller than the stats namespace right now, and that's only small because I haven't finished the stats system for the BTD5 generation. I might be forgetting a few, but the only pages that would be in this namespace are:
  • One page covering all the development builds of Bloons (since the game is so small in scope that separate pages would be excessive)
  • Three or four pages for BTD5 mobile
  • A few pages for BMC flash
  • Three pages for BCS
  • Two pages for BTD6
  • One page for Bloons Blitz
  • Possibly one page for Bloons 2 Flash
That's less than 20. If we do decide to include soft-launch builds, then that would also include:
  • One page for BTD5 flash (if we find the build somehow)
  • One page for BATTD
  • Some number of pages for Bloons Blitz, depending on how long the soft launch lasts
I don't think this namespace will have more than 30 pages. Polavux (talk) 23:08, 23 May 2026 (UTC)Reply
I feel it is not necessary to have a namespace for development versions of games and they can be on main. A "Development" version in the main article of the subject should be more than enough to cover it and if the section starts to get long, it can be moved its own article as "Development of X" or similar name and link them with the Main Hat. This because the way we would cover it should be similar to other main articles, I am thinking these sections articles could look like the Frontier Legends#Pre-release section and/or the Bloons TD (series) article in general. And while talking about each version, we can have a main hat linking to the version's notes on the update history namespace if needed.
Now on the update history discussion, changes between early versions can be covered as usual in the update history namespace, no problem with that, but I am not a fan of the idea of subjects having a "version 1.0 changes" or changes of the "beta" versions on the history section, I feel these changes should be contained only between those articles. Certainly there is a problem with the differences between the last beta to the full launch. For me a "version 1.0" article can be created in the update history namespace to detail the changes between the last development version an the release version of the game (an maybe also between sequel games and their predecessors in a more broad way as they may not be completely comparable), but these should not appear on the history sections of the main articles, but that's just me.
Well, these were my five cents. Drgoku282 (talk) 00:13, 24 May 2026 (UTC)Reply
Currently we list changes made in development versions of BCS on some pages (like Glaive Ricochet (BCS)), so if you don't like that, then how would you change it?
Personally, since we already have "development" sections for some cards that changed before they were released and in playtest builds (like Robo Monkey (BCS)), I think we could use those to cover changes in pre-release development versions too. Polavux (talk) 00:52, 24 May 2026 (UTC)Reply
As for making a version 1.0 page to cover differences from the previous development version. As I said, that seems natural to me for games like BATTD and Bloons Blitz that had a soft-launch period. But for leaked builds and beta tests, it feels weird to do that. Like, if I want to know what was different in build 1050 of BCS, I would go to the page for version 1050, not the page for version 1.0. I can't explain why it seems more intuitive for BCS but not Bloons Blitz, that's just how it is. Maybe it's because the BCS prototypes aren't really when the game launched, while the soft-launches kind of are. Polavux (talk) 01:40, 24 May 2026 (UTC)Reply
After some thought, I wonder if a "pre-release" namespace would be useful for organization. This is similar to my original idea for covering prototypes, but it would have a bigger scope, covering development, concept art, unused concepts, developer comments in "looking forward" sections, and basically any changes that occurred to the subject before it released. This doesn't just mean comparing prototypes to released versions of games and updates, this would also cover the development of specific features within games. Examples of what I'm thinking of:
  • Pre-release:Bloons TD 5 (Flash) to cover all the visual differences in its trailers and pre-release gameplay footage.
  • Pre-release:Dartling Gunner (BTD6) and Pre-release:Beast Handler (BTD6) for their original concepts and upgrades. This might be really good for organization, since the pre-release info on these articles is not very gameplay-relevant despite taking up a lot of the page.
  • Pre-release:Rogue Legends for listing all the developer comments from before release, and the unfinished version of Rogue Legends that was present in version 46.0, which had many differences.
  • Pre-release:Bloons Card Storm/Firstlook test and Pre-release:Bloons Card Storm/Full Playable test for the beta test builds of BCS, and Pre-release:Bloons Card Storm/Build 1050 for the near-final iOS build that accidentally released a few hours before the intended release date. Right now the beta test builds are on Bloons Card Storm Firstlook test and Bloons Card Storm Full Playable test.
  • Pre-release:Bloons TD 6/Version 6.0 for the leaked asset bundle of a development version of 6.0 with different SciGwen voice lines and a different Quad map layout.
Polavux (talk) 05:07, 2 June 2026 (UTC)Reply
To be clear, these are examples of pre-release topics that I think are big enough to warrant splitting into a separate namespace. Minor things, like Lifeguard Brickell's redesign, would not be split, in the same way that we don't split galleries until they become too big. Polavux (talk) 05:09, 2 June 2026 (UTC)Reply

Popping Power

Popping Power has always been an ambiguous term that has been used to refer to pierce and damage (maybe some others that I can't remember) in descriptions used throughout the bloons series. This is extremely confusing and I have no idea what should be done about this. Overclockbtd (talk) 06:38, 29 May 2026 (UTC)Reply

I plan to make a glossary page for the BTD series, like the one for BCS. I think we can include it there, defining it as a general term used in descriptive text for how effective the subject is at popping bloons, and that it can mean a multitude of things (damage, pierce, projectile count, etc) depending on the case.
Popping power is technically a mechanic in the multiplatform versions of BTD5/BTDB/BMC. Since projectiles and AOEs are separate classes of entities in those games, "popping power" is the internal name for a stat modifier that affects the pierce of both projectiles and AOEs (since projectiles have "numPersists" and AOEs have "maxTargets" instead of a shared pierce stat). But that's only internal terminology and doesn't reflect how the term actually gets used in the games' descriptive text, so I think we can disregard it or leave it as a footnote. Polavux (talk) 07:52, 29 May 2026 (UTC)Reply

Organizing BTD6 roundsets

For context, I made the call to list all of the old event-exclusive roundsets in the stats namespace instead of the main namespace, since it seemed like a better fit than the main namespace, and I think using the internal names as page names works better there than in the main namespace (since the internal names are all that we have). See Stats:Bloons TD 6/Roundsets for the list. However, that brings up the question about what to do for the other roundsets:

  • I chose to put the endurance roundset in the stats namespace because it isn't tied to a specific mode, it's shared between Boss Rush, Mini Boss, and Phayze One, and the accelerated roundset was used in a quest and an Odyssey, so I put it there too. However, that brings up the question of what to do about the default roundset on List of rounds in BTD6. I don't think moving it to the stats namespace is bad for visibility since most people access that list page through redirects anyway. My main concern is that the list page also lists things like the "freeplay modifiers" and game hints; the former isn't part of the default roundset specifically, and the latter isn't really a stat. I should also note that I plan on making a separate page about "freeplay modifiers" (probably won't be titled that, but that is the official name, see Talk:Freeplay for my thoughts on that), so the modifier tables that are on the list page can go there instead. Even if we decide not to delete the list page, those should probably be moved to the freeplay modifiers page anyway, because they aren't specific to that roundset, but I'm still not sure what to do about the round hints. We could move those to a new page for round hints across the entire series, but I feel like including them on the same page as the rounds makes more sense. I'd like to hear other people's opinions on this.
    • 'Course, if we do decide to move the default roundset to the stats namespace, that implies that we should do the same for every other BTD game's rounds in BTD4 and on. I'm not opposed to that, but maybe that feels unintuitive.
  • I'm also not sure what to do about the ABR roundset. Technically, it is used outside of ABR, since it's also the roundset of Alternate CHIMPOPPABLE, but that quest is presented as a combination of three modes, so even if it technically isn't ABR, it's still intuitive to the average reader to go to the ABR page to see what rounds are in that quest. I think fragmenting that information is unhelpful, even if for the sake of consistency. Theoretically, NK could make an event that uses the ABR roundset on a non-ABR mode, which would be enough to warrant separating the roundset to a different page in my opinion, but I don't want to make decisions based on something that might not ever happen.
  • I think the legends roundsets can go in the stats namespace too. Personally, I'm not a fan of having to list every single Rogue Legends roundset in one page (especially since you have to collapse most of the tables to make the page more navigable, which I'm not a fan of since it interferes with CTRL+F searching), and I would prefer to have separate pages for them, especially now that there's a comparison mode of the rounds module that would be useful for showing the differences in the alternate roundsets. For the Frontier Legends roundsets, I feel the same way about the base roundsets.
    • I think the FL rush roundsets and mechanics should go on its own mainspace page about Bloon Reinforcements instead. After all, the rush roundsets aren't used like normal roundsets, since the encounters pick out specific rounds to spawn instead of doing them in sequence, so giving those their own roundset pages just doesn't sit right with me. Treating them as normal roundsets would be like structuring the Sheriff (BTD6) page in the same way as Hero pages just because he technically is one. It'd also be more intuitive to describe the mechanics of reinforcements in a non-list page, since list pages aren't really supposed to be where we describe game mechanics, in my opinion.
  • Right now, all of the quest-exclusive roundsets are only listed on the quest pages. Since most of them are only used once, and people are probably going to go to the page for a quest to find out what the rounds are instead of searching the database, I think these shouldn't get their own pages. Usually these roundsets are intertwined with the structure of the quest, so fragmenting that information just for the sake of consistency feels wrong. It feels like a similar situation to the ABR roundset. Alternatively, we could create a stats page that displays all of the quest-exclusive roundsets, but I'm not sure what the benefit of that would be. Again, since they're structured specifically for the quests, it probably isn't very useful to have them all in one place for comparison. Maybe I'm wrong though, maybe there's some use case I'm not seeing.
    • Same goes for the boss roundsets. We could display all of them in one page in the stats namespace, but I don't know what purpose that would serve.

Other perspectives on this issue would be greatly appreciated. :sunglasses: Polavux (talk) 10:30, 8 June 2026 (UTC)Reply

To elaborate: I do think it would make sense to have separate pages listing game hints and "freeplay modifiers" across the entire BTD series ("List of game hints" and "List of round modifiers"?). The question is, if we have those, is there still value in having the List of rounds in BTD6 page to list rounds and game hints in the same place. Either way, the round modifiers should probably be removed because they aren't specific to the default roundset, they apply to all roundsets. Polavux (talk) 23:57, 8 June 2026 (UTC)Reply