Idea

To set itself apart from other Multiplayer Solutions, Big-Tony will include a built-in HTTP server. This server needs to be ridiculously fast, modular, and have a simple API. It should support creating custom endpoints, middleware, and file-serving. The API should be loosely modeled after the Express Library for Node.js, but with the language paradigms of C#. It will need to be multithreaded and should include as many optimizations in its base form as possible.

Implementation

The implementation should go under a new folder called HTTP and should follow a similar structure to the rest of the codebase. It should, like mentioned before, have a flexible architecture and simple API, while still providing speed and performance to the end-user. This tool is being built for developers, and so the documentation should be full of examples and useful information on how to use it.

Requirements

• Built in Optimizations (Speed by Default)
  • Multi-threading
  • Compiler Optimizations
• Flexibility
  • Base class that allows endpoints to be attached
  • Options that can be controlled by a file, command-line, or through the API
  • Control over Performance Optimizations
• Design
  • The code structure should follow the structure of the rest of the project
  • This library is built for C#, so the API design should follow the language's paradigms
  • All of the code should be thoughly documented with example functions

Idea

Structs are much faster than classes when used with arrays, and so we should switch over to them. It also forces the users into a certain use-case which will be much faster than the current use-cases.

Implementation

The idea and title say it all.

Requirements

• All of the systems still function

Idea

There is no doubt, Big Tony is going to be huge. There needs to be a system to customize how each user will use the hundreds of different options available. So far, there will need to be three different ways to set up these configurations: config file, command-line config, and config through API. I really like how the C++ config files work, but I think JSON or XML files could work well too.

Implementation

I think that the way it should work is a .config file could be created. I think it could be interesting if the machine could automatically tell what kind of file it is. But, to be completely honest, this approach would be stupid. Each line should just have a key and a value. It would be formatted as: key: value, and it would be the most efficient option.

For the CLI, you should just be able to input the keys and values one after each other. This would be a simple syntax, just like this... key=value. This should work for most of the use cases, and if it didn't, the user could easily use the .config files.

Finally, for the API, there should be a JSON-like syntax. This could also flow into things like enabling or disabling the HTTP server and Voice Channel systems. In terms of which setup system is most important (overrides the others), the API would be the most, and then would be the CLI, and finally would be the .config file.

Requirements

• File Parser
  • Doesn't Parse Comments
  • Ignores stupid spaces to make syntax more flexible
• All values stored in a static Dictionary
• Config
  • File should just be line based
  • Comments should start with a hashtag
  • Equal sign should separate the key with a value
• CLI
• API

Idea

So... the entire system is not mutlithreaded anymore because I refactored the architecture.

Implementation

Just make sure that the multithreading works properly and is efficient.

Requirements

• Add back Multithread Entire System
• Make sure that it doesn't break everything

Idea

I love playing TF2. Like if I were to give an award for some of the best games of all time, my top three would probably be Wii Sports, TF2, and CS:GO. There are a couple of things that make these games great. But, one of the best things (mostly for TF2 and CS:GO) is the ability for users to create their own experiences. In these two games, the way this is done is through server commands. There are command prompts for users to enter in commands, and if the command is to affect everyone on the server (like altering gravity), the client just sends the command to the server. From here, the server determines if the user has the right permissions, and if they do, the command is executed. The results from the command are then sent back to the user as well, but that is not as important.

Implementation

So, the console system needs to be fairly straightforward. The user sends a UDP packet to the server, and the server responds with another UDP packet. I am more of a visual learner, and probably more of a visual teacher too, so I will just show examples below and write notes below them.

Client

0x03      spawn cow

The user wants the server to read a message from it, so it needs to start with '0x03'. After that, all of the following message is written in plaintext and will be interpreted as a string.

Server

0x00      Invalid Permissions

The user is not an administrator, so they are unable to run the command. The server must reply with a code of '0x00' to show that the command has failed, and an error message following it. The error message will always be a string.

Server

0x01      Cow Successfully Spawned

The user has the right permissions, so the command was successfully run. The first byte is '0x01' to show that it was a success, and from there, the server can leave whatever message it wants.

Requirements

• Request
  • There are no buffer overflow or errors generated by the function
  • The commands are interpreted as strings and have a shell-like syntax
  • The developer can create custom commands that have an express-like syntax
• Response
  • The responses can have a code ranging anywhere from 0x00 to 0xFF.
  • They can be easily interpreted by clients
  • All response messages have a code to start them
  • All replies have a reason for failure or information if its a success

Idea

I was using Doxygen the other day and couldn't figure it out. Even when using the documentation- nothing made sense. The only thing that worked when setting up the config file was an option that let Doxygen generate the entire file using the default settings. And on top of that, it provided great comments that told the user how to use the parameters.

So, the idea is to make a system that lets Big Tony automatically generate config files with all of the default values inside of them. This should be pretty easy, all it would take is an array of structs and the function that would actually create the plaintext file.

Implementation

As mentioned before, an array of structs to store the default variables as well as a plaintext file generator function should work.

Requirements

• Default values always match those generated
• Descriptions are wrapped so that they fit within ~80 character range
• The file matches the syntax parsed by the Big Tony config file parser
• Function is run when the user uses the config command