[Unity][Multiplayer][3D][RPG] Looking for Senior Unity Developer for Long-Term Indie Project

Hi,

Your project immediately caught my attention because you’re not just looking for someone to implement Unity features—you’re looking for someone who can help establish the multiplayer foundation correctly from the beginning. That’s exactly the kind of project I’m interested in.

I’m an experienced developer with a strong background in Unity, C#, multiplayer systems, backend architecture, and scalable game development. I’m comfortable working on client/server architecture, player synchronization, persistent progression, inventory systems, combat, matchmaking/social features, and performance optimization.

For a persistent multiplayer RPG, I wouldn’t start by trying to build the entire world or an “MMO” architecture upfront. I’d first create a focused vertical prototype: a small persistent zone, server-authoritative player movement and combat, several concurrent players, authentication, persistent characters/inventory, basic abilities, and reconnect/session handling. This gives us something measurable before scaling the architecture further.

On the networking side, I’d evaluate technologies such as Photon Fusion, Unity Netcode, Nakama, or PlayFab based on your expected concurrency, hosting strategy, development budget, and how much infrastructure we want to own. I’d also design interest management early so clients only receive relevant nearby entities rather than attempting to synchronize the entire world.

One thing I particularly like about your post is that you want someone willing to challenge technical assumptions. I’m comfortable saying when an approach could create scalability, networking, performance, or development-cost problems and proposing alternatives rather than simply agreeing and implementing it.

I’m interested in a long-term collaboration and would be happy to begin with a paid prototype/milestone arrangement. If we work well together and the project proves its technical direction, I’d also be open to discussing a deeper core-team relationship.

You can see my work here:

https://hire-mark-regato.vercel.app/

I’d be very interested in hearing more about your intended player experience, expected players per zone/world, combat model, and persistence requirements. From there, I can outline how I’d structure the first multiplayer prototype and its technical milestones.

Best,
Mark

Hi Mark,

Thanks for the detailed response. Your approach is very close to what I'm looking for, particularly the idea of starting with a focused vertical prototype rather than attempting to build the entire world immediately. I also appreciate that you're willing to challenge technical assumptions. That's important to me because I'm not looking for someone who will simply implement whatever I describe. I want someone who can tell me when an idea creates unnecessary technical, scalability, networking, or cost problems and propose a better approach.

Before we discuss the deeper game design, I'd like to understand your actual multiplayer experience a little better.

Could you share:

1. The multiplayer games or prototypes you've personally worked on.

2. Which parts you personally implemented, particularly networking, server architecture, persistence, matchmaking/session handling, and backend systems.

3. Any shipped or publicly playable projects where you were responsible for the multiplayer architecture.

4. Your experience with Photon Fusion, Unity Netcode, Nakama, PlayFab, or similar technologies.

5. An example of a difficult multiplayer/networking problem you've encountered and how you solved it.

6. Your GitHub or another portfolio where I can see relevant code or projects, if available.

I'm also interested in your thoughts on the first technical milestone. Based only on the information in my post, what would you consider the minimum vertical slice that would prove the core multiplayer architecture is viable? At this stage I'm intentionally keeping some of the game design details private until we've established technical compatibility.

If your experience matches what you're describing, I'd be happy to continue the conversation and discuss the project in more depth.

Best,
Dee

Hi Dee,

Thank you for the thoughtful reply. I appreciate the questions because they are exactly the areas that matter when building a persistent multiplayer RPG. I also like your approach of validating the technical foundation before expanding the scope.

Regarding my multiplayer experience, I’ve worked on Unity-based game projects involving real-time gameplay, networking considerations, gameplay synchronization, and performance-focused architecture. One of my recent client projects was Ballistic Armada, a multiplayer-focused mobile game built with Unity:

https://play.google.com/store/apps/details?id=com.BallisticTech.BallisticArmada&hl=en_US

For this project, I was involved in the core Unity development, gameplay systems, multiplayer-related implementation, optimization, and creating a stable experience across different devices. My focus was on building reliable gameplay systems, handling synchronization challenges, improving performance, and ensuring the architecture could support future expansion.

You can see more of my game development work here:

https://hire-mark-regato.vercel.app/#hire

My GitHub profile:

https://github.com/angryman312

Some of my recent client projects are covered under NDA, so I’m not able to publicly share source code or internal implementation details. However, I’d be happy to walk through the architecture, technical decisions, challenges, and solutions in detail during our discussion.

I can explain my role, the systems I designed and implemented, the networking approach, performance considerations, and the trade-offs made during development while respecting client confidentiality.

For multiplayer architecture, my experience includes working with concepts such as client/server communication, authoritative game logic, state synchronization, session handling, persistent player data design, and backend integration. I have experience evaluating networking solutions based on project requirements rather than forcing a specific technology.

