Weekday Update w/ Video

I hope everyone had a good Memorial Day and weekend - I sure did. Now onto business, the state of the game.

Starbound Aces is coming along very nicely. Since my last video update I have introduced a lot of new features and changes since my last update. I will compare as they are seen in this video:

This video shows everything from a week ago. Over that time I have made a lot of changes. Many of them are simple optimizations and bug fixes. However, there are a few that are noticeable in the game. These changes are:

-Inserted a new game menu option: Ship configuration
-Changed the engine effect to a trail renderer
-Changed the tracking system of the seeker missile.
-Tweaked some variables

Here are the changes that the other programmer, David Tiscerano, incorporated:
-Cooldown system for manuevers
-HUD Display of cooldown

Many of the other busy work has been behind the scenes tweaks and optimization. Until next time - Enjoy game programming!

Systems Operational (5PM Hosting of Alpha Test)

Alright, alright, alright, it has been a long day of coding for the past six hours of my life. That makes a total of  eleven hours of coding in the past sixteen. So I have a few new features to show off, some screen shots, and later in the day, some videos.

First off, let us take a look at some of the new features. These new features are:

• Weapon Configuration in Multiplayer
• In-match HUD Display
• Weapon Cooldown
• Current Ammunition
• Damage Effects
• Server Side Configurations

The weapon configuration goes hand in hand with the server side configurations I just listed. Now a player can choose between two weapons at the moment, Cannon (More damage, straight shot) or Seeker Missile Launcher (Less Damage, Longer Range, Follows target). When the player chooses one of these options pre-match the GameManager takes a note of this and when the player spawns, tells the server to get all of the data needed to implement the weapons. Visually, they are the same at the moment and we want to add one more - a laser beam.

Secondly, we now have some information in the game during a match in regards to combat. This information is minimal. The first is a cross-hair, that when within a certain distance of an object - tells you the distance to that object. Two other key components of the HUD are in the lower right hand corner - weapon cooldown and total ammunition in relation to clip size. Pressing escape will bring up a menu that lists all players in the game as well as the ability to logout / leave the match.

In game screenshot of a match

Finally, I added some visual fidelity to the combat by add damage effects. The damage effects of ships takes place when a player reaches 30% or less health and then again at 10% or less health. Right now it is some simple particle effects of fire and smoke.

I will also be hosting Alpha testing at 5 PM (Central Time) today, so if you want to join in please leave a comment on this blog and I will get you the required information.

Massive Game Overhaul

I spent most of today and last night going over the game and overhauling a lot of the features and the UI for the game. There are some massive improvements to all the scenes as well as textures for our ships now. Here is a list of all of the improvements made:

• Remote Players who connect to a game no longer have oddly rotated ships.
• Colliders for both the remote players and the client player are now properly oriented.
• Users can now join games that were created earlier that their login time.
• Scrolling view for all of the current games queuing.
• Uniformed GUI re-sizing for various resolutions. (minimum 1024px wide)
• Updated visual effects for space ships
• Better feedback when registering.

If you want to start a game, leave a comment and follow the link here to play the web player version of the game: Starbound Aces Game

And here are snapshots of the new ship models by Valentin Oprea:

Player Ship 1 - Texture

Player Ship 2 - Untextured

Game Persistence Implementation

For the past week I have been going over a lot of my school project code and figuring out what core gameplay elements still need to be added in regards to the server. If you have been keeping tabs on the github project, you can see that a lot of it was fixing code that caused errors as well as adding data persistence to the server engine.

Let us talk about the first issue at that I ran into and fixed this past week. The issue was players trying to log in twice. This was something simple to fix, remove the request to log in. Well, this caused the client to not know it was logged in and therefore I reverted that change. The second issues was automatic room removal. rooms where not being removed properly as they caused exceptions to be thrown. Turns out it was the extension's overriden destroy method causing the issue. This I found strange because the tutorials said that if I implemented the login assistant component, I needed to call the components destroy method in the extensions destroy method. Well, I removed that and have thus far to receive errors since then.

Onto the fun part now. I have added a full, new feature to the game. This is a game list that pulls up games created during your session as well as queued games created while you were picking your nose and not logged in to our game! This is very exciting as it allows for a whole list of data to be populated in the game list field. It also works, right off the bat! Unfortunately, I do not have the new Webplayer out there for the public to play just yet, but I do have all source code for it at our repository, so take a look there or even download/checkout the project and build it from source.

