Proof of concept

"Just do it" rule works great in really small projects but could be pain in the ass with something larger. And this is why you need new primary rule.

Make a plan, execute, repeat

And do it as long as you need and even one more time. Leviathan project evolved on paper for weeks before the first files were created. Thanks to that, I was able to focus on specific key functionalities and choose tools for this purpose.

Let's look at this paper process.

Preparation

Ok, so far we know that I want to make a game and learn some useful tools. I divided the page into 4 tables:

  1. Concept - What I want to do. Theme of the game
  2. Good to go - Other games and their mechanics that i like and fit the game theme
  3. Bare bones - Key mechanics of the game
  4. Tech - Architecture, frameworks, tools, databases etc (wich you can see on image below)

Notepad

And then sit there and fill it with every, even potentialy worst, single idea that you have. Thanks to that you will have a choice. Divide the list into must-have ideas, ones to consider, and (which will be the most of them) shit that we should not touch.

The concept

The section that you waiting for. If the project is already overwhelming at the concept stage - you're doing it wrong. So just like before, I broke it down into smaller pieces.

  • Sci-fi or Cyberpunk climat - Because I like how damn cool it is. And additionaly it gives me ability to experiment with a lot of stuff and ideas that could not be explained in another universe.
  • Trading game - I like the economic aspects of games. Besides, real-time trading would be much easier to write than combat. Especially when it's your first multiplayer game.
  • Semi-open world - It allows players to freely travel around the world but requires switching between locations. The concept of space divided into sectors of influence or something similar. Easier to implement than a huge single world.
  • Other - It would be nice to have some storyline, maybe ship micromanagement and some player and NPC interactions.

And here it is. Game outline. We know the game universe, the rules in it and the main mechanics. This is our holy guidelines. Let's go on.

Good to go

Before you start listing your ideas, think what others have. And do not confine yourself to your universe. For example on my list are games like Port Royale, Anno, The Partician right next to games like Eve Online, Elite Dangerous or even Eclipse and Twilight Imperium which are card games.

All of them have one thing in common. They have the mechanics, the interface, the design or something that might be useful in designing the elements of my game.

Bare Bones

This is the most important table. It contains functionality that will be the foundation of the game. The foundation that will decide which frameworks we will use and what we will do through the first few months of game development.

So what I need?

  1. Trading system - That's what is it all about right? But these two words imply adding more items.
    • Sectors/Systems/Stations - If you want to trade you need to deliver the goods from point A to point B.
    • Transport - If you want to deliver the goods you need some kind of vehicle and a way to move it.
    • Demand - Products must be used somehow because if not - why we need to transport them?
    • Production - There is no trade without demand and demand without supply. Someone must produce goods.
  2. Fraction/Standing system - Flying from point A to B with cargo is so boooooring.
    • Fractions - It gives you a bit more fun in planning our trade routes and production locations.
    • NPCs - Fractions without NPC? Please... It will also allow you to create missions and dangers on the trade routes. For example - pirates.
  3. Player interactions - I'm doing a damn MMO. I need players interaction.
    • Corporations - In action similar to the Guilds.
    • Some comm system - Mails ala Eve or chat
    • Goods exchange - Sometimes you want to trade directly with another player.

And that's my bare bones. List of next 3 months of my life. (I hope only 3)

Technology

That is what I wanted to write today, but the introduction became full-post in itself. So in detail we will return to this in future posts and today only briefly.

A well-rounded list of technologies will save you a lot of time when you do not have to deal with migrations in future.

So once again, split them in colums

  1. Customer device - Playable on any device - webapp!
  2. Client side - JS, portable, well documented and I already know a bit about JS.
    • Frameworks - Phaser, ThreeJS, BabylonJS, Pixi, GameCanvas, Melon, Crafty, Cosos2D, WhiteStormJS - that's my candidates.
  3. Backend side - JS once again
    • Node - I want to learn it remember?
    • Pomelo - I needed a framework as a backend game engine. Pomelo promised relatively simple and powerful. And it is created for Node. It also uses Socket.IO.
  4. Let them talk - Socket.IO, I want to learn it too.
  5. Database - Still not sure here. Maybe classic database with some in-memory database as a middleman.

Of course, I will not use all of them. This is a preliminary list from which I have chosen the most appropriate technologies in subsequent experiments.

So, do not get used to any of them. At the very beginning, when you test the technology, you will give up many and add a lot of new ones.

Such a charm of development.

But you've got a plan!

And you know it might work. The world is consistent, its foundation - mechanics makes sense. The base is easy to build but has great expansion possibilities. The plan is divided into smaller stages, ie you will not get stuck in one task for weeks. You also know the technologies that are needed for the project. This is a cool place to start!

Now, by continuing the iterations, solving problems and constantly adding functionalities we have an open road to ... creating our first files. Finally.

Conclusions

Or more matching name. Termination.
What I wanted to write today is an entry about the choice of technology but because of the length of the post we have to move this topic to the next one.

But the conclusions of this entry are quite clear. Make damn plans! This makes it much easier to plan the architecture of the application, implement the next steps and keep working smoothly.

Performing the problems smashed into small steps is in itself a work and a reward. Thanks to this, we do not lose the enthusiasm in working on a project that extends over time.

And finally, the short gif of experimenting with the market and the movement of players between stations.

Concept Phase GIF