A common challenge in multiplayer development is maintaining consistency between clients while minimizing unnecessary network traffic. For example, instead of continuously synchronizing everything, I prefer designing around server authority, relevant state updates, prediction/interpolation where needed, and only sending data that each player actually needs. This becomes especially important for larger worlds where interest management and scalability become major factors.

For the first technical milestone of your project, based only on the information you shared, I would suggest a focused vertical slice:

A small persistent multiplayer area with a dedicated server flow, player authentication/session connection, synchronized player movement, basic combat interaction, simple abilities, character persistence, and a small progression/inventory system.

The goal would not be to build MMO-scale features immediately, but to prove the important foundations:

• Can multiple players interact reliably?

• Is the server architecture stable?

• Can player state persist correctly?

• Can the system scale horizontally when more players/features are introduced?

• Are we choosing the right networking approach before investing heavily?

After validating that foundation, we could expand into larger systems like world partitioning, social features, guild/group systems, economy, and more advanced gameplay loops.

I also appreciate that you’re looking for someone who can challenge ideas technically. That is the type of collaboration I enjoy. I prefer having open discussions about trade-offs, risks, and better alternatives instead of just implementing features without considering the long-term impact.

I’d be happy to continue the conversation and learn more about your vision, expected player scale, hosting approach, and the type of multiplayer experience you want to create.

Looking forward to discussing it further.

Best,
Mark

Hi Mark,

Thanks. This gives me enough to continue the discussion.

I took a look at the information you've shared. Before we go deeper into my project's design, I'd like to understand your actual role on Ballistic Armada in more technical detail, since that's the most relevant multiplayer project you've mentioned. Could you walk me through the multiplayer architecture you worked with on that project?

Specifically:

1. What networking solution/framework was used?

2. Was the game server authoritative, client authoritative, or hybrid?

3. What responsibilities did you personally own in the networking implementation?

4. How was player state synchronized?

5. How were latency, prediction/interpolation, or reconciliation handled?

6. How were sessions/matchmaking handled?

7. What backend services were involved?

8. What was the approximate concurrent player/session scale you were working with?

9. What was one significant multiplayer or performance problem you personally solved?

10. What architectural decision would you make differently if you were building that system again today?

I'm not asking for any confidential client information or source code. I'm mainly interested in understanding your technical reasoning and exactly where your responsibility began and ended.

Best,
Dee

Hi Dee,

Thanks for this — these are the right questions, and I am happy to go deep on Ballistic Armada. I built that title, so I can be specific about the architecture, what I personally owned, and why we made the calls we did.

The short version: Ballistic Armada is a mobile naval combat sim with campaign, survival, and global leaderboards. The realtime problem was not “8 players in a room.” It was “thousands of ships, aircraft, projectiles, and nukes on a phone, still feeling like a live battle, then competing asynchronously on results.” That shaped every networking and authority decision.

Networking solution / framework
Gameplay does not run over a tick-synchronized netcode layer (no Photon Fusion / Mirror / Unity Netcode match loop). Combat, steering, ballistics, and AI all execute locally on the device.

The online path is a thin live-service layer around the session: identity where needed, persistence for progression/loadout, and score submission for Survival leaderboards. Those are request/response calls over HTTPS, not a persistent gameplay socket. TLS in transit was a hard requirement; we did not put battle state on the wire every frame.

That split was intentional. A lockstep or snapshot-replicated world would have been the wrong cost model for a title whose fun is fleet scale on mid-range Android.

Authority model
Hybrid, with a very clear boundary:

• Client-authoritative for the battle. The device is the sim. Spawn commands, oil economy, movement, targeting, ballistics, damage, and wave logic all resolve locally. There is no remote referee stepping the world.

• Service-authoritative for anything that outlives the battle. Scores, unlocks, and progression are treated as backend records. The client can propose a result; it does not get to silently rewrite the competitive ledger.

I would not call the combat sim server-authoritative, and I would not hide that. For this product, putting thousands of units behind a dedicated tick server would have added latency, hosting cost, and bandwidth without making the battle better.

What I personally owned
I owned the client simulation and the way it talks to live services:

• Unit/entity lifecycle: ships, aircraft, projectiles, nukes, and special enemies (for example mine-laying helicopters)

• Ballistics and combat resolution

• Resource loop (oil production → spend → spawn)

• Mission/campaign flow and Survival wave director

• Input (tap/swipe command layer on top of the sim)

• Frame-time and memory work so large battles stay playable

• Client integration for session start, result submit, and leaderboard readback

