COS [Break time is over]

=========== CHILDREN OF STEEL ==========Greetings to all!In the past years I’ve been working in the COS project.Well, I’m still working on it, and with a fresh start as well!I’ve learned a lot since I first started and the first thing I learned is that if you need help you need a working game.Second thing is if you have a vision, do it yourself, your own way!For now I wont be showing any images. Most of what is being done is python code.Children of steel is a new version of COS.The story is the following:At a certain point in time, the solar system went through a solar storm that lasted for 112 years! in 10 years the entire human race and most living beings of the planet were lead to extinction. During this time the project Salvation was finalized, it aimed to make bio-banks of most of the life forms of the planet to maybe one day repopulate it.This database was a giant space station plugged into a giant ship. The station was sent to drift in space, away from the solar system.After tens of thousands of years, the station was on orbit around an unknown planet!There is an autonomous maintenance system composed of various robot types, that in the case of no human presence should activate and produce various automatic interdependent systems: mining, refinery, repairs, building, learning and above all, find a planet to repopulate with the organics from the bio-banks.Some of the system core elements are deteriorating and the core computer decided to start populating the station before it all breaks apart, and prepare the station to return to Earth.The game will be persistent, meaning that the story will unfold affected by, but independent from players interaction.The game currency will be Joules, calculated by hours of work multiplied by a coefficient of difficulty.You’ll be able to customize your avatar, own buildings, vehicles and bots. Your avatar will gain experience, you’ll be able to buy, sell, build, mine, fight, do research, explore the galaxy, colonize planets, etc, etc.This thread is just to refresh the old thread, which for me is a reflection of 4 years of failure, it gives me lots of negative energy (I have too many obstacle around me already…).Updates coming as usually came, on Sundays._WEEK # 1: Initialization.This year, I expect to make the game progress much faster than in the past, as usual, I’ll update on a weekly manner, and if I get things sorted out between work and COS, I might just be able to pull this off.Update # 1: Week 1 ResultsI created a simple communication setup to allow the main module to start the external modules, now only 2: World generation and network.The world generator will handle the terrain calculations and send the finished work to the BGE, on demand.The networking module will handle calculi related to active network objects, and connection with the server.The main object will control the scene and send the jobs to the external parts.I had to set the logic tick rate to 1000 to have the data flow at real time. The data comes in fast and has no interference with the bge. Also I can run other calculations without starting threads.Question now: How to make the external files run on the background?WEEK # 2: Plotting GameplayWEEK # 3: Gameplay ElementsWEEK # 4: Gameplay, Sever SideWeek # 5 : Basic Game framework (Cumulus)Week # 42: Gameplay(beginnings)

Attachments


Hmm…Children of steel. Almost like Tears Of Steel only…different? :smiley:

Hmm, I just wanted to keep the COS initials, as a reference, steel refers to the robots and the bio generator humans are generated from, in the game! They become in a way children of a system…
Thanks for you comment!

Your welcome. I just made a connection to the Blender short because of the title. I’m aware it’s completely different though. I looked at the original thread too. TOS wasn’t being made in 2009 as far as I know.

The Parable/Allegory wonderful – obvious yet wonderful, Noah Reloaded.
Though chin up, what you call 4 Years of Failure also is 4 Years of Experience and Learning how not to do it.
But it will still be a Procedural Space Game like before, right?

It’s exactly the same game, only different name!
Indeed I learned a lot!
And to speed things up, I’m ready to pay for models!
So I need some interested artista to model for me , only I can only afford up to 50 bucks, the lower model being 5$. PM me if you are interested. The same goes for conceptual art! I’ll pay up to 25$ the artwork.
this way, I can focus on programming!

Wow, Torakunsama, you still here? lol



This is some concept art I’m working on; it depicts the solar storm mentioned in the plot :slight_smile:

Great, that’s a good start! But the protuberances don’t need to be hundreds of millions of kilometers long to cause significant damage to the system. Just having a few times more than the most unusual occurrences will bombard the system with a lot more radiation and also increase the temperature of nearby planets.
So let’s say the Sol star entered a phase of it’s life (“full adulthood”), so as to cause this sort of “anomaly”- just an excuse to have an apocalypse… in this case the entire system is affected! As a result the arcs are sent to another stellar system.

Right now I’m preparing the initial setup for the game:

