Thursday, December 25, 2014

Happy Holidays Part 2

The video below demonstrates sending entities over the network into a game.  500 entities are shown some are overlapping.  The reason the bulk of the entities took a little bit to pop up is because the way the entities were being updated.  Easy fix to the update interval.  Check out the video below.

video

Wednesday, December 17, 2014

Happy Holidays!

It has been a little while since the last update and I thought it would be good to show something visual for a change.
A total of 16641 entities.

Saturday, November 29, 2014

Code Snippet: CPU Usage

Freebie today that is all about CPU (Central Processing Unit) usage. If you are here from BYOND and are familiar with the Server "tick_lag" variable which does the same thing as the CPU class. This snippet is untested on Android devices.

Imports

The CPU class. The OS object is something you will have to code yourself. Simple example to get current CPU usage.

Extending

A feature interested programmers could add is CPU monitoring on a background thread that has a 2 second tick. When the background thread detects the CPU past a certain threshold, like 75.0 then a event is fired alerting any listeners "Hey the CPU is about to explode!". Then you can trigger any optimizations that will lower the CPU usage.

Friday, November 14, 2014

Speak a Different Language?

Not a problem!  Implemented a translation API for anyone who can not read English.

Any dialogue used by NPCs will be translated to make your experience better.

User Interfaces will also be translated.

It can even detect your system's language and use that.  By default it will, just in case, there will be an in-game option to change it.  Will probably have the default language displayed a long with a list of supported languages by their names at start-up for you to select.

Here is a list of supported languages.  Some have letters that won't display they are marked with a *
SPANISH
FRENCH
GERMAN
ALBANIAN
*AZERBAIJANI
CATALAN
CROATIAN
CZECH
DANISH
DUTCH
ESTONIAN
FINNISH
HUNGARIAN
ITALIAN
*LATVIAN
LITHUANIAN
NORWEGIAN
POLISH
PORTUGUESE
*ROMANIAN
SLOVAK
SLOVENIAN
SWEDISH
TURKISH
* These have some letters that aren't displaying

UPDATE: Just wanted to include that I got it worked into the Conversation system.  Snippet below uses French translated from this line "Nice to meet you, my name is Billy Bob Jimmy Joe.  How are you?".
The system is not perfect and some words are not translated but it is small words like using a German translation, for some reason, the word "name" is not translated.  Small bug, not priority.  Translating is not without it's price.  The performance hit in translating text ends up being a few seconds.  Ouch!  So this will have to be masked somehow when the game demo rolls out.

Wednesday, November 12, 2014

Entity/Component System Explanation

What is a Entity and what are Components?  If you don't know what I mean when I blog about that system this post will be very informative to you.

An Entity is a game object that contains a unique id that sets it apart from other entities.  This helps the system identify an entity from other entities.  Entities contain components that are strictly data.  Entities can have as many components as necessary.  Components can be anything, health, stamina, position, velocity are a few examples.  If you wanted an Entity to be able to move you would add the Position and Velocity components to that Entity.  But adding Components is half the work.

Those Components need to have some sort of logic that controls the behavior otherwise they just take up space.  The behavior of those components is determined by a EntityProcessor.  EntityProcessors get the Component from the Entity and perform logic on it.  EntityProcessors only know of their own logic and not that of any other processor. Lets say we had a MovementProcessor to process moving Entities.  The MovementProcessor would grab the Position and Velocity components and perform movement translations on them.  The end result would be that those Entities could move within the game world.  Lets say that you wanted all Entities to come to a halt.  Simply remove or disable the MovementProcessor and then nobody could move.  That simple logic switch would affect all networked entities.  Which brings me to networking.

How does the Entity/Component system interface with networking?  I mentioned before about how Entities contain a unique id to help identify them.  It also helps identify them over the network.  Say I have two players that logged in.  I want them both to get this awesome entity I just made so I send it to them.  They both have that Entity with that id.  Now I have the server perform operations on that Entity and sends that entity id with the updates.  Those players already have that entity id and know which entity the network wants to update so it is a simple matter from there to just locate and update them.  This not only makes the networking approach easier it makes it cleaner as well.  This also applies to databases.  By using the Entity's id as a index, entities can be stored in the database and located very fast.

There are some cons to using this approach.  The more Entities you have with many Components the more memory they are going to take up.  To address this, certain performance optimizations and the use of Object Pooling can alleviate those concerns.  By having a way to store Entities somewhere besides memory you can also remove the memory problem at the expense of performance.  You either sacrifice some performance for memory or vice versa.  That is to be expected in any approach.