The final installment that I worked on in the past week was all GUI systems for the pre-login stage. Most of it was just a design change as they are using our common template. This is taking some time because I have never used Unity's built in GUI system and did not code for GUISkins. So most of the styles are hand configured and have their parameters set in the editor through public properties.

I am not sure when, but soon I will have a new game play video out as well as a walk through of all the new features. After that we will have the new player available for playing on the web. I also plan to do a desktop build as well. But first I will need to revamp the GUI for the lobby as well as the high scores.

Until next time!

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.

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 / SmartFox Senior Project Update

Starting early today in regards to programming.

I just finished implementing the high scores page and the server logic for getting the high scores as well as the player score.

This work went along smoothly. Server side, the code just required an extra request handler in the multihandler. Then I added a method to the DBService class. As a note, the DBService class is a utility class with static members. Personally, this is not how I usually go about utilities, but this is C# and Java land.

The client does all of the visual work. It requests the high scores and the current player's current score. It then renders this to the screen using the OnGUI event. Other than that, not much else is done, data is only ever received, not sent.

The impact of this is that it is the first step to giving players a drive to play. Giving a reason for the player to care about our game is the driving force to having a successful game. The goal of Starbound Aces is to offer an action packed competitive game. A scoring system is the first step in doing so.

I will be working on some effects stuff for the rest of the day and make a video to post on YouTube at my channel. When we have some models, I will also find someplace to put the Web player so that every body can enjoy a game or two.

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.

Starbound Aces Registration Complete

Whew! What a few days it had been.

I have finally finished the custom sign up component configuration and the server/client code.

The final configuration code sets up the servers configuration to relate to database tables. Originally I was getting an exception thrown due to a weird issue. The SFS (SmartFoxServer) SignUpAssistant was, it seemed, looking at the first column and automatically assumed it was the id column. It assumed it was also of a 32-bit or 64-bit integral value. Well, that was wrong for my database. It was, by mistake, made with a first column of type char var. I quickly remedied this by dropping the table and re-creating it. This resolved all issues I had with both the SignUpAssistant and LoginAssistant components.

Client side the code could not have been simpler. In fact, in regards to the login assistant, I changed nothing. As far as the sign up component, I explained the process in my last post.

When I finished the sign up and login component extensions I went about implementing our server-side game driver. This is the next step in my part of the project.

The game is somewhat represented server side. It contains a lot of the data of current games in memory. For instance, the players, the ships, and the weapons attached to the ships. It also keeps track of player scores. Considering that this game's main focus is on competition and the scores are a large part of that, I thought that keeping the scoring system entirely server side was a good idea. During games, players rack up points, then when this game is over, the server exports and aggregates this score to the player's persistent database row.

On another note, we have music! So next video you will get to hear that. I am very exciting about finishing this project and continuing on at the rate we are. Check back soon for more updates!

Unity Senior Project Update

Over the past two days I have been working on deploying my database to our server and writing code for the client side so that players can register and log in.

The database deployment went smoothly with little hick ups. The code on the server extensions; however, are causing some issues. The SmartFoxServer LoginAssistant and SignUpAssistant are a bit different than I anticipated. Both of these classes expect several parameters when it comes to registering and logging in a user. A lot of these parameters are the database column names and the database column data types. The names are an easy fix by simply calling getConfig() of each of the class instances. The difficulty is that I could not find a reference - in a quick search - to the datatypes each of these columns should be for the Login and SignUp assistant classes. I am going by what the server spews out as errors.

Client side everything has gone smoothly as I can see of right now. The reason I give this little disclaimer is that the client side code can't really be fully tested until the server side code is finished without errors. Right now I have some new GUI code up using the Unity OnGUI event method. I have a new level and script for registration. It is pretty simple, it calls a C# class instance of SmartFox, then calls the SmartFox send() method, finally, it sends the ExtensionRequestion for '$Signup.Submit' server side.

"$SignUp.Submit" is a SignUpAssistant command. The reason it is done this way is that the SignUpAssistant class is treated much in the same way of a multihandler extension class in SmartFoxServer. This is explained in depth here. But in short, a mutlihandler allows you to give it an identifying string for requests to be sent to. Then, there is a period, the second command that the extension will handle. Think of this as a call to a class method.

What I have found out is that the data being sent to the server in the SFSObject on the C# side needs to match the column names set in the SingUpAssitant.getConfig() calls. So, for instance, the SFSObject needs to put in the UtfString with the parameters ("user_name", username) if the SignUpAssistant username field column name is defined as "user_name".

