Prospective Contributor FAQ

Common questions about contributing to the E.D.E.N. ecosystem

This FAQ is for anyone who looks at what Emergent Dynamics is building and thinks:

“I want to be involved in this somehow… but I’m not sure how, or whether I’m qualified.”

If that’s you, you’re in the right place.

This page is meant to be clear, honest, and non-intimidating — while still reflecting the seriousness and long-term ambition of the project.


1. About the Project

Q1. What exactly is Emergent Dynamics building?

Emergent Dynamics is developing the E.D.E.N. ecosystem:
a long-term, geodesic, field-driven planetary simulation engine and its surrounding products:

  • Core engine / architecture – geodesic planet substrate, field system, tick engine, subsystems.
  • Planetary Simulator – a Unity toolkit for building serious planetary simulations.
  • Education Edition – classroom-ready, scenario-driven planetary simulation.
  • E.D.E.N. SDK – a development kit for building your own systems and tools on top.
  • Colonies: Genesis of E.D.E.N. – a flagship emergent-simulation game built on the full engine.

Contributors help build the underlying architecture, tools, scenarios, docs, and surrounding ecosystem.


Q2. Is this an open-source project?

No — not in the traditional “everything is on GitHub” sense.
E.D.E.N. is a tightly architected, long-term platform with controlled access and curated contributions.

However:

  • we share a lot publicly (architecture docs, visuals, high-level design)
  • we welcome aligned contributors under NDA/IP agreements
  • some components may later be opened, licensed, or exposed via SDKs

Think private “research lab / simulation studio” more than “casual hobby repo.”


2. Who Can Contribute?

Q3. Do I need to be a professional programmer to contribute?

No.