The Ark was sent off with an “exploration” mission to a nearby star system(don’t want it to be on Pandora…). On board go 2 types of mobile platforms:
Iron hand: Main operating robots whit the ability to explore, build, mine repair, upgrade, etc. They will form a colony on the planet the arc will orbit.
Titanium head: Among them are the core decision makers for the Iron hand, one of them keeps a precious cargo on a concealed place of the Ark. Went all conditions are met, it’s set to activate it, thus give birth to humans destined to return to earth.
These robots are not set to upgrade so they stick to the initial plan. The others upgrade to adapt to various circumstances: If a problem is presented during a mission, many processors will be dedicated to solve it, once solved, the solutions are diffused as upgrade.
Eventually the condition of the Iron Hand by the time humans emerge was impossible to predict, so the secret is kept.
They are supposed to build and upgrade the ark in preparation for the re-population of the Earth.
I’m opened to design ideas for the robots:

  1. Combat bots
  2. Mining bots
  3. Repairs and construction bots
    I’ll handle the Platinum Heads!

Thank you for your interest!

Wow, Torakunsama, you still here? lol

Yeah! Can’t be helped… I need to finish this game, and get into other big projects!

So what in particular would you like me to work on? Robot design? :slight_smile:

Have you got the Ark sorted out? I would say that the design of the robots would be reflected in that somewhat (if it was built by the same people anyhow). Also what kind of size are we talking about? Will there be huge robots that do lots of stuff, or a collection of smaller robots each with a specialised task? Or will there be a swarm of identical omni-robots that can be programmed to do whatever?

precious cargo on a concealed place of the Ark

…So is the Ark a pretend exploratory ship but in reality a means of survival for the humans? I don’t get why it’s a secret, maybe I missed something :confused:

Anyway I like the way the story’s coming on.

…So is the Ark a pretend exploratory ship but in reality a means of survival for the humans? I don’t get why it’s a secret, maybe I missed something

Eventually the condition of the Iron Hand by the time humans emerge was impossible to predict, so the secret is kept.

The secret is kept because the designers suspect that the robots decide to destroy the humans or that they don’t deserve to be revived… whatever the robots will become later, the creators decide to have the PHeads as “Elders” and at least one will serve as a guardian of the human race.
The robots have to upgrade and have the best AI they could have for the very own survival of the mankind, so that they’ll keep the Ark with their lives.
The Ark is basically a big ship with a omni factory in it, and a dock for mining. On top of it there’s a Cargo deck, on wich the vertical city will be built to accommodate the first humans. I’ll design the robots, for now, check out the Esperanza Space station on the old COS thread to have an idea on how the ark looks like.
You can draw the ark orbiting a planet. This planet is reach in Gold, but is very hot and covered with acids. Atmosphere very turbulent, looks like an aggressive Venus, or Venus meets Mars planet. That will be the initial place for the game!

You can draw the ark orbiting a planet. This planet is reach in Gold, but is very hot and covered with acids. Atmosphere very turbulent, looks like an aggressive Venus, or Venus meets Mars planet.

It’s coming on really well- what colour is the planet meant to be? Venus is a sort of creamy colour (although I always thought it was blue!!)

WEEK # 1: Initialization.
This year, I expect to make the game progress much faster than in the past, as usual, I’ll update on a weekly manner, and if I get things sorted out between work and COS, I might just be able to pull this off.

This week, I’m preparing the ground to start designing the game:
So I’ll set up the structure of the many elements in the game.

The core file will have 4 main objects: Main, Active Elements, Network and World generator[/B]
The three last objects be controlled by the first( Main). So here’s their description:[/B]
1. Main:
The main object will set the different states of the other elements. As a controller, it’s function is to change and inform the game states to the other core elements. It will also hold the game data in order for the other objects to use it.

2. Active Elements:
The game AI, object functions and so on, are to be handled by this object. It will generate and manage objects like buildings, ships and other objects

3. Network
The network object will handle all the game communication with the servers, and keep the Main updated.

4. World generator:
The WG will generate the game environment.

The Idea is to use threading to prevent one module to interfere with the others. Now the BGE is not very good with threading, I still don’t know why, so I might have to resort to run external files and then connect with the BGE via socket. This way I take most of the logic from the BGE, leaving it to do the rendering and physics alone.
(…to be continued…)

Venus is a sort of creamy color (although I always thought it was blue!!)

What I meant was a bit like a redder Venus, with thick atmosphere and rapid winds. The planet is obviously very hot and has a few asteroids as moons. This is a “safe” spot, it’s a very small system with a red dwarf as star and only plenty of asteroids in orbit. I’ts hard to detect and very uninteresting system.

Looking good! Sometimes a restart is perfect for applying everything you learned into a new, clean, project. I also liked how your broke down the logic into an OOP design, I think that will go a long way towards keeping everything manageable.

Using socket to communicate with the logic sounds interesting, its something I’ve never considered. but I wonder how much logic you would actually save using that method?

Best of luck to your new project!
Ex.

Thanks Excalaberr, that means a lot, coming from you…
OOP is way much manageable, and yes, I learned to be independent code wise. I still lack experience and am still learning, but I don’t need to wait for someone to help me solve some problem…

