Hello, well I’m always interrest by space trip and your project sound really cool for me since your first thread, even if I must see more about player’s possibilities or histories.
I just say you good luck for reboot of COS.
Merci beacoup sbkodama
WEEK # 2: Plotting Gameplay
So ho do you play a game like COS?
There are a few elements that make it possible. COS is planned to be a complex game with various elements to control. These elements are Sim, RTS and FPS elements:
Sim:
The simulation part of COS is reminiscent of The Sims meet Simcity. There are global Sim elements and local ones.
The local elements are life support for the player. They include Hunger, fatigue, bladder . These affect attributes like health, strength, stamina, fun/fear, accuracy and XP.
XP accumulated during the day is applied to the attributes as the player goes to sleep! XP points are higher if the player is well rested. If the player is too tired the points go negative. As the player stamina increases, he can stay active for longer. There are artificial ways to keep the fatigue levels low, these are stimulants.
Fear is probably the worst enemy. The player needs to beat it in order to be able to perform certain actions. A fearful avatar will freeze or run away.
Hunger and bladder allow the health level to be high, healthy player grow faster.
Interaction: The player has 18 action slots, they correspond to the numeric keys on the key board. The slots represent the maximum amount of actions the player can perform. If the player is using an object, the slots fill up with the actions the object supports. Some objects require a level of expertise to have some actions available.
Other objects have many dependencies, allowing therefore to overcome the 18 actions limit. For instance, a ship might have various parts: engines, generators, airlocks, most of which are controlled by consoles. The consoles can simultaneously control various objects and software is used to macro certain actions, so they can be performed at a click of a button.
The player has learning attributes, the xp points go to them as the player rests. More can be said, but this is a big wall of words already.
RTS:
The RTS elements provide mission strategy and tactics.
Mission manager: The mission manager is the core of user directed action. This manager is available to team leaders , and a team with a base. The manager needs a few things to generate a mission: objectives.
Objectives are set by scouts, spies or by hired hand. They place beacons to objects or places and set some conditions to it like: Capture, destroy, reach, etc. Once the conditions are met, the objective is complete, once all objectives are complete, the mission is complete.
This manager allows players to organize games, competitions, assaults, etc.
The players can give direct orders to the team, preset targets, etc.
FPS:
The player moves in a traditional FPS way. The player can carry a weapon and a multiTool. The weapon is powered by the minigenerator the avatar can equip on it’s suit. Bigger weapons require more power, using the multiTool requires less energy since it works based on combination of magnetic, photon and nanobot techniques. This tool can be used to produce shields, analyse objects, operate consoles and so on. It works at the resemblance of the OmniTool in the Mass Effect Trilogy, and the wrist hologarphic PC in Final Fantasy, the Spirits within.
I’ll try to go more in details if there is need for that, later during the week!
WEEK # 3: Gameplay Elements
Greetings fellas!
This week I’m laying down the gameplay elements or maybe managers. These elements are the means by which the player will manage his progress, missions and training. For that reason the elements will be available in the form of menus.
Inventory
The inventory table will divided by tabs,which will make distintion between Equipement, consumables, buildings, resources, ships, planets, and programs.
Equipement are objects the avatar can use and carry along like suits, weapons, micro-generators, tools, B-Packs, etc.
Consumables ae food, drinks, medecine, but also fuel.
Buildings will take everything from a vending machine to a space station.
Ships, all of them.
Resources will be all minerals in raw and refined form, but also spare parts and Joules(COS currency).
The planets tab will take all the planets the player owns and keep a record of the visited ones.
Programs or software are sets of instructions that can be bought or creaeted to control machines the player has.
Training
The training menu allows players to develop , learn and teach tasks. The task the player can train are dependent on the base skills he has. Training does not add XP points but increase the player’s attributes. It can be activated or deactivated at anytime . Higher attributes means higher XP points and better Job (end product) quality.
There are 2 types of tasks: Sequencial ad Non-Sequencial. The first one means that the actions need to be performed in a specific sequence. The second one means that as long as he acions are performed in a specific contest, the task is valid.
Jobs are sets of tasks. The quality of the tasks will serve as base o calculate the pay rate.
Teams
A player can belong to 3 teams at most. A formal team like the employer’s, a personal like a group of friends and a informal like sports team.
As a team leader, one can rank and pay the group members according to their performance. The pay rate is automaticaly calculated. Rules and logo can also be added.
Mission manager
This element can combine all others to make the game experience unique for every user. This is used to generate missions, competitions and jobs.
The MM is available to anone forming a team.
There Jobs, and missions in the manager. A job is like a mission that is renewed at specific times (every morning) and for a period of time(year). The job is complete at the end of the working hour. The objectives are predefined with the position.
A mission is a custom job. The leader can define the objectives and the accomplishment conditions.
The entire suystem is based on the core interaction system. The avatar interaction with the world will make asks possible. A task is a set of actions(8 max) and is structured like this: [(action, reaction, sequence),…]. The action is one of the basics a player can do: Walk, crouse, use, lay, jump, climb, swim, etc. The reaction is one of the 5 options a target can have. They are the outcome of the player’s action. The sequence is the order in which the action comes within the task. The task is complete if the 3 elements are correct.
Week # 4 : Gameplay, Server side
In COS, the clients send 4 bytes to the server. This pack includes: delta Position, delta rotation, action, and target. The action is inbedded within the delta position and delta rotaion bytes. The target takes 2 bytes and includes any object in a level the player can interact with.
The action targeted towards entity will change it’s state or introduce new objects in to the level. New objects will be given and id and saved into a database.
In return, he server will send 8X 128 bytesX10/sec= 10kb/sec of data to each client (there’s a limit of 128 clients per server) comprising the client’s Deltas, the action, the target, and the state.
Objects in the level are not comunicated via network. Most of them are a the player’s position or are static. For instance changing a ship’s state to active, will copy a relative player position to the ship, in the server side. In the other clients, this actio will parent the ship to the player and sna it to a relative position, the player mesh is ended, unless both clients are in the same ship.
All objects are loaded once, and new oes are dynamically added, like bullets, new buildings and pick-ups. then saved to a database.
A level is generated when there are more than 1 player in the same place, 1MBU^3.
The BGE can only handle a few hundreds of objects per updae, therefore, there will be rules o allow more to populate a level, these are:
Group pack formation, boarding vehicle.
-
Group pack formation will place all players in a group (max 8) to assume a formation position. Then the users positions will depend on the group leader’s. This is efficient if the team has to form a barrier around a person or if the members need to multitask while moving around. Also, only the leader’s delta is processed in the client, where all the other players are either parented or connected to the leader. This can be used for NPC crowds, to populate the levels.
-
Boarding vehicles:
As the entities board a vehicle, their situation is the same as the grouping, but with the small advantage that physics and rendering not being calculated, for clients outside them, on the client’s side. On the server side, their positions are just copied from the ship’s.
I’m sure I’m missing something, but that is the basis for the gameplay mechanics, server side. There are more detail on my notes though, I’m outlining the important parts here.
Next week I’ll start building the base for te game: Server and client skeletons!
Week 5 : Basic Game framework (Cumulus)
The cumulus system is a simple network setup!
For COS, I need a Main server to control small servelets.
The Cumulus system simulates a big cloud. The Cumulus is the combined data of all clients. It controls Clouds (servelets) which group drops(levels), users or clients(droplets) can only see the droplets making the drop.
Now I need to make the server communicate with the client. After that we can start getting visual updates!
Please, stand by!
Sounds cool, its awesome that you are breaking down the game with so much detail. That will definitely help you in the long run.
The local elements are life support for the player. They include Hunger, fatigue, bladder .
I’m wondering how bladder is going to work? Does the player have to take a piss every so often? lol
Keep it up man
Ex.
Thanks Excalaberr, I hope so too!
Well, something like that. The player will use the toilet from time to time, if he’s not suited. Suits will have a certain level of comfort and special slots for liquified food, IV food, stimulators, medication, bladder pouch…
There’s more than 90% water in urine, so, it will be recycled. The player might need that water in the long run … … yaa … pee water… hmmm…
Bear Grills anyone? lol
I actually like the story of your game, quite interesting 
Thank you socker! I’m actually thinking of removing the bladder part… it may come as an hindrance later on. Also I tried to fit it into the states bytes, and I see it’s not critical, and may prevent the player from focusing in case of extreme fighting conditions. And I want to add fear instead. Fear may prevent players from acting properly in certain circumstances. Courage can be gained by special “face your fears” training. The state of the player will indicate Air,water, hunger, heat, fatigue, dress, pose, location. Each has 4 levels. For example heat at 25% and dressed to 0, for 1 game hour can kill the player from cold. If the player location is 0 (space) and Air is 0, the player dies in 2 minutes.
I also want to deaths to be as difficult as possible. Being resurrected implies that the player will lose all physical skills.
Right now I’m stalling, since I’m synchronizing, the server, with the BGE module and the Connector. So I need to edit 3 scripts at the same time! I’m getting a bit overwhelmed. Well, there’s still, and I think I’m within my own schedule. Besides, now I know where I’m heading!
Week # 10: Game play Client side
So this week, I’ll build the client side with the first visuals if possible.
I knew I’d need more than one week to get the main game framework “done”, most of the time was spent designing and deciding what elements would be and what wont.
The result?
The CUMULUS System:
The CUMULUS system as I aboarded previously uses one controller and various servelets to serve groups of players.
Each servelet is a ‘Cloud’ of users, it stores all players data. Each one uses a socket and a thread.
The other element is the ‘Drops’ or player grouped per level. The data in each group is the one to be sent to each client in the level.
This is just a way to organize the data in order to send it. I had to rewrite this system many times. And as a basic frame work it should be able to add/remove player, buildings, ships, etc.
I hope I can upload the latest version to the Server today and test it out!
The client will receive a pack of data(ab. 50 kb), split it and interpret it into visual information.
In any case, I’ll have to generate the first level, to add checkpoints and test spawning. I’ll use internal npc to randomly send data from the server. Let’s see how it goes!
Can you just adjust the “rate” of the script that launches countermeasures?
I love what you have done BTW, have you seen what I am working on ? The component cubes… the process and send and receive data, using rays and polydata, but I can’t get it working all the way,
But your “computer” could be a component cube, that can be targeted and destroyed…
I am making a very similar game I noticed after reading your story,
mine is on earth though after a “robopocalypse”
have you seen what I am working on ?
How could I ever have missed it?
Don’t you remember me giving you advice and stuff? Sighhhhht… you really can’t come and ask questions about your setup, this is a game update, not a general question or discussion about game components, try to stay on topic!
Can you just adjust the “rate” of the script that launches countermeasures?
As far as I know, I don’t have those… if by countermeasures you mean packets of data (it’s the only things the file sends and receives) then yes, I time each servelet. They only fire 4 times for delta data and once for precision position, rounding it to 5 times per second and about 200kb/s per client. I can have the server run other operations in the mid time.
I am making a very similar game I noticed after reading your story,
mine is on earth though after a “robopocalypse”
So it’s completely different! On mine, all humans are extinct for a few centuries. The machines rebuild them, and try to restore the human race. That’s why is called ‘Children of Steel’. Also most of the game doesn’t happen on Earth. It will be scattered about the galaxy as the humans expand their territory.
Sorry dude, I can’t help you with your project, I really barely have enough time for mine. On top of that, I really don’t get that cube component concept of yours…
Have I ever been on topic ?
and now for something completely different
it’s ok, I will get it eventually,
Do you need any models?
Model? I’ll need tons. But mostly textures.
They will “appear” with time. Many models will be gradually added to the game with different capabilities, as technology advances. Old models will be updated with time as well. This way the game will reach it’s final state after a while.
I’ll take a few personal models into account too, if need be, through a special chanel!
@torakunsama - Sounds good. This Cumulus system is a method to split up players into groups like servers in MMO games? Will it support players jumping from servelet to servelet?
Anyway, I’d like to try this out when I can. Keep up development!
I can rig and model, I am learning UV texturing,
what is your end shading format? Multi-texture? openGL ?
This Cumulus system is a method to split up players into groups like servers in MMO games?
Yes that’s te idea! I only have one dedicated server! In theory it can handle 32768 users with the cumulus system. Each servelet holds 256 users, there are 128 servelets.
Will it support players jumping from servelet to servelet?
No they can’t!
You see, a player’s position in the “Cloud”(servelet) is permanent as long as he’s conneced!
However, players can jump from “Drop” to “Drop” (levels dictionary). Players in the cloud are pyobjects. But in the drop, they are represented as a list of data. So the level is part of the player data and is updated as the player moves around. A level is created if more than one player are in the same level space.
A cloud as a finite number o players, the dop doesn’t. The list in the “drop” representing the player must be as smal as possible. For example, the “accurate” position data is 12 bytes, the delta data is between 6 and 8 bytes.
If the level has got 1024 users, the raw data to send to each user in h drop will be : 1024X12 + (1024X8)X4 = 45 056 bytes per second. This implies that the data sent to the clients per servelet is variable.
I can rig and model, I am learning UV texturing,
what is your end shading format? Multi-texture? openGL ?
GLSL. I considered multitextures too, for the fog color variation, but, that is not enought to skip shadows and Shaders.
I’m actually looking fo an experienced artist. If none shows up, I’ll do it myself. I’m an artist before a rogrammer! Thanks for the offer though!
I asked because you might want to move your character to another servelet. For example, if your friend is playing on servelet B and you want to play with him, then you would have to make sure that you’re also on servelet B, right? Would there be a way to disconnect and reconnect to a particular servelet?
By the way, this is very interesting. Thanks for explaining more about the networking portion of things.
is there any way to “cloud” the server onto the clients pc’s?
or @ least have them as pre-processing nodes?
So data from bob goes to bill, bill rolls in his data and passes it to server?