Starwards Blog - Writing Style Analysis

Overview

The Starwards blog employs a transparent, conversational devlog style that combines technical game development insights with accessible storytelling. The writing balances hard sci-fi rigor with pragmatic LARP game design, creating an authentic behind-the-scenes narrative.

Voice & Tone

Primary Voice: Collective “We”

  • Default perspective is first-person plural (“we decided”, “we discussed”)
  • Represents the team as a unified entity
  • Creates inclusive, collaborative atmosphere
  • Occasional first-person singular when individual authors are credited (e.g., Amir’s “go to” command post)

Tone Characteristics:

  1. Honest & Self-Aware
    • Admits mistakes: “We should have moved forward at an earlier stage”
    • Acknowledges limitations: “it’s still showing signs of being a closed project”
    • Shares failures alongside successes
  2. Conversational & Approachable
    • Uses casual interjections: “Easy peasy!”, “Fork it”, “Dead simple, right?”
    • Rhetorical questions engage readers
    • Informal language: “very trickey” [sic], “fiesty jouster”
  3. Self-Deprecating Humor
    • “At this point I’ve realized that it was going to take a while… So, I made myself a cup of coffee and sat down to write about it in this blog. Yes. I procrastinate.”
    • “We also established who is the better pilot.”
  4. Reflective & Transparent
    • Shows decision-making process, not just results
    • Discusses trade-offs openly
    • Reveals doubt and uncertainty: “we weren’t sure what that next phase should be”

Structure & Organization

Typical Post Architecture:

  1. Context-Setting Opening
    • Establishes background or current situation
    • Often references previous posts or decisions
    • Example: “After laying the technical foundations, the project was stuck…”
  2. Problem/Dilemma Presentation
    • Clear articulation of challenges
    • Multiple perspectives considered
    • Uses headers to organize thoughts
  3. Analysis & Exploration
    • Methodical examination of options
    • External references (videos, articles, other games)
    • Numbered lists for criteria or considerations
  4. Resolution/Decision
    • Explicit “The Decision” sections common
    • Clear statement of chosen path
    • Justification provided
  5. Optional Action Items
    • Some posts end with concrete next steps
    • Bullet-pointed tasks
    • Example: “write problems ‘Bank’ per system”

Structural Devices:

  • Heavy use of H2/H3 headers for navigation
  • Blockquotes for definitions and external content
  • Embedded media (videos, images) integrated naturally into narrative
  • Lists (numbered and bulleted) for organization
  • Italics for emphasis, not bold (generally)

Content Patterns

1. Design Diary Format

Posts document the development journey chronologically, showing:

  • Initial state → problem identification → solution exploration → implementation → results
  • Learning moments and iterations
  • Evolution of thinking over time

2. Problem-Solution Narratives

Most posts follow this arc:

  • “What we wanted to achieve”
  • “Why it was difficult”
  • “How we approached it”
  • “What we learned”

3. Philosophical Justification

Strong emphasis on internal consistency and justification:

  • “As we strive to create a world with coherent internal reasoning, justification is a big deal for us”
  • Willing to compromise strict realism for gameplay: “we need firstly to promote features that we believe will contribute to the LARP experience”
  • Hard sci-fi aspirations balanced with practical LARP needs

4. Educational Content

Posts teach while documenting:

  • Explains concepts for non-experts (TPK, Hit Points, engagement ranges)
  • Links to external resources (Wikipedia, YouTube)
  • Contextualizes technical decisions

Language Characteristics

Sentence Structure:

  • Mix of short and long sentences
  • Short for impact: “Easy peasy!”
  • Long for complex explanation with embedded clauses
  • Compound sentences with semicolons and em-dashes

Vocabulary:

  • Technical but accessible: Uses game dev/LARP jargon but explains when necessary
  • Domain-specific terms: Structure Regions (SR), Game Master (GM), CIWS, railgun
  • Casual interjections: “pretty similar”, “pretty dull”, “Dead simple, right?”
  • Sci-fi terminology: fighters, torpedos, sensors, damage reports

Stylistic Quirks:

  1. Pop Culture References
    • “Guns. Lots of Guns” (Matrix)
    • References to The Expanse, Battletech, Thorium
    • YouTube video embeds as supporting arguments
  2. Parenthetical Asides
    • Frequent use of parentheses for definitions, clarifications, examples
    • “(loose definition: …)”, “(we call it ‘bot’)”, “(not to mention…)”
  3. Emphasis Through Formatting
    • Italics for emphasis: “huge”, “that”, “never”
    • ALL CAPS rarely used
    • Bold text minimal
  4. Technical Humor
    • “Fork it” (software pun)
    • Playful naming: “Jouster bot”, “fiesty jouster”

Narrative Techniques

1. Real-Time Development Narrative

Some posts capture the moment of development:

  • “I open the GM screen… and then the ship begins turning… and I am in developer heaven: success on first try! I love it when that happens. So rare. But wait - why is the ship not stopping?”
  • Shows bugs, frustration, problem-solving in real-time
  • Creates drama and relatability

2. Retrospective Analysis

Other posts look back reflectively:

  • “After months of work, we looked back…”
  • “After giving it a deep thought…”
  • Shows maturity and learning

3. Decision Documentation

Explicit documentation of why choices were made:

  • Lists criteria before decisions
  • Weighs pros and cons openly
  • Records rejected alternatives