I did not operate a dedicated game-server cluster or a realtime matchmaker. If a decision was “how does this destroyer acquire a target this frame,” that was me. If it was “provision a room of 8 peers,” that was out of scope for the shipped architecture.

How player state was synchronized
Two different states, two different pipelines:

1. Battle state — in-memory on device. Units are simulation entities (transform, hull/armor, weapon timers, AI state, team). Projectiles are pooled, short-lived objects. There is no per-tick replication to other clients because there is no shared combat room.

2. Persistent player state — pulled at session boundaries (loadout, upgrades, campaign progress) and written back when a run commits. Survival results are a compact payload: identity, mode, score, wave/mission context, duration. The leaderboard view is a read model of those committed results, not a live mirror of everyone else’s fleets.

So “sync” here means session commit, not state replication.

Latency, prediction, interpolation, reconciliation
Network RTT is not on the combat critical path. The timing problem is simulation vs render on a thermal, thermal-throttled phone.

What we actually did:

• Fixed simulation step, variable render. Combat and ballistics step on a stable tick so projectile arcs and damage do not depend on frame rate. Rendering interpolates between sim states so motion stays smooth when a frame is late.

• Update LOD / interest. Nearby or in-combat units get full AI and targeting. Distant or off-screen units run a cheaper brain (lower tick rate, simplified steering). That is the local equivalent of interest management.

• Pooling and spawn batching. Thousands of nukes/ships/aircraft means you cannot smash the allocator every shot. Projectiles and common unit types go through pools; spawns are budgeted across frames so a wave does not hitch.

• Command buffering. Player orders (spawn, strike, move) enter a command queue and resolve on the sim tick, so input is deterministic relative to the world step.

There is no client-prediction vs server-reconciliation loop, because there is no remote authority fighting the local sim. If we were building your realtime project, that is exactly the layer I would add — predicted local motion, authoritative correction, interpolation for remote actors. I am not going to pretend Armada already had that; the transferable part is the timing discipline (fixed step, interpolation, budgeted updates).

Sessions / matchmaking
A session is a local mission or Survival run: load player profile → run the sim → commit result.

There is no realtime matchmaking into shared rooms. Competition is asynchronous: you play your battle against the AI director, then your score lands on a global board. That is the multiplayer surface players actually feel — “can I beat the people on this list” — without requiring everyone to be online in the same tick.

If I were adding realtime later, I would keep this session object (loadout, seed, ruleset, result) and wrap a matchmaker around room allocation, not around the unit sim itself.

Backend services
From the client’s point of view:

• HTTPS APIs for profile/progress and Survival score submit/fetch

• Leaderboard read model (global high scores)

• Store/live-ops around ads and IAP

• No dedicated gameplay simulation cluster

I treated the backend as a source of truth for durable data, not as a second copy of the ocean. That kept mobile data use small and let the battle scale with CPU, not with bandwidth.

Scale I was actually working with
Two different scales, and I want to be exact:

• In-session: thousands of concurrent simulated entities (ships, aircraft, projectiles, nukes) on device. That was the live performance envelope — and the changelog about spawning thousands of units plus “fixed game lagging” was that work landing.

• Online: asynchronous leaderboard traffic, not concurrent matched rooms. I will not quote a fake CCU for a room-based architecture we did not run.

A significant problem I personally solved
Late-game Survival (and big player-spawned fleets) melted frame time. Too many full-AI units, too many ballistics traces, too much spawn/destroy churn.

I split the sim into budgets: full-fidelity combat near the camera and in active engagements; reduced-rate updates for the rest; pooled projectiles; and spawn spreading so a wave could not spike a single frame. The result was that “thousands of units” stayed a feature instead of a hitch. That is the performance problem I am proudest of on this title.

What I would do differently today
For this game, I would still keep combat on-device. The fantasy is fleet scale on a phone; a dedicated server does not make that better.

What I would change:

• Put a stricter result protocol in front of leaderboards from day one (schema version, run metadata, basic sanity bounds). Async competitive boards get messy if the client is the only storyteller.

• Make the simulation more explicitly seedable (wave director + economy as data). That makes debugging, replays, and any future shared-session mode much cheaper.

• If the product needed realtime PvP, I would not grow it out of the unit sim. I would add a separate session layer: dedicated or relayed authority, a narrow replicated state (who commands what, not every projectile), and client prediction only for the local commander. For a new Unity-side project today I would start with a proven transport (Fusion or Unity Netcode) rather than inventing a socket layer.

That last point is the one most relevant to your design. Armada taught me to decide what is simulated, what is durable, and what is replicated as three different problems. Mixing them is how mobile multiplayer gets expensive and fragile.

