code/yieldomega

Watch

Fork 0

Investigate native story generation and social objects for TimeCurve launches #32

New issue

Closed

opened 2026-04-13 11:52:21 +00:00 by PlasticDigits · 3 comments

PlasticDigits commented

2026-04-13 11:52:21 +00:00

(Migrated from gitlab.com)

Problem

TimeCurve may have strong internal mechanics, but if those mechanics do not naturally surface into visible stories, social objects, and recurring narrative hooks, the launch can feel too quiet from the outside. We need to investigate how the product itself can continuously emit memorable events, recognizable leaders, rivalry arcs, streaks, milestones, and status objects that make participation and observation socially legible.

This is not mainly a marketing problem. It is a product-mechanics visibility problem: the launch should continuously generate things worth noticing, following, and talking about—without defaulting to generic shilling or external hype loops.

Non-goals: We are not asking to copy pump.fun or to lean on low-quality "meme casino" tactics. The investigation should focus on how YieldOmega's own mechanics can produce recurring narrative objects and visible game-state in a native, durable way.

Research questions

1. What types of events inside TimeCurve naturally create stories?

Examples to evaluate (not exhaustive): streak defense, streak break, "comeback" buy, last-second reset, rivalry between wallets, leader changes, podium lock-ins, surprise upsets, treasury milestones, launch progression phases, clutch entries near key time thresholds (e.g. timer-hard-reset band, very low remaining time).

Examples: titles, badges, named moments, animated event cards, battle logs, podium snapshots, weekly recaps, "current king under pressure," "biggest defender," "streak breaker," "last buy hunted," "time savior," etc.

3. How can these be surfaced in the app so users and spectators instantly understand what is happening?

Examples: live event feed, battle board, highlighted moments, rivalry modules, wallet achievement strips, launch timeline, phase transitions, endgame alert states, recap views.

4. Which outputs are best for internal visibility versus external shareability?

Internal: in-app feed, launch page state, leaderboard callouts, timeline markers.
External: screenshot-worthy cards, share images, compact social summaries, auto-generated recap objects, social post templates.

5. Which mechanics already exist or are planned that can support this without adding low-signal complexity?

Review TimeCurve and Podium / WarBow-style ideas already discussed in-repo. Identify where narrative energy already exists in onchain rules and events but is not yet surfaced well in the indexer or frontend. Treat docs/product/primitives.md as authoritative for v1: three reserve podium categories (last buy, time booster, defended streak) and WarBow / Battle Points as separate PvP/status—not a fourth podium prize.

6. What should be avoided?

Avoid shallow fake-engagement systems, pure spam loops, meaningless notifications, and mechanics that are easy for "sharks" to farm without making the game more fun for real participants.

What to inspect

Existing TimeCurve gameplay loops (buys, timer extension vs hard reset, charm/redemption).
Podium prize concepts (three categories above).
WarBow concepts where relevant: Battle Points, ladder snapshot, steal / guard / revenge / flag flows—docs/product/primitives.md.
Battle board / PvP visibility: what state transitions and player actions are already exposed in the frontend vs reconstructable from events.
Whether any existing onchain events or derived facts can be promoted into named, trackable narrative beats (spectator-readable, shareable).

Framing dimensions

Think in terms of: spectator readability, player identity, rivalry formation, status visibility, shareable moments, repeat attention, durable participation (not one-off clicks).

Expected deliverables

A short design investigation (issue comment thread or linked doc) summarizing findings.
A categorized list of native story-producing mechanic patterns tied to real rules/events.
A list of possible UI components that surface those patterns.
A clear split: "MVP can do now" vs "future deeper systems".
Concrete recommendations for 3–5 features or experiments to prototype.

Strong mechanics are not enough if they remain socially invisible. Investigate how YieldOmega can make TimeCurve launches continuously emit recognizable stories, statuses, conflicts, and artifacts that users can follow inside the app and share outside it.

