Senior Project Update SmartFox Server

So I spent yesterday looking at the code in regards to a server issue I am having. The issue is that the socket reader is throwing an exception whenever the player leaves the room.

Quite frankly I have been stuck on this for two days now. I even made a post in the SmartFox forums to see if anybody could help me out with it. To see details, here is the link: Socket Reader NullPointerException .

Other than that I have not been doing much in regards to Unity or SmartFox Server. However, when all the issues server side are fixed I plan on cleaning up the presentation of the game GUI. Our other programmer is working on the camera scripts for the game so that the camera doesn't follow the ship perfectly, making for dull looking gameplay action.

The Final Stretch

I knew this day would come eventually. The beginning of the end, as the cliche goes. Today marks the last eight weeks of my time at DeVry. With it, comes the closing hours of my Senior Project - Starbound Aces.

This week we will be spending time organizing data about Alpha gameplay reviews and comments to make some bug fixes as well as fleshing out the game. However, to be quite frank, any efforts to have unbiased third parties to test the game were a complete, miserable flop. Any attempts - on two forums and a couple of social media websites - resulted in only one comment in regards to the game. Thankfully, there are some close friends and allies who were able to play the multiplayer version of the game with me and give some feedback.

Most of the feedback was as follows:

-How do I x?
-Where are you?
-Am I flying?

Indeed, a lot of that is just questions. Which means there are some things in the game that need fixing. First off, a help menu for those who don't know how to play. I spent too much time assuming that people playing would have a natural assumption of 3rd person PC gaming controls. That was ignorance on my part. Secondly, the movement/camera scripts need and overhaul in regards to the actual gameplay. This is the task of the other programmer on the team. Finally, fixing the player name displays to be locked on viewport will give players an idea where other players are at in regards to the game world. Space is too big to hide player names by not locking them to the viewport. A later screen shot will show what I mean by this.

Until next time, enjoy your game programming, because I certainly will - until it doesn't works when it was working before and I have no idea why so I just restart my computer hoping that will fix the issue but that obviously wasn't the issue because it turns out to be some stupid thing I did late at night when I was obviously too tired or drunk to remember doing it and sure I thought it was a cool thing to add into the game but it clearly wasn't a good time to put it in and of course I forgot to commit my latest changes and I already saved and closed so there is no mercy in the Ctrl+Z department which I think is stupid but oh well that is how it goes and it turns out to be that I overrode a method in a class and so the base class was not being called so really the big issue is stupidity and one line of code then that is when game programming is not enjoyable but I still enjoy it anyways.

Unity / SmartFox Senior Project : Halfway Point

Today marks the halfway marker for our Unity project: Starbound Aces. It has been a long 8 weeks of producing documentation and an Alpha version. Playable here: Play Starbound Aces

I want to spend this time recapping all of the work done for the game and what I would have done differently in regards to the programming architecture of the game. Then I would like to explain what will happen moving forward from here.

In regards to the recap there are several subjects I would like to cover. These subjects are server extension design, database design, and the client side design.

The server extension design was originally intended to follow a simple authoritative design in which client data was verified by various classes. These classes I called game drivers. Each class was responsible for collecting data from each client. This was implemented fairly simply but did not achieve its ultimate purpose. Each of these classes were to have validation methods built in that accepted or rejected client data by virtue of 'is it possible'. For instance, if the client says their position is at a given point, the ship validation (containing all information for movement such as acceleration, velocity, position, and rotation) would determine whether this was possible in the time passed and the given latency. If not, it would tell the client that their ship is elsewhere. When implementing this method however, even without the validation, it caused a lot of jumping around client side. This leads into what I would have done differently in regards to the server extension design.

What I would have done differently in regards to server extension design is completely simulate, and drive, the game from the server. What does this mean? Well, it would imply all physics, movement, game logic, events, combat, everything, would be handled server side. Essentially, the game core systems to drive it would have been programmed server side. The only responsibility of Unity would be to collect the data, render, connect, give user feedback, and get user input.

The database design of the project was small. There are only three tables and two that are actually used. The two tables that are used are for the user and the user scores. This is simple enough and was just enough to accomplish the lowest core requirements of the game. This I have no problem with and went without a hitch.

There are a few, more ambitious, ways I would have used the database.