I would love to keep going on your project with that lens: authority, tick rate, what actually has to be on the wire, and what can stay local. Whenever you want to walk through your design, I am ready.

Thanks again for asking at this level — it is the conversation I want to be in.

Best,
Mark

Hi Mark,

This is exactly the level of technical explanation I was looking for.

I especially appreciate that you clearly separated what Ballistic Armada actually does from what you would introduce for a realtime multiplayer project. That distinction is important to me.

Based on your explanation, I'd like to move to the next step.

I'll give you a more detailed overview of the multiplayer RPG I'm developing. Some of the deeper world design and lore will remain private for now, but you'll have enough information to reason about the technical architecture.

The core direction is a persistent online 3D RPG where players exist in a shared world, progress their characters over time, interact with other players, fight enemies, acquire equipment/resources, and participate in systems that persist beyond an individual session.

Character progression is a major part of the design. Players will level up through gameplay and eventually have a rebirth/progression system that allows long-term advancement beyond a single conventional character progression loop.

I don't want to design the entire backend architecture upfront. I want the first prototype to prove the fundamental multiplayer assumptions before we build the larger game.

Based on that direction, I'd like you to propose:

1. Your preferred networking stack and why.

2. Your proposed client/server architecture.

3. What should be authoritative on the server.

4. What should remain client-side.

5. How you would handle player persistence.

6. How you would structure zones/world instances.

7. How you would approach interest management.

8. How movement and combat synchronization would work.

9. How reconnect/session recovery would work.

10. What the first playable multiplayer prototype should contain.

11. What you would deliberately NOT build during the first prototype.

12. What infrastructure you would choose initially and what you would expect to change when the player population grows.

I don't need production-ready code at this stage. I'm primarily interested in your architecture and reasoning.

I also want you to challenge the concept where you see technical risks. If something I've described would create unnecessary complexity or cost, please say so directly.

Once we've discussed the architecture, we can determine whether a paid technical prototype is the appropriate next step.

Best,
Dee

Hi Mark,

This is exactly the kind of technical breakdown I was looking for. I especially appreciate that you're separating what needs to be proven now from what should deliberately wait.

I also agree that the first milestone should focus on validating the multiplayer spine rather than trying to build the RPG itself.

Before we move forward, I'd like to understand the practical scope and cost of the prototype.

Based on the architecture you've proposed, could you give me:

1. Estimated development hours

2. Proposed milestone breakdown

3. Deliverables for each milestone

4. Estimated total cost

5. Expected prototype infrastructure/service costs

6. Which parts you consider essential versus optional

7. What you'd need from me on the design/client side

8. How long you estimate the prototype would take

I'd also like to walk through one hypothetical multiplayer scenario with you so I can understand how you reason about authority, persistence, reconnects, combat and item duplication under real conditions.

No production code or full game design is needed at this stage. I'm mainly interested in validating the architecture, scope and execution plan before committing to the prototype.

Thanks,
Dee

Hi Dee,

Thank you — I am glad we are aligned on proving the multiplayer spine first. That is the fastest way to know whether this project should grow.

Below is a practical scope I would be happy to execute. It is designed so you can say yes to a contained prototype, see working multiplayer early, and keep rebirth, zones, and full RPG systems out of the spend until the spine is proven.

Essential package (what I recommend we commit to)
Multiplayer Spine Prototype — $4,800 USD fixed
96 hours · 4 development weeks (about 5 calendar weeks including review)

That is the number I want you to evaluate. Optionals are separate and not required to validate the architecture.

Hourly equivalent is $50/hour. I prefer fixed-price on this slice so the cost cannot drift while we are still proving assumptions.

Payment (so you are not paying for a black box)

• 40% ($1,920) to start Milestone 1

• 30% ($1,440) after Milestone 2, once you have walked around with predicted, server-confirmed movement

• 30% ($1,440) on final demo + handoff

You will have seen live movement before most of the fee is due.

Estimated hours and milestone breakdown

Milestone 1 — Session foundation (20 hours, week 1)
Stand up the three processes and get two clients into one zone.
Deliverables:

• Unity client + headless Fusion dedicated server, one map

• Stub auth / session token (not production login)

• Character spawn from a persistence snapshot

• Two-player join, leave, basic debug HUD (ping, player id, zone id)

• Short written architecture note (what is authoritative vs client-side)

Milestone 2 — Movement, interest, truth (24 hours, week 2)
This is the first real proof.
Deliverables:

• Client-predicted movement, server-canonical transform, reconciliation

• Speed / bounds envelope on the server

• Interest management (grid + radius); distant actors drop off the wire

• Remote-player interpolation

• Debug overlay: predicted vs server position error, interest count, tick