4. Journey Narrative

The Epsilon Saga post exemplifies long-form storytelling:

  • Chapter-like structure with evocative headers: “First Contact”, “The Chasm”, “The Fork”
  • Arc from beginning to end
  • Emotional journey alongside technical journey

Topic Coverage

Recurring Themes:

  1. Game Design Philosophy
    • Hard sci-fi vs. fun gameplay
    • LARP-specific constraints
    • Lean startup methodology
  2. Technical Implementation
    • Physics and realism
    • System architecture
    • Bot/AI behavior
  3. Milestone-Based Development
    • Clear focus on deliverables
    • MVP thinking
    • Avoiding scope creep
  4. Community & Open Source
    • Transparency about challenges
    • Collaboration with other projects
    • Open-source ethos

Balance:

  • ~40% design/philosophical content
  • ~30% technical implementation
  • ~20% visual/demo showcases
  • ~10% meta/announcement posts

Media Integration

Video Content:

  • Embedded YouTube videos with context
  • WebM files for short demos
  • Always integrated with narrative, not standalone
  • Videos support arguments (e.g., First-Pass explanation of fighters)

Images:

  • Screenshots showing progress
  • Diagrams explaining concepts (Engagement Circles, Battletech armor)
  • Bootstrap classes for styling: .mx-auto.d-block, .float-right, .img-thumbnail
  • Captions integrated into text, not separate
  • Extensive internal linking between posts
  • External references to Wikipedia, YouTube, GitHub
  • Links to source code and issues when relevant

Audience Assumptions

The writing assumes readers are:

  1. Interested in game development process (not just results)
  2. Familiar with basic gaming/LARP concepts (but willing to explain)
  3. Technical enough to appreciate implementation details
  4. Patient with complexity (long, detailed posts)
  5. Curious about design philosophy (not just features)

Key Differentiators

What makes this blog distinct:

  1. Process Over Product
    • More about “how we got here” than “look what we built”
    • Documents failures and pivots, not just successes
  2. Design Justification Culture
    • Every decision has a “why”
    • Trade-offs explicitly discussed
    • Internal consistency highly valued
  3. Collaborative Voice
    • Team speaks as unit (mostly)
    • Acknowledges different perspectives
    • Credit given to external influences
  4. Educational Mission
    • Teaches while documenting
    • Shares knowledge with community
    • References sources for learning
  5. Authentic Struggle
    • Shows real challenges
    • Admits when stuck
    • Shares uncertainty

Writing Guidelines for Future Posts

To maintain consistency:

DO:

  • Use “we” as default voice
  • Start with context/background
  • Explain technical decisions with rationale
  • Show the journey, not just the destination
  • Include multimedia to illustrate points
  • Link to related posts and external resources
  • Use headers liberally for structure
  • Admit mistakes and learning moments
  • Ask rhetorical questions to engage readers
  • Use parentheses for clarifications
  • End with clear conclusions or next steps

DON’T:

  • Use marketing/hype language
  • Skip over failures or challenges
  • Assume readers know all terminology
  • Make posts pure announcements without context
  • Use excessive bold or ALL CAPS
  • Write in first-person singular (unless specifically attributed)
  • Present decisions without explaining the “why”
  • Make posts too short (prefer depth over brevity)

Tone Checklist:

  • Conversational but informative
  • Honest about challenges
  • Transparent about decision-making
  • Accessible to non-experts
  • Shows personality/humor
  • Respects reader intelligence

Examples of Strong Patterns

The Opening Hook:

Good: “We are happy to announce…” (simple, direct) Great: “After laying the technical foundations, the project was stuck.” (immediately engaging, shows problem) Excellent: “I open the GM screen, choose a ship, right click somewhere… and I am in developer heaven: success on first try! I love it when that happens. So rare. But wait…” (narrative tension, relatable)

The Decision Structure:

  1. Present dilemma with multiple valid paths
  2. List criteria for evaluation
  3. Analyze each option against criteria
  4. State decision clearly
  5. Justify with reference to values/goals
  6. Acknowledge trade-offs

The Technical Explanation:

  1. Start with high-level concept
  2. Explain why it matters
  3. Provide technical details
  4. Use examples or analogies
  5. Show visual if possible
  6. Connect back to game experience

Signature Phrases

Phrases that capture the Starwards voice:

  • “Easy peasy!”
  • “Fork it”
  • “And so…”
  • “After giving it a deep thought…”
  • “As we strive to…”
  • “That builds the niche aspect…”
  • “We like…” (expressing design preferences)
  • “Dead simple, right?” (before explaining complexity)
  • “So here we are…”

Evolution Notes

The style has remained consistent from 2021-2022, with these observations:

  • Early posts more announcement-focused
  • Middle posts deeply philosophical about design
  • Later posts more technically detailed about implementation
  • Consistent voice throughout despite evolution
  • “Epsilon Saga” represents peak narrative storytelling
  • Recent posts shorter, more focused (possible trend toward efficiency)

Conclusion

The Starwards blog writing style is characterized by transparent, educational development documentation delivered in a conversational, honest voice. It prioritizes process over product, justification over assertion, and learning over perfection. The style successfully bridges technical game development with accessible storytelling, creating an authentic chronicle of an indie game project’s journey.