Community Feedback for Text-based Adventure Game

I am in need of some verbose feedback in regards to my online game that I created. There are various sections of the game and the website of the game that I am looking to receive feedback on. These sections are the game itself, the game manual, website layout/design, and further suggestions.

If you would like to stop reading and just go ahead and play, here is the link:http://adventuregamequest.azurewebsites.net/  
Before I continue to explain what I am looking for, I would like to explain the project a little as well as the roadmap I have planned out for myself. What I would like to explain is the game itself and its inspiration. Secondly, I will discuss the roadmap of where I am at and where I wish to go.

In regards to the explanation of the game I have two main topics I would like to point out. These topics are the game itself (as in gameplay) and the inspiration behind the game.

First, the game is a text-based adventure game. You, like I did so many years ago, probably just threw out all interest in playing the game. That is fine, we all have different tastes and you aren't forced to continue reading. For those who wish to know more, here is a high level overview. The game is built to be played online and semi-competitively. There is a ranking system based on your adventures that tracks relics you collect, areas you explore, and monsters you fight. It includes a simple achievement system that auto-brags for you what you are doing. I plan on adding inter-player communication and a quest system. Finally, as most indie games/small projects have these days, I plan on adding random gameplay to the mix. What I mean by this is random quest generation (for smaller quests) and random dungeons (tried and true). I will stop here as it is getting more into my roadmap, so I will now discuss with you the inspiration behind such a game.

What is the inspiration behind this game? Well, to be honest, as I stated on my blog - enjoy-game-programming- I did it because I could and was in training to use new libraries, technologies, platforms. Ultimately, I say, it was because I could. However, it grew to be more than that. As I progressed I kept getting new ideas and drive to keep going. I had an idea of a world, a story, gameplay elements, and friendly competition between players. I also new that working on this part time with no artistic skills would be a huge roadblock. So I stuck with the KISS model. I kept it simple and focused on what really makes a game - a medium to tell an interactive story from the designer to you.

Yes, awesome effects, epic music, and slick graphics help with that story telling - I will admit that. However, I wanted to delve into the deeper parts of a game, to create something that gives real drive to keep playing, not just a firework show for the eyes and hears. A game where people think, where the gamer is not treated as a gigantic wallet awed by cheap tricks. Where the game is created with a tight gameplay system and well balanced mechanics. This is where you come in and the reason behind this announcement. I am looking for people to play and give feedback and it would be much appreciated. "This isn't my first rodeo", I have gone to other communities for other projects to receive feedback. I am no stranger to criticism or direction. If you want to be brutal, be brutal. If you had a bad day and want to rip my game to shreds, do. I beg you, feedback is the most important.

Finally, the roadmap I have for this game. Right now I have all of the core functionality in place and is accessible to the player. There are a few features that I would like to add and then some other stuff to jazz it up. Here is a list to keep this short:

Gameplay: On Beta Finished

• Player chat for players in the same location
• Quest system
• Expanded world and story
• Better balancing
• Expanded npc roster.
• Non-combat npcs (monstly for giving quests)

Before Going Gold

• Users may pick portraits
• Background art based on location
• Revamped UI (hopefully with the help of the community That's you)

With that in mind I want to change direction from the game and the motivation behind it to what I am asking assistance for. Remember, what I am mostly looking for is feedback in regards to the game itself (broad overview), the game manual (is it understandable?), website layout/design (is it user friendly/intuitive), and further suggestions.

The first discussion point would be the game itself. I as this because my background and degree is mostly programming related work, I did not always focus my efforts on game design. I feel strongly that I know the theory well, but it is the implementation of various mechanics that I wish to receive feedback on. Such mechanics would be feedback from the game (is it descriptive enough, do you understand what it is telling you, is it appropriate?), balance, and do you simple just get the game. I mean, do you really get it.

Secondly, I would like feedback on the game manual. As this is a text-based game, there really wasn't much in the way of a smooth tutorial I could offer. So I decided with an age-old classic - the game manual. I explain all the commands available in the game and what sections of the HUD say and do. I also offer descriptions of various hints the game offers in regards to the HUD. What I am looking for here is if there are any sections that are not clear, missing, or should be replaced.

Finally, with the game being online, I would like to have a user-friendly website to host it on. Right now I would have to say it is pretty basic. I would love it if people with website design backgrounds could offer hints to make it better. Also, the UI for the game and its intuitiveness can fall into this category as well.

I would appreciate all of the feedback possible and here is a link to the website that the game is hosted on (the game name is a working title and WILL be changed):

http://adventuregamequest.azurewebsites.net/

Server Side Player Properties

An after effect of our server side overhaul is that the game now has a database full of ship, weapon, and projectile configurations. This means the server can pull data from there and send the properties to players upon game starts. In conjunction with the client side GUI to configure a ship, we have a good system going for multi-player games.

The only real issue was wrestling with the timing of script execution, construction, and threads. This caused some issues where the client was not updating its properties when the server sends the data due to the script not existing and therefore not listening for the event. When that happened, the event just disappeared. Unity does allow for script execution ordering but that would not have fit my case as the GameManager Singleton and the SmartFox Client Controller needed to send and receive events before, during, and after other scripts. Therefore, I rolled some code in the C# scripts to time events the way they would work with our system.

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!

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 Project Web Player

While I have no major updates for you, or a video, I do supply a link to the web player for our Senior Project. Wait... what? Want to play? Well, here it IS: Play Starbound Aces

Short, sweet, to the point. Leave posts to comment on the game!

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.