Milestone 3 — Authoritative combat (22 hours, week 3)
Prove hits cannot be invented on the client.
Deliverables:

• One player ability sent as intent; server validates range, cooldown, target

• One server-simulated enemy (training dummy / golem)

• Damage, death, and compact combat result events

• Client presentation only (VFX/animation follow the server result)

Milestone 4 — Loot, persistence, reconnect, no dupes (30 hours, week 4)
This is the second real proof, and the one that protects a future RPG economy.
Deliverables:

• Inventory with item instance ids (not just “give sword”)

• Server-side loot spawn and atomic pickup

• Persist character: position, XP/level stub, inventory, equipment

• Disconnect grace window (30–60s), reconnect token, no ghost duplicate

• Immediate persist on loot / death / logout

• Acceptance scenario (the walkthrough below) as a recorded test

• Handoff: how to run server + two clients, what to build next, what we deliberately did not build

Hours total: 96. I am including integration and the acceptance test inside M4 rather than adding a vague “buffer” line.

What I would treat as optional (not in the $4,800)
Only if you want them after the spine is green:

My recommendation: do not buy these yet. If M2 and M4 pass, we will know exactly which optional is worth it.

Infrastructure / service costs during the prototype
These are yours to the vendors; they are small at this scale.

• Photon Fusion Cloud: free 100 CCU tier is enough for the prototype (well above our 8–16 player cap).

• Dedicated zone process: one modest VM when we demo (Hetzner / equivalent), about $15–40/month. For M1–M3 I can run the headless server locally and on a short-lived VM for your reviews.

• Persistence: PlayFab free tier or a small Postgres on the same VM. Prototype load will not move the needle.

• No Kubernetes, no Gameye fleet, no multi-region. That is a later-population cost.

Expected prototype infra: $0–40 for the month we are building, typically under $25 if we only run the VM during test windows.
I would not put you on 24/7 always-on hosting unless you explicitly want the “world is up overnight” check — that is an ops preference, not a spine requirement.

Essential vs optional (plain list)

Essential
Dedicated server · stub session · predicted movement · AOI · one server enemy · intent/result combat · instance-id inventory · atomic loot · DB persist · reconnect + grace · anti-dupe acceptance test · debug overlay · run notes

Optional / later
Rebirth content · extra zones · PvP · chat/parties/guilds · trading · crafting · physics-as-combat · anti-cheat beyond authority · always-on world sim · production auth · art/animation beyond placeholders

What I need from you (design / client side)
Nothing about lore. A short reply on these is enough to start:

1. Engine/platform: Unity version you want, and PC/editor first (my recommendation). Mobile can wait; phones hide netcode bugs.

2. Placeholder art is OK? Capsules/blocks for player, dummy, and sword. I assume yes unless you have a small greybox map you want used.

3. Movement: walk/strafe on a navmesh or simple collider ground? Jump required in v1? (I recommend no jump unless the combat fantasy needs it.)

4. Combat feel: one melee/ability vs a dummy is enough. Tab-target vs “press to fire at nearest” — pick one for v1.

5. Player cap for the proof: I will build for 8, test with 2–4, design AOI so 16 is plausible. Tell me if you need a different number.

6. Accounts: I can create the Photon app and a PlayFab (or Postgres) project, or use yours. Either works.

7. Review rhythm: one call or recorded build at the end of each milestone. UTC+8 here; I will overlap your hours.

If you want, I can send this as a 7-line checklist and you just mark answers.

How long

• 4 weeks of build if decisions above come back within a couple of days.

• ~5 weeks calendar if reviews sit over a weekend.

• Kickoff can be the week you confirm the essential package.

Hypothetical scenario — “The sword that must exist once”
This is how I would reason under real conditions. I would also use it as the Milestone 4 acceptance test.

Setup
Alex and Blair are in the same zone. A Training Golem is server-spawned. On death it can drop one unique Iron Longsword with instance id I-8841. Alex’s wifi will die at the worst moment.

1. Enter (persistence → zone)
Both clients authenticate with a stub token. Persistence returns character snapshots (id, stats, inventory, last position). The zone server creates exactly one live actor per character id. A second login for Alex is rejected (or takes over the same actor via reconnect token) — never two bodies.

2. Combat (authority)
Alex presses attack. The client plays wind-up immediately (feel), and sends AbilityIntent { abilityId, targetId: Golem, clientTick }.
The server checks: Alex is connected, cooldown ready, golem exists, range/facing legal. It applies damage on the server tick and broadcasts CombatResult { attacker, target, damage, flags }.
Blair’s client does not trust Alex’s animation. Blair only shows the hit when the result event arrives. If Alex’s client lies (“damage 9999”), the server ignores it.