So far, I am having some issues with matching the datatypes that SmartFox's SignUpAssitant expects on my SQL tables. But, I am moving along and soon players will be able to create their own accounts. Then they will be able to log in with those accounts and play.

Return from the North

Alright, so my short vacation is over and I have had plenty of time to think over these projects of mine. It has also given me some ideas on how I structure these posts. For instance, a while back, when first started, I was going to structure these posts in a design and technical way. So for now on I will stick with that - the first section will be the design processes behind the projects, then the second part will be the technical aspect of my projects. Hopefully this will lead to some well structured posts - rather than long ramblings about my work!

Unity Project

Okay, so let us start on where we plan on going forward with our Unity Senior Project. This week we are creating a Project Plan (PP) and finishing our Technical Design Document (TDD).

 As far as the PP goes, we have a small schedule of work listed out in our TDD draft. With a group of four, we are planning on dividing the work amongst ourselves based on our talents. We will have two people doing the scripting/programming, a sound artist, and a 3D modeler/graphic designer. Hopefully this will lead to efficient workflow and keep us from stepping on each others' toes.

The TDD draft did excellent in our class and really does not need much work for the rest of the course. A lot of the sections (graphics engine, physics engine, messaging system, etc.) relates directly with the Unity game engine. So as far as that is concerned, check out Unity's website to see the technologies they utilize in their game engine ( https://unity3d.com/ ).

Right, so we have covered and overview of a small design aspect of the game. Let us move over to some of the technical parts.

Before I left for vacation I had put up a simple demo video of some raw gameplay based on our networked games. So far we are able to connect to a server running SmartFox, login as a guest, chat, and play a simple game. How is this all accomplished with Unity and SmartFox? Well, SmartFox has a lot of excellent examples on thier website; however, they are examples on what to type in order to get something working. Here, I have a fully applicable, designed solution, to how this is all working.