## Problem TimeCurve may have strong internal mechanics, but if those mechanics do not naturally surface into visible stories, social objects, and recurring narrative hooks, the launch can feel too quiet from the outside. We need to investigate how the product itself can continuously emit memorable events, recognizable leaders, rivalry arcs, streaks, milestones, and status objects that make participation and observation socially legible. This is **not** mainly a marketing problem. It is a **product-mechanics visibility** problem: the launch should continuously generate things worth noticing, following, and talking about—without defaulting to generic shilling or external hype loops. **Non-goals:** We are not asking to copy pump.fun or to lean on low-quality "meme casino" tactics. The investigation should focus on how **YieldOmega's own mechanics** can produce recurring narrative objects and visible game-state in a native, durable way. ## Research questions ### 1. What types of events inside TimeCurve naturally create stories? Examples to evaluate (not exhaustive): streak defense, streak break, "comeback" buy, last-second reset, rivalry between wallets, leader changes, podium lock-ins, surprise upsets, treasury milestones, launch progression phases, clutch entries near key time thresholds (e.g. timer-hard-reset band, very low remaining time). ### 2. Which of those can become durable "social objects" rather than just backend state? Examples: titles, badges, named moments, animated event cards, battle logs, podium snapshots, weekly recaps, "current king under pressure," "biggest defender," "streak breaker," "last buy hunted," "time savior," etc. ### 3. How can these be surfaced in the app so users and spectators instantly understand what is happening? Examples: live event feed, battle board, highlighted moments, rivalry modules, wallet achievement strips, launch timeline, phase transitions, endgame alert states, recap views. ### 4. Which outputs are best for internal visibility versus external shareability? - **Internal:** in-app feed, launch page state, leaderboard callouts, timeline markers. - **External:** screenshot-worthy cards, share images, compact social summaries, auto-generated recap objects, social post templates. ### 5. Which mechanics already exist or are planned that can support this without adding low-signal complexity? Review **TimeCurve** and **Podium / WarBow**-style ideas already discussed in-repo. Identify where narrative energy already exists in onchain rules and events but is **not yet surfaced well** in the indexer or frontend. Treat [`docs/product/primitives.md`](docs/product/primitives.md) as authoritative for v1: **three reserve podium categories** (last buy, time booster, defended streak) and **WarBow / Battle Points** as separate PvP/status—not a fourth podium prize. ### 6. What should be avoided? Avoid shallow fake-engagement systems, pure spam loops, meaningless notifications, and mechanics that are easy for "sharks" to farm without making the game more fun for real participants. ## What to inspect - Existing **TimeCurve** gameplay loops (buys, timer extension vs hard reset, charm/redemption). - **Podium** prize concepts (three categories above). - **WarBow** concepts where relevant: Battle Points, ladder snapshot, steal / guard / revenge / flag flows—[`docs/product/primitives.md`](docs/product/primitives.md). - **Battle board / PvP** visibility: what state transitions and player actions are already exposed in the frontend vs reconstructable from events. - Whether any existing onchain events or derived facts can be promoted into **named, trackable narrative beats** (spectator-readable, shareable). ## Framing dimensions Think in terms of: **spectator readability**, **player identity**, **rivalry formation**, **status visibility**, **shareable moments**, **repeat attention**, **durable participation** (not one-off clicks). ## Expected deliverables - A short **design investigation** (issue comment thread or linked doc) summarizing findings. - A **categorized list** of native story-producing mechanic patterns tied to real rules/events. - A **list of possible UI components** that surface those patterns. - A clear split: **"MVP can do now"** vs **"future deeper systems"**. - **Concrete recommendations** for **3–5 features or experiments** to prototype. --- Strong mechanics are not enough if they remain socially invisible. Investigate how YieldOmega can make TimeCurve launches continuously emit recognizable stories, statuses, conflicts, and artifacts that users can follow inside the app and share outside it.

PlasticDigits commented

2026-04-13 11:52:24 +00:00

(Migrated from gitlab.com)

