JevaEngine - Underground Outbreak Online is a multiplayer game I have been working on while also advancing the multiplayer capabilities of the engine. I will be hosting the servers hopefully sometime tomorrow night for a solid day or two if anyone is interested in joining me and testing out some networking code.
Here are some early screen shots of multiplayer (sorry for the simplistic scenery, I was a little tired making this map...):
JevaEngine's first game, Outbreak (A simple multiplayer Zombie RPG) is almost ready.
Currently there are a few things being touched up. Here is some of the latest:
- Snagged a very tricky bug in the Jeva Communicator library that caused network entities overlap IDs in one another in a very inconspicuous way.
- Fixed a few problems found in the path finding algorithm that went largely unnoticed up until now.
- Enhanced the TextArea UI Component a bit.
- Added a chat-system to the Multiplayer RPG module.
- Windows 8 Builds seem to be having trouble with rendering JevaEngine at optimal framerates. This may be due to a misconfiguration of the machine I am working on and I do intend of traveling to School this weekend to try it out on a few machines and determine how sufficient the networking is.
- Movement Synchronization seems to be a little rough due to latency in server transmission - it is a simple fix and will likely be implemented after the initial release.
Thanks for staying interested!
After the inital release I am going to fine tune the engine, add some features on my to-do list that are implemented in the engine but entities don't have sufficient access to via scripts (lighting, particles, projectiles) and then potentially start looking for a team depending on how well the initial release does.
JevaEngine now has a very solid networking implementation, that includes entities such as AreaTriggers and NPC Characters and various other basic entities (doors etc...)
The way it works is something like: - Every networked entity has a script associated with it. There is a client script (stored and executed on the client) and a server script (stored and executed on the server) Both work exactly the same as entity scripts did before (i.e, with single player.) Server scripts work on the entity for i.e movements etc. Client scripts do the same for strictly client-side tasks (like playing the 'die sound' when a character dies) While client scripts can technically alter states such as location, they will be resynced with the server when the next snapshot is recieved.
I am going to be releasing a basic game to demo this, the game works something like this (and will be published on game jolt) I will deploy the server on my computer which should be good for ~45-50 players with 175 complex entities (that is, entities with very active AI constantly mutating states that need to be shared accross clients):
1. Players spawn as soldiers on the map - except for the two top-ranking players of the previous map. Soliders play a sort of Rpg Perspective - they can loot for better weapons and level up per round (i.e, after the round is reset - their character is reset) If I can, for the first couple of releases, I want to avoid having to keep track of players beyond individual rounds etc because that requires a backend database implementation that detracts for the purpose of the first couple of releases requires more serious security considerations.
2. The first of the two top-ranking players will be the master of the World's spider hive. I.e, they play a sort of RTS perspective of the game and control the spider NPC army of the multiplayer game.
3. The second of the two top-ranking players will be the same except for Zombies
4. Spiders and Zombies work together to kill the soldiers and vise-versa. Trophies are earned for being a top-ranked player for a given period of time, killing x spiders etc.
@ryan.dansie if there was an upvote button I'd click it for that last bit of humor you provided me.
Speaking of which, this forum needs an upvote buttom
On Topic:
I'd essentially reiterate what everyone else here has said. You need to prove that you bring some value to the table before you start recruiting members - espeically when compensation is based on % revenue. They don't want to be doing all the work to get 30% of the profits - you have to make yourself worth the 70/60/50%. That usually means you need to be the one to kick-start the project and push it into a stage where it would be optimal to have several team members and where it can be seen as a project with potential.
Finally the idea that you aren't here to make friends is disturbing. For small indie projects you need your team members to cooperate very well. You need friends in your team.
@William the GC works that way for most GCed environments. Objects are only collected when they both aren't at all referenced (or Soft\Weak referenced) and when their is a need to do so (since the GC cycle can impact performance if it runs too frequently and usually these excess cycles are a waste until memory nears considerable exhaustion) Forcing the GC to collect is a discouraged practice since most of the time it results in poorer performance for those reasons.
My point about Trash was that it is actually a well established design pattern called the dispose pattern. You can look at a proper implementation for it in AS3Commons.
Your Trash function doesn't have any effect because all it does is dereference internal members - which in turn must wait for the GC to collect them anyways. If this improves performance it is because you have a reference still to the NPC object somewhere.
You shouldn't need method overloading to do as I described. In fact, I would probably make something like faceObj final anyways - it doesn't make sense to override\overload an implementation like that.
Anyway, they're just some basic suggestions, feel free to ignore them if you'd like - this is your project and you are much more familiar than I am with the code.
I really don't ever touch AS3 code but I'll do my best to provide some feedback with my programming experience outside of AS3.
For Managed\Garbage Collected environments like Flash, Java, .Net etc the pattern you use in CharacterLogic/NPC.as (with the Trash routine) is called the dispose pattern. The best way to do it is to implement a common interface IDisposable so whoever is looking at the code can tell right off the bat if an object needs to be disposed (trashed) or not before dereferencing it.
Aside from that, the only other thing I could suggest while I was (albeit very quickly) looking over the code was that you have some boilderplate code (i.e, your NPCs share some of the same implementation as Hero) You could create an abstract Character class to contain those common implementations and then have Hero & NPC inherit from that Character.
I personally haven't used Tiled. It looks great but I'm not sure how well it scales with the complexity of the game - if it's all you need though it should work out fine. That said, from my experience, writing a tailored editor is essentially just writing some wrapper and UI code around some abstract game components and it really isn't as tedious as it sounds to do. (i.e, my map editor is essentially 4 small classes. Two of those are wrappers (i.e composition) around an abstract tile & entity class with sufficient metadata to serialize them to a save file etc. The other is some UI Code, and the last is just some code to initialize the game and UI and have them work together.) The point is that the Map Editor should be built directly off of the game - it makes it very easy to implement and maintain.
Here is a demo of the game server and client. I am still polishing up a few things then I intend on creating a simple game out of it to do some server load testing. The server is on the left, the client on the right. This demo illustrates only one client - though the server is capable of managing many clients.
The Screen Recorder I use eats up CPU Cycles like a monster so I can't record with a decent frame-rate.
Load Times:
The load times for the spider sprite in particular is quite slow. This is due to the Spider's texture file being absurdly large and inefficeint. You will see the client Freeze and the server Freeze as the spider is loaded into the world for about 5s, usually the assets would go through a precache process to avoid the load times while in-game, but precaching is not an immdediate concearn and has thus been thrown on-to the 'do later' task-list.
The load times for worlds are slow, this is because the worlds are currently stored in a plain-text (sort of like XML but with less overhead) format. This means that with large worlds and many layers it takes a large amount of CPU time to parse them. Optimally (and in later stages of development) these worlds will be stored in a binary format. Once the map files have actually been parsed, my profiler informs me that the actual LOADING of the map using the intermediate data structures fromed via the parsing process is very quick.
Security from client-side tampering:
In theory (if I'm not missing any bugs here) it is impossible for the clients to alter the state explicitly of any server entity without first asking the server so the game should be safe from game tampering. Additionally I have employed data encryption and code obfuscation\optimizations to ecourage would-be hackers to give up. The worst someone could do is to throw the client out of sync with the server, but it would have no effect on other clients or the server.
Please post any feedback, it is appreciated.
What I am doing now:
- I will be resolving a very obscure and difficult to reproduce bug in the server - Polishing & finalizing the server & networking code. - Creating an actual multiplayer game out of the recent advancements in the engine to do some load-testing on the server.
I'm not sure where I am going to deploy the server... I can't deploy it on this piece of crap because it barely does two things at once and I need access to my IDE. I have another computer I could deploy it on but it isn't 'mine' per se.
Network Subsystem is nearly completed, I believe I will have some basic networking to show off soon.
It looks like server-side scripted entities are actually going to be quite easy to implement, and all features in the game (minus dialog which will require some tweaking since dialogs pause the server-side world state) will seamlessly be handled on the server-side and fed to the clients.
The network-subsystem took a bit of work, but with the current implementation I am hoping for minimum bandwidth consumption.
The networking is going to be implemented outside of the engine's core. This makes most sense to me since the actual model used for networking can be most optimally chosen outside of the core of the engine. I.e, if movement is strictly tile-based (as it is for the RPG Extension) then movement can be abstracted to a very low-bandwidth per-tile level. If it is more complex than that (i.e, not strictly tile based) then obviously it may require some more bandwidth intensive operations etc to portray velocity, acceleration location etc and a more complex client-side prediction.
The current networking model communicates to clients using snapshots broadcasted at a fixed frequency. Using snapshots allows data network data to be queued for a fixed frequency and then dispatched to the client (and vise-versa) This is an avantage as compression ratios are best with larger chunks of data and it avoids redudant data being dispatched over at a very high frequency (wasting bandwidth.)
I've started to implement the networking subsytem.
Planning the implementation will not be an easy task but I feel that by using Reflection and Annotations I can pull off a relativley nifty implementation that doesn't leave too much of a 'footprint' on the existing code in the engine.
It needs to be done very carefully so I do tend on spending a good two or three days planning out this implementation thoroughly before hacking into it. The networking Sub-System for the engine's core will, without a doubt, be one of the more challenging implementations I will have to do on this engine.
That said, so far, I am relativley impressed with the minimal amount of code-refactoring that has needed to come out of scaling the engine accross multiple larger functions, so I hope that the design of the engine as it stands will allow me to do this very easily.
JevaEngine - Underground Outbreak Online is a multiplayer game I have been working on while also advancing the multiplayer capabilities of the engine. I will be hosting the servers hopefully sometime tomorrow night for a solid day or two if anyone is interested in joining me and testing out some networking code.
Here are some early screen shots of multiplayer (sorry for the simplistic scenery, I was a little tired making this map...):
JevaEngine's first game, Outbreak (A simple multiplayer Zombie RPG) is almost ready.
Currently there are a few things being touched up. Here is some of the latest:
- Snagged a very tricky bug in the Jeva Communicator library that caused network entities overlap IDs in one another in a very inconspicuous way.
- Fixed a few problems found in the path finding algorithm that went largely unnoticed up until now.
- Enhanced the TextArea UI Component a bit.
- Added a chat-system to the Multiplayer RPG module.
- Windows 8 Builds seem to be having trouble with rendering JevaEngine at optimal framerates. This may be due to a misconfiguration of the machine I am working on and I do intend of traveling to School this weekend to try it out on a few machines and determine how sufficient the networking is.
- Movement Synchronization seems to be a little rough due to latency in server transmission - it is a simple fix and will likely be implemented after the initial release.
Thanks for staying interested!
After the inital release I am going to fine tune the engine, add some features on my to-do list that are implemented in the engine but entities don't have sufficient access to via scripts (lighting, particles, projectiles) and then potentially start looking for a team depending on how well the initial release does.
Latest Networking Demonstration:
http://www.youtube.com/watch?v=v-52aKJ4Smo
I sort of feel like a scum-bag using all thse Flare assets to show off my engine. They're perfect though - they are all isometric :)
Anyway, for all the contributors to Flare's asset library it is well appreciated. I am careful to credit all the work.
Thanks.
JevaEngine now has a very solid networking implementation, that includes entities such as AreaTriggers and NPC Characters and various other basic entities (doors etc...)
The way it works is something like:
- Every networked entity has a script associated with it. There is a client script (stored and executed on the client) and a server script (stored and executed on the server) Both work exactly the same as entity scripts did before (i.e, with single player.) Server scripts work on the entity for i.e movements etc. Client scripts do the same for strictly client-side tasks (like playing the 'die sound' when a character dies) While client scripts can technically alter states such as location, they will be resynced with the server when the next snapshot is recieved.
I am going to be releasing a basic game to demo this, the game works something like this (and will be published on game jolt) I will deploy the server on my computer which should be good for ~45-50 players with 175 complex entities (that is, entities with very active AI constantly mutating states that need to be shared accross clients):
1. Players spawn as soldiers on the map - except for the two top-ranking players of the previous map. Soliders play a sort of Rpg Perspective - they can loot for better weapons and level up per round (i.e, after the round is reset - their character is reset) If I can, for the first couple of releases, I want to avoid having to keep track of players beyond individual rounds etc because that requires a backend database implementation that detracts for the purpose of the first couple of releases requires more serious security considerations.
2. The first of the two top-ranking players will be the master of the World's spider hive. I.e, they play a sort of RTS perspective of the game and control the spider NPC army of the multiplayer game.
3. The second of the two top-ranking players will be the same except for Zombies
4. Spiders and Zombies work together to kill the soldiers and vise-versa. Trophies are earned for being a top-ranked player for a given period of time, killing x spiders etc.
@ryan.dansie if there was an upvote button I'd click it for that last bit of humor you provided me.
Speaking of which, this forum needs an upvote buttom
On Topic:
I'd essentially reiterate what everyone else here has said. You need to prove that you bring some value to the table before you start recruiting members - espeically when compensation is based on % revenue. They don't want to be doing all the work to get 30% of the profits - you have to make yourself worth the 70/60/50%. That usually means you need to be the one to kick-start the project and push it into a stage where it would be optimal to have several team members and where it can be seen as a project with potential.
Finally the idea that you aren't here to make friends is disturbing. For small indie projects you need your team members to cooperate very well. You need friends in your team.
@William the GC works that way for most GCed environments. Objects are only collected when they both aren't at all referenced (or Soft\Weak referenced) and when their is a need to do so (since the GC cycle can impact performance if it runs too frequently and usually these excess cycles are a waste until memory nears considerable exhaustion) Forcing the GC to collect is a discouraged practice since most of the time it results in poorer performance for those reasons.
My point about Trash was that it is actually a well established design pattern called the dispose pattern. You can look at a proper implementation for it in AS3Commons.
Your Trash function doesn't have any effect because all it does is dereference internal members - which in turn must wait for the GC to collect them anyways. If this improves performance it is because you have a reference still to the NPC object somewhere.
You shouldn't need method overloading to do as I described. In fact, I would probably make something like faceObj final anyways - it doesn't make sense to override\overload an implementation like that.
Anyway, they're just some basic suggestions, feel free to ignore them if you'd like - this is your project and you are much more familiar than I am with the code.
Just going to throw in an opinion here:
I really don't ever touch AS3 code but I'll do my best to provide some feedback with my programming experience outside of AS3.
For Managed\Garbage Collected environments like Flash, Java, .Net etc the pattern you use in CharacterLogic/NPC.as (with the Trash routine) is called the dispose pattern. The best way to do it is to implement a common interface IDisposable so whoever is looking at the code can tell right off the bat if an object needs to be disposed (trashed) or not before dereferencing it.
http://en.wikipedia.org/wiki/Dispose_pattern
Aside from that, the only other thing I could suggest while I was (albeit very quickly) looking over the code was that you have some boilderplate code (i.e, your NPCs share some of the same implementation as Hero) You could create an abstract Character class to contain those common implementations and then have Hero & NPC inherit from that Character.
I personally haven't used Tiled. It looks great but I'm not sure how well it scales with the complexity of the game - if it's all you need though it should work out fine. That said, from my experience, writing a tailored editor is essentially just writing some wrapper and UI code around some abstract game components and it really isn't as tedious as it sounds to do. (i.e, my map editor is essentially 4 small classes. Two of those are wrappers (i.e composition) around an abstract tile & entity class with sufficient metadata to serialize them to a save file etc. The other is some UI Code, and the last is just some code to initialize the game and UI and have them work together.) The point is that the Map Editor should be built directly off of the game - it makes it very easy to implement and maintain.
Anyway, looks great so far, keep it up.
Video of Server & Client Networking Demo (Watch in 720p)
http://www.youtube.com/watch?v=4aJhpaTUDro
Networking is fully operational:
Here is a demo of the game server and client. I am still polishing up a few things then I intend on creating a simple game out of it to do some server load testing. The server is on the left, the client on the right. This demo illustrates only one client - though the server is capable of managing many clients.
The Screen Recorder I use eats up CPU Cycles like a monster so I can't record with a decent frame-rate.
Load Times:
The load times for the spider sprite in particular is quite slow. This is due to the Spider's texture file being absurdly large and inefficeint. You will see the client Freeze and the server Freeze as the spider is loaded into the world for about 5s, usually the assets would go through a precache process to avoid the load times while in-game, but precaching is not an immdediate concearn and has thus been thrown on-to the 'do later' task-list.
The load times for worlds are slow, this is because the worlds are currently stored in a plain-text (sort of like XML but with less overhead) format. This means that with large worlds and many layers it takes a large amount of CPU time to parse them. Optimally (and in later stages of development) these worlds will be stored in a binary format. Once the map files have actually been parsed, my profiler informs me that the actual LOADING of the map using the intermediate data structures fromed via the parsing process is very quick.
Security from client-side tampering:
In theory (if I'm not missing any bugs here) it is impossible for the clients to alter the state explicitly of any server entity without first asking the server so the game should be safe from game tampering. Additionally I have employed data encryption and code obfuscation\optimizations to ecourage would-be hackers to give up. The worst someone could do is to throw the client out of sync with the server, but it would have no effect on other clients or the server.
Please post any feedback, it is appreciated.
What I am doing now:
- I will be resolving a very obscure and difficult to reproduce bug in the server
- Polishing & finalizing the server & networking code.
- Creating an actual multiplayer game out of the recent advancements in the engine to do some load-testing on the server.
I'm not sure where I am going to deploy the server... I can't deploy it on this piece of crap because it barely does two things at once and I need access to my IDE. I have another computer I could deploy it on but it isn't 'mine' per se.
Network Subsystem is nearly completed, I believe I will have some basic networking to show off soon.
It looks like server-side scripted entities are actually going to be quite easy to implement, and all features in the game (minus dialog which will require some tweaking since dialogs pause the server-side world state) will seamlessly be handled on the server-side and fed to the clients.
The network-subsystem took a bit of work, but with the current implementation I am hoping for minimum bandwidth consumption.
The networking is going to be implemented outside of the engine's core. This makes most sense to me since the actual model used for networking can be most optimally chosen outside of the core of the engine. I.e, if movement is strictly tile-based (as it is for the RPG Extension) then movement can be abstracted to a very low-bandwidth per-tile level. If it is more complex than that (i.e, not strictly tile based) then obviously it may require some more bandwidth intensive operations etc to portray velocity, acceleration location etc and a more complex client-side prediction.
The current networking model communicates to clients using snapshots broadcasted at a fixed frequency. Using snapshots allows data network data to be queued for a fixed frequency and then dispatched to the client (and vise-versa) This is an avantage as compression ratios are best with larger chunks of data and it avoids redudant data being dispatched over at a very high frequency (wasting bandwidth.)
Anyway, updates to follow.
I've started to implement the networking subsytem.
Planning the implementation will not be an easy task but I feel that by using Reflection and Annotations I can pull off a relativley nifty implementation that doesn't leave too much of a 'footprint' on the existing code in the engine.
It needs to be done very carefully so I do tend on spending a good two or three days planning out this implementation thoroughly before hacking into it. The networking Sub-System for the engine's core will, without a doubt, be one of the more challenging implementations I will have to do on this engine.
That said, so far, I am relativley impressed with the minimal amount of code-refactoring that has needed to come out of scaling the engine accross multiple larger functions, so I hope that the design of the engine as it stands will allow me to do this very easily.
Pages