We have room for:

  • simulation engineers (C#/Unity)
  • visualization and tools developers
  • scientists and modelers (climate, earth systems, geospatial, etc.)
  • educators and scenario designers
  • writers and documentation contributors
  • worldbuilding / narrative designers (especially for future Colonies work)
  • community / outreach helpers
  • organizational / project coordination support

If you understand systems, care about clarity, and resonate with the vision, you’re in the right neighborhood.


Q4. I’m interested, but my background is mostly educational / creative / non-technical. Is that useful?

Yes.

Some very high-value contributions don’t involve code at all:

  • designing educational scenarios and lesson-friendly modules
  • framing simulation behavior into teacher-usable materials
  • writing clear documentation and explanations
  • worldbuilding and narrative framing for future gameplay
  • outreach to schools, researchers, and communities

If you can help bridge the gap between “simulation engine” and “real people using it,” you’re valuable.


Q5. I’m early in my career / self-taught / a student. Should I even apply?

If you’re:

  • serious about learning
  • curious about systems
  • comfortable thinking deeply

…then yes.

We don’t filter by prestige. We filter by mindset, communication, and alignment.

If you treat this seriously, we’ll treat you seriously.


3. What Is the Process?

Q6. What are the steps to becoming a contributor?

Roughly:

  1. Read the public-facing docs – architecture overview, roles, expectations.
  2. Complete the Contributor Questionnaire – low-pressure, signals your interests.
  3. Short conversation – to check fit, clarify interests, and expectations.
  4. NDA + IP Assignment – to protect both you and the project.
  5. Post-NDA onboarding – internal architecture overview, norms, and starter materials.
  6. Initial task or exploration path – sized according to your background and comfort.

You are never thrown into the deep end without context.


Q7. Is there a minimum time commitment?

No hard minimum.

We’ll ask you what you realistically want:

  • “a little here and there”
  • “a few hours weekly”
  • “it depends on the tasks”

We care more about consistency and follow-through than raw hours.
If you take something on, we expect you to see it through or communicate clearly.


Q8. Can I just “lurk” and observe?

Pre-NDA: you can read public docs and watch progress.
Post-NDA: access expands and so does responsibility.

We’re not building a passive Discord community.
If you sign on as a contributor, it’s because you want to contribute — not just watch.


4. NDA / IP / Legal

Q9. Why do I need to sign an NDA?

Because we share:

  • internal architecture details
  • draft designs and experimental systems
  • unpublished tools and visuals
  • in-progress ideas

The NDA simply says:
“Anything you see inside stays inside.”

It protects the project, and it protects you — you can ask real questions and see real materials without worrying about crossing lines.

It does not claim your identity, your career, or your unrelated work.


Q10. Why is there an IP Assignment? Am I giving away my ideas forever?

No.

The IP Assignment clarifies that:

  • contributions to this project become part of the unified engine
  • the project can legally ship, expand, and build on those contributions
  • there are no ownership disputes later

You keep your skills, your general knowledge, and your unrelated work.

The IP assignment ensures the E.D.E.N. ecosystem doesn’t fracture into conflicting ownership.


Q11. Is this paid work, volunteer work, or something in between?

Right now:
Most contributor roles are pre-revenue, collaboration-based, and not structured as employment.

The ecosystem is designed with:

  • future commercialization
  • licensing
  • SDKs
  • educational partnerships
  • grant/award targets

…but the early contributor phase is about building the architecture, tools, and credibility that make those possible.

If compensation, employment, or equity ever enters the conversation, it will be explicit — never implied.


5. Technical Expectations

Q12. Do I have to know Unity?

For engineering and tools roles:
Unity experience is strongly preferred.

For education, writing, science, or conceptual roles:
Unity is a bonus, not a requirement.

You’ll get more out of the project if you’re willing to learn the basics, but it’s not mandatory for every role.


Q13. Do I have to deeply understand the geodesic math behind the engine?

No.

It’s helpful to understand what the architecture is doing:

  • equal-area tiles
  • edges and directed edges
  • fields mapped to the surface

…but you do not need to derive it from first principles.

You just need to respect that this is the canonical substrate and work within it.


Q14. Is there a strict coding style or contribution format?

Yes — but it’s not arbitrary.

We care about:

  • clarity
  • modularity
  • determinism
  • alignment with the field/tick/subsystem model

You’ll be given guidance once you’re inside.
If you’re willing to code cleanly and follow patterns, you’ll be fine.


Q15. I’m interested in ML/AI integration. Is there room for that here?

Later, yes.

The current focus is:

  • planetary substrate
  • field system
  • deterministic subsystems
  • overlays
  • tools
  • educational scaffolding

ML/AI will have a place once the core simulation is structurally solid.
If your interest is long-term AI integration into a serious simulation platform, you’re in very good company — it’s just not the first milestone.


6. AI, Tools, and Workflow

Q16. Is AI (like ChatGPT) used in development?

Yes — deliberately and carefully.

We use AI for:

  • drafting documentation
  • brainstorming architecture
  • generating scaffolding for code
  • exploring design space
  • structured review and refinement

We do not use AI as an unfiltered code firehose.
Everything is curated, filtered, and integrated into a coherent architecture.


Q17. As a contributor, can I use AI to help with my tasks?

Yes, assuming:

  • you respect the NDA (no pasting private internals into external tools)
  • you treat AI as an assistant, not a source of truth
  • you write and understand the code or content you submit
  • you follow project-specific AI safety guidelines

We care that your contributions integrate cleanly and are architecturally sound, not whether you used a text editor or a language model to help draft them.


7. Roles and Fit

Q18. How do I know which role fits me best?

Three quick filters:

  1. Do you like building systems?
    → Simulation, tools, engine, overlays.
  2. Do you like explaining or teaching?
    → Scenarios, documentation, education.
  3. Do you like narrative and creative framing?
    → Worldbuilding, Colonies, scenario storytelling.

If you’re not sure — that’s what the questionnaire and initial conversation are for.


Q19. Can I move between roles over time?

Yes — in fact, it’s likely.

Example paths:

  • simulation → tools → education
  • education → scenarios → documentation
  • visualization → overlays → core field work

As long as you respect the architecture and communicate clearly, mobility is welcome.


Q20. What if I only want to help in a very small, specific way?

That’s fine.

Examples:

  • improving a single doc page
  • providing domain feedback on a specific subsystem
  • designing one or two scenarios
  • stress-testing a specific overlay or tool

We’d rather have small, high-quality, well-aligned contributions than unfocused “I’ll do anything” participation.


8. Culture and Expectations

Q21. What is the “culture” of Emergent Dynamics like?

In a sentence:

Quietly intense, architecture-first, and long-term.

We care about:

  • precision
  • follow-through
  • high standards
  • honest communication
  • low ego, high ownership

If you want chaos, speed at all costs, or “move fast and break everything,” this isn’t the right project.


Q22. How often will I be expected to communicate?

Enough to avoid guessing games.

For most contributors:

  • brief check-ins when you pick up or finish a task
  • occasional updates if something takes longer than expected
  • questions when you’re genuinely blocked

We’re not micromanaging, but we also don’t operate in complete silence.


Q23. What happens if I disappear or life gets busy?

Real life comes first.

We ask that you:

  • let us know if you need to step away
  • don’t vanish in the middle of a critical task
  • are honest about what you can realistically take on

If expectations are aligned, there’s no drama.


9. Getting Started

Q24. What should I do first if I’m interested?

  1. Read:
  • the Architecture Overview
  • the Contributor Roles page
  • the Contributor Expectations page
  1. Fill out the Contributor Questionnaire.
  2. Wait for a response — if there’s a good fit, we’ll schedule a short conversation and move from there.

Q25. What if I’m interested, but nervous I’m “not good enough”?

If you’re:

  • reading the architecture docs carefully
  • thinking about how the systems connect
  • feeling genuinely excited by the vision

…then you’re already in the top tier of potential contributors.

The biggest filter is mindset and seriousness, not raw skill.
Skill can grow. Mindset is harder to fake.


Q26. Can I just send you my resume/portfolio instead?

You can, but:

The questionnaire is tuned to this project.
It gives us much more relevant signal than a generic résumé.

If you want to attach a portfolio, that’s great — but the questionnaire is the real entry point.


10. Final Thoughts

If you’ve made it to the end of this page and still feel drawn to the project, that’s a strong signal.

You don’t need to be perfect.
You don’t need to know everything.

You just need:

  • curiosity
  • respect for the architecture
  • willingness to learn
  • and a genuine desire to help build something that could matter for a long time.

If that sounds like you, we’d like to hear from you.