First-pass thoughts (seed for discussion)

Top 5 candidate story generators already latent in the mechanics

Under-threshold timer game + hard reset — The <15m defended-streak window and timerHardReset branch create natural "clutch / ambush / comeback clock" stories; many UX-relevant facts already live in Buy and related state.
Defended streak vs streak break — Active streaks, breaks, and ambush-style overlaps are rivalry-native (who held the window, who broke whom).
WarBow PvP loop — Steal / guard / revenge / flag silence-and-claim are explicit social conflicts with visible winners and losers, not abstract scores.
Last-buy podium race — Endgame where "final movers" matter produces legible spectator drama if surfaced as a timeline, not only a static table.
Time booster leaderboard — Cumulative "who actually moved the deadline" is a distinct skill narrative from BP or last-buy hype.

Top 3 UI surfaces likely to make the system feel alive quickly

A live event / battle feed (human-readable beats from canonical onchain events—buys, WarBow actions, flag milestones—not generic alerts).
A unified "launch story" strip: timer phase + podium/WarBow snapshots + "moment" callouts (leader change, streak break, flag claimable, endgame).
Per-wallet story on the launch page: recent beats, rival edges, streak/booster/last-buy relevance—so identity and rivalry are visible without leaving the page.

High signal vs likely noise

Higher signal: Surfacing existing differentiated mechanics (timer bands, streak break, ambush/clutch bonuses, flag timing, steal/revenge) as named, inspectable moments; recap objects tied to real state transitions.
Likely noise: Notification sprawl, generic "engagement" copy, share cards disconnected from verifiable game facts, or features that mainly reward volume farming over meaningful play.

Happy to refine once the main investigation doc exists.

### First-pass thoughts (seed for discussion) **Top 5 candidate story generators already latent in the mechanics** 1. **Under-threshold timer game + hard reset** — The `<15m` defended-streak window and `timerHardReset` branch create natural "clutch / ambush / comeback clock" stories; many UX-relevant facts already live in `Buy` and related state. 2. **Defended streak vs streak break** — Active streaks, breaks, and ambush-style overlaps are rivalry-native (who held the window, who broke whom). 3. **WarBow PvP loop** — Steal / guard / revenge / flag silence-and-claim are explicit social conflicts with visible winners and losers, not abstract scores. 4. **Last-buy podium race** — Endgame where "final movers" matter produces legible spectator drama if surfaced as a timeline, not only a static table. 5. **Time booster leaderboard** — Cumulative "who actually moved the deadline" is a distinct skill narrative from BP or last-buy hype. **Top 3 UI surfaces likely to make the system feel alive quickly** 1. A **live event / battle feed** (human-readable beats from canonical onchain events—buys, WarBow actions, flag milestones—not generic alerts). 2. A **unified "launch story" strip**: timer phase + podium/WarBow snapshots + "moment" callouts (leader change, streak break, flag claimable, endgame). 3. **Per-wallet story** on the launch page: recent beats, rival edges, streak/booster/last-buy relevance—so identity and rivalry are visible without leaving the page. **High signal vs likely noise** - **Higher signal:** Surfacing **existing** differentiated mechanics (timer bands, streak break, ambush/clutch bonuses, flag timing, steal/revenge) as named, inspectable moments; recap objects tied to **real** state transitions. - **Likely noise:** Notification sprawl, generic "engagement" copy, share cards disconnected from verifiable game facts, or features that mainly reward volume farming over meaningful play. Happy to refine once the main investigation doc exists.

PlasticDigits commented

2026-04-30 04:52:34 +00:00

(Migrated from gitlab.com)

mentioned in commit 787e586718

mentioned in commit 787e58671816675a20df35673ef9bb63e3423209

PlasticDigits commented

2026-04-30 04:53:00 +00:00

(Migrated from gitlab.com)

mentioned in issue #93

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-05-12 07:41:19 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

code/yieldomega#32

No description provided.

Rows
Columns