Now, what I wanted to have done is much more in depth. On top of the scores and users, I wanted to add in functionality for the game table. The game table would hold metadata about each game played. This would allow new people joining the lobby to see a game created before they entered. It would also allow a player to see their past game statistics. Finally, I would have added more tables for ship configurations. This would hold all data for each weapon, projectile, and ship hull available. It would then allow players to set configurations when connected to the server and pick one for the game they are about to join.

The client design I turned out to work well with what was originally planned with a few modifications. The SmartFox Server singleton class did the grunt of the work. Its main responsibility was to connect, login, handle events, and forward data between client and server. This worked out excellently without any problems and worked as intended.

There are few things I would have changed. One would have been to create smaller scripts based on network actions. These scripts would look similar to the one I added last week called NetworkTransform:

public enum NetworkObjectType {

    PLAYER = 0,

    PROJECTILE

}

public enum CommunicationType {

    SEND_ONLY,

    RECEIVE_ONLY,

    SEND_AND_RECEIVE

}

public class NetworkTransformer : MonoBehaviour, IEventListener {

    public NetworkObjectType type;

    public CommunicationType commType;

    private int networkId = -1;

    private string stype;

    private IClientController server;

// Use this for initialization

void Start () {

        server = GameManager.gameManager.ClientController;

        server.Register(this);

        switch (type) {

            case NetworkObjectType.PLAYER:

                stype = "player";

                break;

            case NetworkObjectType.PROJECTILE:

                stype = "projectile";

                break;

            default:

                break;

        }

}

    public int NetworkId {

        get {

            return networkId;

        }

        set {

            networkId = value;

        }

    }

// Update is called once per frame

void Update () {

        if (commType == CommunicationType.SEND_ONLY || commType == CommunicationType.SEND_AND_RECEIVE) {

            SendData();

        }

}

    private float delay = 0.1f;

    private float timepassed = 0.0f;

    private void SendData() {

        timepassed += Time.deltaTime;

        if (timepassed >= delay) {

            switch (type) {

                case NetworkObjectType.PLAYER:

                    SendPlayerData();

                    break;

                case NetworkObjectType.PROJECTILE:

                    SendProjectileData();

                    break;

                default:

                    break;

            }

            

            timepassed = 0.0f;

        }

    }

    private void SendPlayerData() {

        Dictionary<string, object> data = new Dictionary<string, object>();

        data.Add("transform", transform);

        data.Add("type", stype);

        server.Send(DataType.TRANSFORM, data);

    }

    private void SendProjectileData() {

        Dictionary<string, object> data = new Dictionary<string, object>();

        data.Add("transform", transform);

        data.Add("type", stype);

        data.Add("networkId", networkId);

        server.Send(DataType.TRANSFORM, data);

    }

    public void Notify(string eventType, object o) {

        if (commType == CommunicationType.RECEIVE_ONLY || commType == CommunicationType.SEND_AND_RECEIVE) {

            switch (eventType) {

                case "transform":

                    handleTransform(o);

                    break;

                default:

                    break;

            }

        }

    }

    void OnDestroy() {

        GameManager.gameManager.ClientController.Unregister(this);

    }

    private void handleTransform(object o) {

        Dictionary<string, object> data = o as Dictionary<string, object>;

        int id = (int)data["id"];

        if (id != networkId) {

            return;

        }

        float px = (float)data["position.x"];

        float py = (float)data["position.y"];

        float pz = (float)data["position.z"];

        float rx = (float)data["rotation.x"];

        float ry = (float)data["rotation.y"];

        float rz = (float)data["rotation.z"];

        float rw = (float)data["rotation.w"];

        transform.position = new Vector3(px, py, pz);

        transform.rotation = new Quaternion(rx, ry, rz, rw);

    }

}

This class was hacked in to resolve issues where the SmartFox instance on the client side was doing too much management of data and resolving who gets what data rather than forwarding its data as originally designed. In fact, I would dare say I would have created a base script for this design that determined whether an object was send, receive, or send and receive only, then create a class for each type of network event possible. Right now, a lot of the scripts are tied to specific functionality and make reuse virtually non-existent - poor OOP design.

Moving forward we have a lot of plans for the game in regards to our class. A lot of the work to be done is related to the features of the game. So, unfortunately, most of what I said before of how I should have/ wanted to do things will not be implemented in this game. So, here is a list of what I need to get done, but I will not go into long winded detail right now. Next week though, I will explain how I will go about this when my final class starts, and the last 8 weeks of this project. Here is what I plan on getting done for next period:

