Rob's MMORPG Notes

[robject]

This is a convenient place to put my notes and, hopefully, sponge off of the experience of others at the same time.

Marc knows how to organize the business and marketing end of things. But he's not technical. Luckily there are nerds here.

TECHNICAL- HARD
* Technical Project Manager.
* QE lead: a technical lead "without portfolio" [pending better pithy description].
* Technical leads: team players who love Traveller. Probably three.
* Test-driven design. Yes I'm going to be a hard-ass about this.
* UIs must have APIs, designed up front, used by unit tests and automated tests (e.g. it can test itself). Yes I'm going to be a hard-ass about this.
* Well-written (not necessarily long) requirements and design documents. Refers to rules to reduce reqs' lengths.
* Backend should have a RESTful API.
* Scalability based on a percentage of max(current SF online game players OR Traveller players).

TECHNICAL- EASY
* GIT repo.
* Database schema.
* Internationalized string properties.

TECHNICAL - PROBABLE
* An administrative CLI will probably exist for troubleshooting and management.
* Fiverr for cheap Java programmer labor. This is why we need very good requirements and design docs. This is also why we need good technical leads.

TECHNICAL - POSSIBLE
* Consider microservices and containerization ("resume-driven development"). Yeah yeah I know.

TECHNICAL - REALITY
* Java8 backend
* MySQL
* Using a clone of TravellerMap as the map engine.

TECHNICAL WEAK LINK
* It is likely that a front end will be in the browser. This is a weak link, since browser UI frameworks typically measure their lifespans in months. I need experts weighing in on this.

 

[Adam Dray]

What kind of MMO is this?

Full 3D like Unity or Unreal? You'll need experts in that. You'll need artists to build 3D models for everything.

2D with motion? You can do this in HTML5 but it can get tricky. You still need art.

2D with static images? You still need art and probably imagemaps.

Mostly just text? These already exist, in the form of MUDs, MUSHes, and the like. Most are C-based or have their own internal, terrible languages (I'm a MUSH expert). There's a ruby variant. They use a telnet-based client, but there are lots of clients out there already.

 

[Adam Dray]

* Well-written (not necessarily long) requirements and design documents. Refers to rules to reduce reqs' lengths.

Consider:

Instead, write detailed game play manuals.

Kills two birds with one stone. Code must match the player manual.

Put it in a wiki.

 

[Adam Dray]

How many players do you want to support? Scaling has to be designed-in from the start.

Traditional SF gameplay that I'm familiar with has a serious problem with travel time. How do you make jump time interesting? Or do you handwave it away?

If jump time is real, what's the Real:Virtual time ratio? (How many virtual days go by in one real 24-hour period?)

 

[Adam Dray]

(I ran a very successful fantasy-roleplaying MUSH with about 60-150 active players at any given time, for 18 years.)

 

[robject]

Ok, Adam wants to talk technical.

Assume Marc, Tony Howlett and I come to an agreement with Traveller AR and get it to a marketable state.

 

[Adam Dray]

Sure, I also run a Java software shop (18 people) for a living.

 

[robject]

'K. Originally I was thinking Unity with 3D models and art, scalable backend, and so on. Once I started thinking in that way, I remembered Tony.

 

[Adam Dray]

Unity is a C# environment, not Java.

 

[robject]

Yes. Your questions force me to think .

My original thoughts were mainly about how I'd approach it, but your questions made me think about how it would realistically be done.

 

[Adam Dray]

Any time you want to bounce stuff off me, hit me up here or personal email (adamdray@gmail.com).

 

[whartung]

I don't know how to manage the lethality of a Science Fiction environment.

It's easy with starships, armor them up, redundant systems, etc. etc.

But people? Not so much.

I've not played the Star Wars MMO, but it's "Science Fantasy" anyway.

In Traveller, bullets hurt. RAM Grenades Hurt. Fusion Guns HURT.

In fantasy games, you have the Party up against The Boss. The Boss tend to be a large towering creature. It's a big towering thing for several reasons. One, is simple cinematic.

But the others are practical. In a dynamic, real time fight, it's difficult for several people to crowd together and target a small shape, especially in the large encounters with lots of people.

If the plan is some kind of MMO that uses something like the First Person Shooters mechanics, then that's different. But that goes back to the lethality aspect.

In WoW, everyone stands out in the wide open, pouring out spells and what not on to the Bosses while avoiding things thrown at them, fire on the ground, summoned monsters etc.

No ducking and crawling and scurrying about in a warehouse filled with crates, or diving being lab equipment.

Of course, the other thing is that in many of the games, back to lethality, combat is THE solution, not an option. Anything that isn't a "go pick stuff up" scenario, is a "go kill XX bad buys" scenario. Life is cheap, and death isn't permanent.

So, just curious how a Traveller based game would feel.

 

[robject]

Any time you want to bounce stuff off me, hit me up here or personal email (adamdray@gmail.com).

Thanks Adam. I've created a Git repo for a Trader client, and will be posting the link shortly, when I feel like it's gotten somewhere useful.

Oh heck, I'll post it now, even though it's nascent. Really nascent. I mean like two days old.

https://github.com/bobbyjim/Trader

 

[robject]

Trader Client now has the first iteration of trade code -- I don't like it, and it's going to change, I just don't know how yet. At each destination, freight and passengers are unloaded, then loaded up again. Economics isn't working yet.

There is at least one bug -- freight and passengers must be loaded only AFTER the destination world is picked. I think I'll fix that right now.

The trade code needs refactoring. I sense a template pattern.

I think I need to specify ships via QSP.

 

[robject]

I've added primitive persistence: I write the serialized Player to disk.

Thanks be to Joshua Bell for TravellerMap's API. One less thing to worry about.

Next comes a primitive RESTful API consisting of one call.