Update # 1: Week 1 Results
I created a simple communication setup to allow the main module to start the external modules, now only 2: World generation and network.

The world generator will handle the terrain calculations and send the finished work to the BGE, on demand.

The networking module will handle calculi related to active network objects, and connection with the server.

The main object will control the scene and send the jobs to the external parts.

I had to set the logic tick rate to 1000 to have the data flow at real time. The data comes in fast and has no interference with the bge. Also I can run other calculations without starting threads.

Question now: How to make the external files run on the background?

[ATTACH=CONFIG]210469[/ATTACH]

Just some hints and observations:
It’s all about bandwidth. I would avoid sending strings at all, using integer (char) ids for one byte (255 numbers) representation. If you wish to use strings, simply send them when the object connects in a special name packet (I have yet to add this in my system).
Try and separate the game mechanics from the network. You’ll find later on that you may wish to add a specific feature that breaks the original. For example, my networking system for an FPS works roughly like so (from the base up):

  • Network Base class: This should deal with basic IO. No serialisation to be found here. In my case, I am using it as a base class to add an interface for receiving packets, and keeping a tab on data sent. Here is my base class, with some convenience methods, as well as a fake-latency extension: http://www.pasteall.org/38553/python
  • Serialisation layer: Handles conversion to and from bytes. At its simplest this incorporates slicing packets, writing strings and other variable structures to bytes and back, and unpacking packets.
  • Event Layer: The serialisation layer has to talk with the event layer in order to identify the size of the packet with that id. Thus they’re closely tied to each other. Events are basic classes which have a build and parse method (currently named send and receive unfortunately (must change that!)). They also have an active state which determines if the event can send data. Events hook into the game and receive information from scraper methods (like GameState.full_snapshot()) to parse and send. Events serialise their own data using the functionality provided by the serialisation layer
  • Game Layer: This runs the “game functions”. It actually starts with the NetworkedFPS class which inherits from network base. So it’s actually a cyclic kind of structure where the high level methods sit next to the lower level ones. Anyway, this should be an interface to pull everything together. In my case this instantiates the GameState, EventManager, and Clock (as well as other things).

The important point is this. If i decided to change my game into a Tower defence game (or rather, make a new game) only two parts would really need changing. The GameState would need a basic rewrite for a different type of game, and the Event classes would need a rewrite to suit that. It is because they are so closely tied. But, all of the methods that get your data from A to B can remain intact.

One thing I do not understand is why you are running your simulation at 1000 ticks per second. What is the reasoning behind this?

Thanks Agoose77!
My setup is similar to this. This was a simulation, and I needed to know how fast can the BGE get the data…
So in the real setup only byte representations will be changed.
The network sends and receives data, but I can use it to save some data about active objects in the server.
Then the main object does all the serialization as the unpacked data is directly usable. As I tested much earlier on local network, I could handle up to 256 clients in one scene, after that it get’s too laggy. The ideal is 128, but it’s hard to decide how many users can be in one specific point of the game. The server might be able to handle a few more hundreds of clients, but the client has a limit of objects with logic to run in a scene… anyway… there are workarounds.
The world generator will receive a position and a seed, then will return a series of values to fill up a table(map) for the current map!
I had various problems with a sole purpose system, as you mentioned, since changing one thing involved going back and change hundreds of lines of code…it’s a nightmare. So yes the splitted method seem to be a better choice.

One thing I do not understand is why you are running your simulation at 1000 ticks per second. What is the reasoning behind this?

When I first run it, I had a 5 sec delay as the BGE was reading the buffer, 60 fps was not fast enough to read the data sent by the other applications, running roughly at 1khz. besides, I only need 60fps for the rendering, the logic can and should be running faster!

I’m still interested to hear you elaborate this. Firstly, I presume that you’re reading the entire contents of the socket buffer before you continue the logic tick. You shouldn’t need to update things faster than 60 fps, because things wont change faster than 60 fps. The client cannot poll inputs faster so why should you react to them?

Well, it’s not all about networking! There is the world generation which is calculi hungry, so I need a specific area of a planet surface to be calculated, the time the ground values are returned, need to be as fast as possible.

As for the Network, I expect receive a a 4kb packet 10 times a second. So, 60 fps is largely enough!

There’s also a thingy I’m plotting, not sure will be able to.
I want to have electronic warfare and there will be the possibility to have more powerful computers than others, the power of a PC will determine how many electronic “missiles” it can send and how many it can defend. The whole thing should look like a 2 sided galaxy arcade game. The computers control the ship’s components it will determine how fast the ships react. The faster the PC the more complex software they can run. Software is a list of commands a console must do. Consoles in ships should detect all components and according to the software ti should determine what the ship is able to do with them.
Normally the computers should run at like 5fps up to 200fps. Thus I’ll need all the frames I can get…