3. Death and loot (server creates the item)
Golem HP hits 0 on the server. The server rolls the loot table once, spawns a world loot actor: { instanceId: I-8841, itemDef: IronLongsword, claimedBy: null }.
That instance id is unique in the database. The sword does not exist on any client until the server says so.

4. Pickup race + disconnect (the dangerous moment)
Alex sends PickupIntent { I-8841 }. Before the round-trip completes, Alex’s connection drops.

Server rule — one atomic transaction:

• If claimedBy is null and Alex is in range: set claimedBy = Alex, despawn world loot, append I-8841 to Alex’s inventory, write persistence immediately.

• Broadcast LootRemoved(I-8841) to anyone who had it in interest, and InventoryGranted to Alex (queued if Alex is mid-drop).

Two outcomes, both valid, neither is a duplicate:

• Commit landed before disconnect. The sword is already in Alex’s inventory in memory and in the DB. World loot is gone. Blair’s pickup fails (already claimed). Alex’s body stays in the zone for the grace window (still targetable — no combat-logout exploit). Alex reconnects with the token → same actor, inventory still contains I-8841. No second sword is spawned.

• Commit did not land. The sword is still on the ground. Blair can legally pick it up. Alex reconnects with an empty grant for I-8841. That is not a dupe; it is a lost race.

What we never do: spawn loot from the client, grant by item name without an instance id, or create a new Alex on reconnect. Those three are how RPGs duplicate items.

5. Reconnect
Grace window (e.g. 45s): actor remains, HP keeps ticking if in combat, inventory is already the server copy.
After grace: despawn, persist last confirmed state, Alex is offline. Next login loads the DB snapshot — including I-8841 if it was committed — at last position.
If the zone process crashes instead of Alex’s wifi: Fusion memory is gone, Postgres/PlayFab is not. Recovery is “load last commit.” That is why loot writes are immediate and footsteps are debounced.

6. What this proves
Authority (hits and grants), persistence (the sword survives a crash), reconnect (one body), and anti-duplication (one instance id, one claim). If this scenario passes on a recording with two clients and a pulled cable, the spine is real.

How I would like to move forward
If the essential package looks right, we do not need a larger design doc. We need:

1. Your yes on the $4,800 / 4-milestone spine

2. Answers to the seven client questions above (or “defaults are fine”)

3. Kickoff date

I will then send a one-page statement of work with the same milestones, deliverables, and the sword scenario as the formal acceptance test.

I am ready to start, and I am looking forward to building this with you.

Do you use telegram ?

Best,
Mark

angryman312 wrote:

Hourly equivalent is $50/hour. I prefer fixed-price on this slice so the cost cannot drift while we are still proving assumptions.

Payment (so you are not paying for a black box)

40% ($1,920) to start Milestone 1

30% ($1,440) after Milestone 2, once you have walked around with predicted, server-confirmed movement

30% ($1,440) on final demo + handoff

Awkward! This forum is strictly for unpaid hobby work (including revshare). Compensation in real time is not in keeping with the Hobby Project Classifieds forum's spirit (and rules).

@goDeeV13 , if you are considering @angryman312 's offer, this thread will be moved to Your Announcements. If you are rejecting @angryman312 's offer, his post will be removed or edited and this thread will stay in Hobby Project Classifieds.

Hi Dee,

I am waiting your response.

Thank you.

Tom Sloper wrote:

angryman312 wrote:

Hourly equivalent is $50/hour. I prefer fixed-price on this slice so the cost cannot drift while we are still proving assumptions.

Payment (so you are not paying for a black box)

40% ($1,920) to start Milestone 1

30% ($1,440) after Milestone 2, once you have walked around with predicted, server-confirmed movement

30% ($1,440) on final demo + handoff

Show less

Awkward! This forum is strictly for unpaid hobby work (including revshare). Compensation in real time is not in ...

Thanks Tom. Yes, I am considering @angryman312's offer and we are currently discussing the scope and terms of the proposed technical prototype. Please move the thread to Your Announcements.

angryman312 wrote:

Hi Dee,

I am waiting your response.

Thank you.

Hi Mark, thanks for putting this together. I appreciate the level of detail in the proposal, especially the milestone structure and the acceptance scenario around persistence, reconnect, and preventing item duplication.

I’m considering moving forward with the $4,800 fixed-price prototype, but before confirming the engagement or making the first payment, I’d like to review the one-page SOW and make sure we’re aligned on the scope, deliverables, acceptance criteria, IP/source-code ownership, repository access, third-party services, and final handoff.

For the seven questions:

1. Unity: I’m fine with using the current mutually agreed Unity LTS version. PC/editor first is fine.