That is all I got thanks for reading.

Saturday, November 8, 2014

Got a Graphics Designer

Happily announcing that we have a GD! This means that we can start designing the perspective and programming the actual game itself (significant work has been done on the barebone framework). Don't expect a release date any time soon. This is going to be a remake of SS13 in a different perspective utilizing a more modern programming language. We will be using OpenGL which means we will have access to the GPU and will be able to have actual shaders for different effects.  This also ensures that we will have a graphics backend that is cross platform compatible.  Windows, Mac, Linux is planned with a Android version later down the road.  Have to get the main PC operating systems done first.

A few things to note:
  • Will be pay-to-play based on server cost.
  • Accounts!
  • Most game modes will take place on a big space station
  • Atmospherics will be more realistic, if you open a hole in the station and aren't wearing magnetic boots you will be sucked out at a high velocity, unless you are on a station with working emergency force fields.  That station feature will have to be researched/manufactured and interconnected with the station subsytems, good luck.. 8)
  • Science! Genetics! Engineering!  Eventually Robotics and whatever else we can invent.
  • Monkeys! Ferrets!(jk)  Xenomorphs was SS13's baby.  We will be having a more different form of alien that SS13 players won't be familiar with and will have to adapt to, or die..
  • A lot more that will be done that I won't spoil
The main goal will be to get some graphics out there and stress test my networking code.  It has been the biggest challenge for myself to date.  Very proud with what I have accomplished.  To summarize, an Entity/Component system that is fully network capable and efficient.  The Entity/Component system makes the game objects more dynamic and reusable.  Did I mention I have implemented Entity "templates" that allow me to save a Entity's state to a file and load it whenever?  More on that in a later post.

This remake/improved version will have an eventual release date but want to put emphasis that it won't be for a while.

That networking issue I had in the last post is solved.  Won't be going into detail on that, it would be to lengthy and take away from time from actual work.

I will be posting updates/progress as the months go by.

Link: http://ss14.boards.net/

Wednesday, October 29, 2014

Efficient Networking - Throttling

I have successfully created what I am calling a Bandwidth Limiter. With this class I am able to limit the amount of bytes sent per second. This will allow me to control the amount of network resources the server has to gobble up which will equal less server costs.  It is currently set to 1KBp/s.  There is a caveat.  The packets that are not sent, because of the limiter, must be either discarded or put into a queue to send again.  But how do you figure out what packets need to be resent?  The way I think I am going to control it is certain packets that are important will be labeled "reliable" which means they will be sent regardless.  I can even make it so the bandwidth limiter ignores those packets.  Problem solved.  Unfortunately the code for the limiter will not be released on this blog.

I am also still trying to solve a good way of only sending Entity components that have actually changed rather then just sending the whole Entity in bulk.  By limiting entity updates to only the components that have changed it will save a significant portion of the bandwidth.  I'm afraid that the solution I have come up with may be the best one.  But I will be researching alternatives.  For now, I am using a boolean state to indicate if a component was modified but I have to update that state manually whenever a value in that component changes.  Having the state get updated manually can lead to many different places in the code where the state is modified which will not be very fun when I have to track down why a component is always getting a state update even if the values inside the component haven't changed.  With careful coding this may not even be an issue.  But if I can find a better way, I will!

Thanks for reading.

Monday, October 27, 2014

Efficient Entity Processing

One of the bottlenecks in my framework has been the Entity processing.  I wanted the ability to limit the amount of entities processed per loop.  This allows me to control the amount of CPU usage on the server side efficiently.  I am going to share my madness code with all of you.  When you have a server that has 1million+ entities to process the LAST thing you want is lag caused by the server's processing loop.  The best way to prevent that nightmare is to create a limited loop.  The small snippet of code is below for review.

The log to see what is happening. The "Entities left alive" part is because there is a processor that is subtracting health -20 from each of the 50,000 entities.

Sunday, October 26, 2014

Showcasing User Account Network Output

Not much to explain here. Just look at it and smile. I did. And the HONK script..

Sunday, October 19, 2014

Sidetracked - NPC Conversations

One of the main things a game has to have is interactive NPCs.  They give the player that immersion with the world and it's inhabitants.

The way I handle NPC conversations is basically they are a tree structure where if you choose an option that choice may lead to another conversation entirely different from the original, I use Dialogues to simulate that.  The way I am handling it is a Conversation object is the root.  Conversations have "Dialogues" that contain text.  The Dialogue object also contains Choice objects that lead to other Dialogues.  Choices are key.  Having a conversation where your choices don't matter ruins immersion, your choice could cause that NPC to attempt to kill you or give you an item.  Those branching Dialogues have choices or one choice "End" to end the Conversation object.

