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...