2. Art: Placeholder assets are completely fine for this prototype.

3. Movement: Keep it simple with collider-based ground movement. No jump for the initial prototype unless you identify a technical reason it is needed.

4. Combat: One simple melee ability against a training dummy/enemy is sufficient.

5. Player capacity: Build/test around 8 concurrent players, with the architecture allowing us to evaluate whether 16 is technically plausible.

6. Accounts: I prefer the project and infrastructure accounts to ultimately remain under my ownership. We can determine the exact setup in the SOW.

7. Reviews: Milestone-based reviews with a recorded demo/build and access to the source at each milestone works for me.

Telegram is also fine for day-to-day communication. For the formal project scope, milestones, technical decisions, deliverables, ownership, and payment-related matters, I’d like us to keep the official record in the SOW/email so we both have a clear reference.

Please send me the one-page SOW first, and I’ll review it before we proceed.

Hi Dee,

Thank you — I am glad the proposal was useful, and I appreciate how clearly you locked the seven questions. That is enough to write a clean SOW.

I have attached SOW v1.0 for the USD 4,800 fixed-price Multiplayer Spine Prototype. Please treat that document as the official record for scope, milestones, deliverables, acceptance, IP, repository access, third-party accounts, payment, and handoff. Telegram remains fine for day-to-day; anything that changes the SOW should stay on email.

A few points I want to highlight so we stay aligned:

Your answers are written into the SOW. Unity LTS (version locked at kickoff), PC/Editor first, placeholders only, collider ground movement with no jump, one melee ability vs a training dummy, build/test around 8 CCU with architecture we can use to evaluate 16 (not a 16-player guarantee), milestone recordings plus source at each milestone.

Accounts and ownership stay with you. Photon, persistence (PlayFab or Postgres — we choose at kickoff), optional demo VM, and the Git repo are Client-owned. I can help you set them up. Keys and billing do not live on my side. Source is assigned to you as each milestone is paid; I will not publish or reuse your design without written consent.

Acceptance is concrete. Milestone 4 still uses the sword scenario: one instance id, atomic pickup, reconnect to the same actor, no duplicate item if a client drops mid-loot. You review each milestone by email within five business days.

Payment does not start until you accept this SOW. After you confirm, the 40% kickoff (USD 1,920) begins Milestone 1. Then 30% after M2, 30% on M4 handoff.

Please read the attached SOW and tell me if you want any clause adjusted — especially IP, repo access, third-party setup, or the 16-player language. I would rather tighten a sentence now than discover a mismatch after kickoff.

Once you email that SOW v1.0 is accepted (or send a marked-up version), I will reply with a short kickoff note: Unity LTS version, persistence choice, Git invite, and payment method. Then we can start.

Thanks again for the careful review. I am ready when you are.

Best,
Mark
ctiptopper@gmail.com
Telegram: @angryman312

Statement of Work

Project: Persistent 3D RPG — Multiplayer Spine Prototype
SOW version: 1.0 · Date: 22 September 2026
Parties: Client — Dee · Contractor — Mark Jayson Guibao Regato (ctiptopper@gmail.com · Telegram @angryman312)

This SOW is the official record for scope, milestones, technical decisions, deliverables, ownership, and payment. Telegram is for day-to-day coordination only. Changes to this SOW are valid only if confirmed in email by both parties.

1. Objective

Build a technical prototype that proves the multiplayer spine: server-authoritative movement and combat, character persistence, reconnect/session recovery, and item-grant safety (no duplication). This is not a playable RPG vertical slice. Lore, rebirth content, extra zones, social systems, and production backend are out of scope.

Success: two PC clients can move in one shared zone, defeat a training dummy with a server-resolved melee hit, loot a unique item, disconnect, reconnect, and still have exactly one copy of that item.

2. Locked design answers

3. Scope

In scope (essential spine)
Unity client · headless Photon Fusion 2 dedicated server · one greybox zone · stub session token · client-predicted / server-canonical movement with speed/bounds checks · interest management (grid + radius) · remote interpolation · one server-simulated dummy · intent → server result melee · inventory with item instance IDs · atomic loot pickup · persist character (id, position, XP/level stub, inventory, rebirthCount field unused) · reconnect token + 30–60s grace window · debug overlay (ping, tick, predicted vs server error, interest count) · run notes and short architecture note.

Out of scope (deliberately not built)
Rebirth/content loop · jump · PvP · second zone / travel · parties, guilds, chat, trading, crafting · physics-as-combat · production auth, payments, moderation · anti-cheat beyond server authority · always-on living-world sim · mobile · final art/animation · Kubernetes / multi-region / autoscaling.