So, how do Choices select a different Dialogue?  Every Dialogue has a "label" that makes it unique.  The label could be "npc.reaction.negative".  The label can be anything, even a random bit of characters which is what I used for testing.  Conversations can be exported to XML and saved to a file/loaded easily.  Below is the example conversation I test with.

Diagnosing the above XML you can see the Conversation is the ROOT and has Dialogues contained within.  The first Choice redirects to the Dialogue with the label "VKfxCsuVmL" and will begin that Dialogue when chosen.  The choices that do not have a "nextDialogue" end the conversation.  Conversations can even be programmed through Javascript.  The XML was actually generated by a script.
I still consider this framework as Alpha and the above mentioned information will likely change.  I have not implemented linking to actual Entities so that the NPC names are associated with the conversation to distinguish a conversation that has multiple NPCs participating.

Thank you for reading.

Thursday, October 16, 2014

3 Years Later... An Introduction

Intro

When I first started playing Space Station 13 3 years ago it was such an amazing experience.  I died within the first 5 minutes from some random dude killing people.  The more I played the more ways I died, or griefed others.  A marvel of survival horror (only a survival horror lets you play a murdering clown).  And that atmospherics!  Wow!  It wasn't until a few months playing that I decided to put my knowledge of java programming to the test and try to create a game framework project to eventually make a SS13-like game.  I worked on/off the framework but it is really shining now.  I have accomplished a lot with the framework.  Blood, sweat, and tears.

Cool things in the Framework

  • CPU monitoring
  • Scheduler
  • Events (Scripts can hook into it too!)
  • NameGenerator (real names!)
  • Text-To-Speech (works but need different voice)
  • Object Serialization (Binary, JSON, YAML, XML)
  • Memory Monitoring with Callback on low memory detection
  • Database
  • Reflection (ability to create Java classes using ClassBuilder)
  • Logging (different logging implementations JDK, MinLog currently supported)
  • Assets management (was a pain in the d)
  • Game Settings (able to save and load settings or use autoDetect method)
  • Input framework (this one was a pain in the d to get working with JMonkeyEngine)
  • Archive (ZIP,AR,TAR,JAR)
  • Object Poolin
  • Game Stages support (sorta like Screens but not)
  • Game Dialogue (with XML save/load)
  • Entity framework (templating supported/really useful)
  • Pluggable Scripting framework (lua, jython, javascript are all done) Javascript is what I will be using
  • Networking (client/server)
  • Some minor things I don't need to mention

TODO

When it comes to updating entities over the network only the components that have changed should be sent to save bandwidth.  This will limit network traffic significantly!  The hard part is figuring out how to do this effectively.  I have a few ideas but I will save it for another blog post, this one is getting to big.

My Version of SS13-like Game

The way I would like to play the game is in First Person.  In a sense like how the Legend of Grimrock 2 but 8 movements of direction instead of 4 but the perspective will be limited to 75.  This will create a limited awareness where you can't see behind you.  You will start off with a clunker of a ship that would shatter if you ran into a asteroid.  From there you can mine or pirate your way across a limited galaxy.  Your first ship won't have the structural integrity to land on a planet but when you are able to, planets will have hotspots to conquer.  The galaxy will be limited because more interaction with players and less places to hide!  But really its all about getting your hands dirty trying to survive in hell.  Good luck!  There will be more on the features later when that part of the development cycle nears.  I will be very interested in taking suggestions for features.

Last Minute Notes

Originally the framework was Java then I switched to C# to see if performance would be better, it wasn't.  Although I really did enjoy messing with Async/Await methods.  Maybe I will release the source for the C# version one day.

This framework, however, is still under development and the source will never be released to the public.  Sorry, but way to much time/stress has been put into it.  Besides that there will be the 3rd party api to allow users to create custom content.  Third party dev will probably be the last task, unfortunately.  Have to get the core components mostly bug free before I will be satisfied.  I will be posting later down the road when I will be taking in spriters, same pixelated width/height as SS13 sprites, and programmers.  I try my best but I am no artist.  And there is a lot of code.  Also if you are a fellow java programmer interested in my approach on certain aspects, please email me or comment below and I will try to oblige.  Some subjects are out of the question, like how user accounts are handled server-side, packet structure, etc.

More updates every month, please subscribe.
To be continued...