There are two core design patterns at play with our implementation of the server interaction client side. So for now, I will be discussing the Unity (client) side of things in regards to how we designed our game. I urge you to download/checkout our source code to be able to follow along. ( https://github.com/hollsteinm/GSPSeniorProject ) 

Alright, so let us get started.

The two core design patterns we utilized our game so far are the Observer pattern as a messaging system and the Singleton design pattern. There are several reasons we chose to go with these patterns. These reasons are for connection stability, control, and decoupling.

First, we chose the Singleton pattern for connection stability. A client should ever have only one connection to our server. The paradigm behind the Singleton pattern is to offer a global point of access (the instance invocation) and ensure only one instance of the object exists ever. Now, there are plenty of arguments for and against the Singleton pattern that I will not discuss here. But it is with great consideration that I decided to utilize this pattern. 

We will also notice, when looking through the source code, that both the SFSClient and DummyClient are both singletons as well. This was not necessary and I will actually be re-factoring this later. 

Why is it not necessary? Well, besides the GameManager being the Singleton in the game, that persists across scenes, it will act as a Toolbox. A Toolbox is a concept I read about from IBM. It is essentially a Singleton that allows access to other system controllers (managers) that would have otherwise been Singletons as well. It prevents a mass amount of Singletons being created, and allows one point of access to each instance inside of the Toolbox. For more information on the Toolbox, here is the link: https://www.ibm.com/developerworks/library/co-single/. Long story short, a Toolbox is an aggregation of Singletons.

Right, let us move away from this distraction back to the topic at hand. 

The second reason we went with these patterns are control. Unity may have its own messaging system and what not for broadcasting to other objects and nested objects, but we needed something we could control in our scripts. Rather than randomly invoking some method, we wanted to create a decoupled way of having objects react to various server events. As of right now this is poorly implemented due to me. Right now there are only about five messages that the SFSClient notifies to registered observers. This is mostly because some of the messages from the server involve moving RemotePlayers or the ClientPlayer and relaying that information. However, there is one example that shows how this is intended to work and should be refactored to work.

In the project there are four interfaces put together to make the client speak with the server. These interfaces are the IEventListener (Observer), IEventMessenger(Observed), IClient, and IClientController. Each of these, with the exception of the latter, have methods that must be overridden by child objects. The reason for, as mentioned before, decoupling. In fact, any event listener and client have no idea what the SFSClient or DummyClient are, they simply know what a IClientController is. Now, if this was C++ land, I would be continuing on to tell you about all of the performance implications of utilizing pure virtual functions and v-table look ups, but this is C# land, so we just don't give a shit. Moving on, let us delve into this pattern more with and example found in the source code.

Looking at ChatGUI, we can see that it derives from MonoBehaviour (as all Unity scripts must) and IEventListener. On top of that, the class also maintains a reference to an IClientController object. This reference is pointed to the GameManager's instantiated IClientController instance (remember the Toolbox?). This instance is different depending on what game mode we are going to do. There are two types, the SFSClient which is an IClientController and the DummyClient, which is a mock server connection class. Respectively, each one is instantiated for Multi-player and Single Player.

Right, so looking at IClientController, we can see it is an aggregated Interface, a child of both IClient and IEventMessenger. This allows for a server-listener model to be implemented. This keeps us from constantly polling for events. Rather, the IClientController reaches an eventable moment, and notifies all listeners. Such events, for this example, are a chat message.

Looking at ChatGUI again, we can see that it implements the IEventListener method Notify (as it must). Its arguments are a string and an object. The string is used to pass on what kind of message is being sent (this is simple on our environment because SmartFox uses the same type of String/Object combinations and HashTables/Dictionaries for passing data around. The object is arbitrary data that is sent to the listener. Now, there is a concern here that I will go into detail with. This concern is Type Safety.

For those who don't know (mostly beginners) you can throw around arbitrary data and classes around in C# by having, as a parameter, an object. Because all classes and primitives in C# implicity are children of the object, anything can be sent as a parameter to a method. This saves time and programming logic by not having to utilize massive amounts of polymorphism for every single possible case of data passed, if it is not relevant to the object implementing the interface.

For a local example, look at IEventListener, now imagining all possible combinations of string-object parameters to be passed. Well, we would have string plus all primitives (string, float; string, int; string, float[]; etc.) and of course all classes we have. What, so, if IEventListener knows about all objects in the game, then all children know about all objects in the game, now we have a serious case of coupling. So, we pass arbitrary data. However, that is a problem with this as well, arbitrary data.

The problem with this is that we have no control over what data is given. So we could have the message type sent to the ChatGUI be of type "charmessage" but the data passed as an object could be a float value. However; the ChatGUI on a message type of "charmessage" is expecting a string type. We can see how this can cause an issue now. Luckily, in C# we can call the typeof method to instill type safety in our methods. 

Now, we have not done this in the source code as of yet. It is something that needs to be implemented. This could be done using exceptions or just early returns.

As we can see, by implementing Singletons and the Observer pattern we were able to accomplish several ideas. These ideas were to work towards connection stability, control, and decoupling. By using interfaces we were able to implement these ideas and maintain a system that is significantly decoupled. It utilizes several well known design patterns to accomplish this.

GameMaker: Studio GML GUI Scripting

I have to start off with this post that I am somewhat disappointed by the in game Graphical User Interface found in GameMaker: Studio. I understand that it is not a powerful engine like Unreal or idTech4 - but it goes without saying that there is more to a GUI than how it is rendered.

This is exactly how GM: S looks at it. The GUI is strictly a render-able object overlaid the rest of the view and bound to screen coordinates. It does not however; have any other aspect of the object, move with these traits. What do I mean by that?

Well, the collision mask (used by mouse click/enter/leave/etc. events) still stays in world-coordinates. Or in GameMaker terms, room coordinates. So if you have an object created at 0,0 and render itself in the Draw GUI Event, it will render with the center at the top left corner. But the collision masks will be place at the top left corner of you room. This was not the solution to using my shop UI.

Many suggested transforming the mask to the image per-step. Well, with that being said, you might as well as transform the whole thing. This then removes the need for Draw GUI and everything works as it should. So, what does this teach me? Two things:

1) Draw GUI Event is only for render only objects.
2) GameMaker: Studio needs better support for screen space coordinate UI features.

If anybody was wondering, here is the code to render and object consistently in view at a 'fixed point' (in relation to a view).

[In the Step Event]
if(close){
    instance_destroy();
}

x = view_xview[0];
y = view_yview[0];

for(i = 0; i < 4; i++){
    btn[i].x = view_xview[0] + 64;
    btn[i].y = view_yview[0] + 64*i + 32;
}

The btn array is a reference to buttons that occupy the shop UI. This way, one object manages all related instances.

The part that should be focused on is the following:

x = view_xview[0];
y = view_yview[0];

In conclusion, GameMaker: Studio is a good engine and I enjoy using it; however, it feels lacking in some features that require needless workarounds. But, I will continue developing in it.

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!