Capacity note: 8 concurrent players is the working target. “16 plausible” means the replication and AOI design should not be inherently 8-only; it is not an acceptance requirement that 16 players stay at production frame-time or bandwidth.

4. Stack and third-party services

Contractor may help create or configure these under Client login, or via temporary invite. API keys, app IDs, and billing stay with Client. Secrets are not committed to git. Client pays vendor fees directly (prototype estimate: USD 0–40 for the build month; Photon 100 CCU free tier is expected to be sufficient).

5. Milestones, hours, and deliverables

Fixed price: USD 4,800 · 96 hours · 4 development weeks (~5 calendar weeks including reviews). Hourly equivalent: USD 50.

Each milestone: playable build or Editor repro steps, recorded demo, source pushed to Client repo, and a short email summary of what changed and what is next.

6. Acceptance criteria

A milestone is accepted when the listed deliverables work on PC/Editor with two clients + dedicated server, and no in-scope defect blocks the next milestone.

M4 formal acceptance — “The sword that must exist once”

1. Two clients join the same zone as distinct characters (one actor per character id).

2. Player A’s melee is ignored if the client lies about damage; only server results apply.

3. Dummy death spawns one world loot actor with a unique instance id (e.g. I-8841).

4. Pickup is atomic: claimedBy is set once; a second pickup of the same instance fails.

5. If A disconnects during/after pickup: no second sword is created; B cannot receive a duplicate of I-8841.

6. Within the grace window, A reconnects to the same actor; inventory matches server (and DB if the grant committed).

7. After grace, A’s next login loads the last committed snapshot — including I-8841 iff the grant was committed.

8. Forced process restart of the zone server does not invent items; recovery is last persistence commit.

Client will confirm each milestone by email within 5 business days of the demo. Silence after 5 business days counts as accepted so the schedule can continue; Client may still log in-scope defects during the warranty window.

7. Repository, access, and handoff

• Client creates and owns the repository. Contractor receives write access for the engagement.

• History is pushed at every milestone (and regularly in between).

• On final payment: full source, server build steps, how to run two clients, env/template for secrets, architecture note, and a “what we did not build” list.

• After handoff, Client may revoke Contractor access. Contractor will delete local copies of secrets; Client source may be retained only if Client asks for a warranty patch.

Warranty: 7 days after M4 acceptance, Contractor will fix in-scope defects that break the acceptance criteria, at no extra fee. New features are a change order.

8. IP and ownership

Upon receipt of the corresponding milestone payment, Client owns all work product created under this SOW: source, assets produced for the prototype, design notes, and recordings made for reviews.

• Contractor assigns to Client all right, title, and interest in that work product (work-made-for-hire to the extent allowed; otherwise exclusive assignment).

• Pre-existing Contractor tools/snippets used as generic utilities remain Contractor’s; Client receives a perpetual, paid-up license to use them inside this project.

• Third-party engines/SDKs (Unity, Photon, PlayFab, etc.) remain their owners’ IP; Client must have valid licenses.

• Client lore and unpublished design remain Client’s confidential information. Contractor will not disclose them.

• Contractor will not publish, portfolio, or reuse Client’s game design, names, or recordings without prior written consent.

9. Payment

Currency: USD. Method: agreed in kickoff email (bank / PayPal / Upwork as Client prefers). Work on a milestone starts after the associated start/prior payment has cleared, except M1 which starts after the 40% kickoff payment.

Change orders: New features or out-of-scope items are quoted in email (hours × USD 50, or a small fixed add-on) and started only after Client written approval.

Cancellation: Client may cancel by email. Paid milestones stay Client-owned. In-progress milestone is billed for reasonable hours worked, capped at that milestone’s share, against a brief status dump in the repo.

10. Communication, schedule, and assumptions

• Official record: this SOW + email. Day-to-day: Telegram.

• Reviews at each milestone; Contractor timezone UTC+8, with overlap arranged for demos.

• Client provides: repo + third-party account invites (or live setup session), milestone feedback within 5 business days, and confirmation of Unity LTS version at kickoff.

• Placeholder art and a single greybox map are sufficient. Jump is omitted unless both parties email-agree it is required for a technical reason.

• Prototype is a validation build, not production-secure, not shipped quality, not an always-on MMO.

11. Start

Engagement starts when (a) both parties email-accept this SOW v1.0 and (b) the 40% kickoff payment has been received. Kickoff email will lock Unity LTS version, persistence choice (PlayFab vs Postgres), Git host, and payment method.

Accepted by

Optional add-ons (not included): PvP +12h / USD 600 · second zone +16h / USD 800 · proximity chat +6h / USD 300 · playable rebirth loop +10h / USD 500. Quoted only if requested after the spine is accepted.