• Fix room leaving errors on server side
• Fix users attempting to double join rooms
• Email response to activate accounts
• Clean up all GUIs in the game
• Implement full database for game creation
• Create game waiting lobby so players can queue before going into a game
• Generating random space debris
• Fix messaging between client and server as redundant and 'dead' data is being sent.

Unity Senior Project Update Video

Whoa! What is this? An Update video for the epic Starbound Aces.

I did a massive update to a lot of the assets in the game as well as the GUI. As promised, this game now looks somewhat slicker. Also, here is a free video for your enjoyment!

Wow! Isn't that awesome, and aren't I awesome to share it with you!? Please comment on what you think so far to help improve the project.

Unity and SmartFox Server Update

Whew, I did it!

I spent the last four hours of my life trying to fix code and implement features. I accomplished what I set for goals for myself today. These goals were to streamline the Unity UI and get players registered into the score database table when they register for the game.

The Unity GUI is a powerful tool. It allows for a lot of customization. Add that to their already powerful scripting engine, they have it made. The GUI buttons and test fields that I already had in the game seemed generic and stale. As they should have been. They were using the engine default styles. This was easily fixed by exposing a public GUIStyle to the editor and applying it to all the buttons in that level. Finally, I made it easier to position the buttons and see changes by exposing the rectangles that define their position width and height to the editor. This allowed for a more streamlined approach of custom GUIStyles.

The server side code was a bit of an issue. There were two issues in my way that soaked up a lot of my time. These issues were a dumb mistake on my part and a issue with SmartFox Server itself. The first mistake was that I was setting query executes to not autocommit. With the jdbc drivers this caused any update or insert SQL queries to not be, well executed. The problem was that I was stupidly not calling the connection to commit the changes. The second issue was something I had not run into before. The SignUpAssistantComponent from SmartFoxServer allows you to do pre and post processing by defining an interface. The interface takes several parameters. These are the user, the SFSObject, and the config itself. The preprocessor worked fine with all of the parameters. However, the postprocessor seemed to have lost scope of the SFSObject. Any calls to get any type of data resulted in NullPointerExceptions. I circumnavigated this issue by providing the needed data (the username of the registering player) as a user variable for the temporarily logged in guest user during registration.

All in all, it was a long day and I spent what seemed too long working in circles. I am glad that I was able to accomplish my goals. Soon, I will have a video up with some in-game theme music and *hopefully* some artwork.

Unity GUI and HighScores

Quick update of what I plan on getting done after work today. The goals I have in mind for today are to customize our GUI menus and getting the high scores scene to display player scores.

For the most part, our game is a handful of menus and a multiplayer level. Since most people will be seeing our menu system first, I figured beautifying first would be a good goal to have. Right now we are using the basic GUI.Button calls in the OnGUI event in Unity. This is fine for prototyping, but we need a game with our own look. So, I am using the overloaded method of the GUI.Button methods. These take GUIStyle and GUIContent arguments. Thankfully, these are member fields that are configured to be edited in a friendly manner from the Unity Editor. This will make the life of our artist easier.

Secondly, I want to get the score table in our SQL database to work correctly. What is supposed to happen in the SignUpAssistantComponent postprocessor is that the server will insert the user into the scores table. This will allow them to keep track of their scores. In our game, there is an option to view highscores. In this scene I hope to show the player's current score and rank, the top ten players and their scores. I also want to put in a scrolling menu for going through all of the other players' scores.

I will have an update post later tonight on what I accomplished so far. Hopefully it won't look like I took a step backwards.

Game Maker Graphical User Interface

So this morning I pretty much finished up all of the basic enemy AI logic (minus combat) and decided to work on the shop system. This system will be simple. The system is based more on an action game than an RPG in which you have a handful of upgrades to buy at the shop. They are not items, just upgrades. They will increase the respective ability by a small percentage, increasing in price with each use.

This lead me to start creating some kind of menu system. Simple, I have done this before in straight C++ code, all you really need is a template of the logic of a menu system - buttons, backgrounds, and messages. In GameMaker: Studio, this is simpler because it has a bunch of User Interface predefined events. It also has a separate Draw event called Draw GUI.

I implemented all of this with ease except that when I moved all of the code for the shop menu for the Draw Event to the Draw GUI Event, my buttons stopped working. So now I need to figure out how the GUI detects mouse clicks and position.

I will come up with a solution tonight and share with everyone!