Well, after a long break I decided to get back to my Senior Project ( seeing as I have to anyways ).
I always do better with a plan and chose to plan out our combat system for the game. The game logic for the system itself would not be difficult. Being a simple game, each ship is given a simple laser weapon.
The weapon itself was not hard to add to the game. Being something that travels in a straight line and is as fast as light, I was able to implement a simple raycast and line renderer for the weapon. The raycast is called when the mouse button is pressed down and a line rendering component is awoken upon firing to give some visual feedback. All in all a simple system. If the player hits somebody, they gather some required information and that information is sent off to the server. From there, SmartFox handles sending the messages to the rest of the players.
As far as code goes, I was having some difficulty implementing some of the features of this component. It seemed a lot of it had to do with stupid mistakes and timing issues. For instance, remote players joining rooms were not being instantiated properly and caused plenty of Null Pointer Exceptions. This was my bane for a week.
I decided to add a queue when a new player was added to the room, as opposed to adding the remote players instantly. Then I would wait for the level to load before adding the players in in the OnLevelWasLoaded method. If the players were added after the client is in the room, they are queued and polled in the FixedUpdate method.
In the FixedUpdate method the count of queued players is checked, if there are any players, they are immediately added to the scene and their information filled out. They are then added to the remote players list.
After fixing all of these issues and correcting a lot of timings, I was able to continue on with the combat scripts. I added a simple script called Weapon, which in later iterations will be abstract to allow for well implemented inheritance to add different types of weapons.
Anyways, this script is small, sweet, and simple. It projects a raycast from the origin of the player. If it hits anything, it checks to see if it is another player. If it is another player, the damage that the client can do and the server id of the player that was hit is sent as an extension request to SmartFox. All players are then notified of this event. The notified players check to see if it is their Id that was sent. If so, their health is reduced by the damage that the original shooter causes.
In hindsight, the server needs to start picking up more responsibility. Once the development picks up, I will ensure this happens. The reason I am saying that the server needs more responsibility is that I can never trust the client. I need the server to determine whether a player is actually able to shoot and if they in fact hit the player that they said they did.
All in all, it was an okay day for development and I added a new feature. Being complete, I pushed the source code to the repository for all to see. I do acknowledge that it needs to be cleaned up and re-factored, but that will come with time, if there is any left.
Monday, March 31, 2014
Thursday, March 27, 2014
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.
Friday, March 21, 2014
Unity and Game Maker: Studio Project Videos
Alright, here it is! Proof, awesomesauciness. Videos of my current projects. They are raw, unedited, and totally interesting!
The Unity project shows another and I playing a networked game. We cannot kill eachother, but we can chase! You can see us chatting and some of the features I added. And before you say it, I know, I need to fix the camera snaps!
The Game Maker Project is also raw. No artwork added except for my own. It is meant to be an action filled came in terms of combat. However, there is the world exploration aspect in between combat.
The Unity project shows another and I playing a networked game. We cannot kill eachother, but we can chase! You can see us chatting and some of the features I added. And before you say it, I know, I need to fix the camera snaps!
The Game Maker Project is also raw. No artwork added except for my own. It is meant to be an action filled came in terms of combat. However, there is the world exploration aspect in between combat.
Well, I hope that these videos were somewhat enjoyable for you. I won't be able to update again until after I get back from vacation. But hopefully the relaxation will improve my coding efficiency when I get back.
Until next time!
Remember:
Senior Project Source: https://github.com/hollsteinm/GSPSeniorProject
Youtube Channel: http://www.youtube.com/channel/UC0OGFRSD6HOVkVDcHgz5LSw
Unity Networked Game, UP AND RUNNING!
Hey folks!
I am writing this because of several reasons. These reasons are that I wasn't able to post last night (like I had hopped), and because the reason I could not post has been resolved.
So last night, I spent a majority of the time fixing a bunch of issues with my SmartFox logic and Unity Scripts. Most of these issues were due to poor management and assigning of resources.
Let me start at SmartFox first. I was consistently getting java.lang.NullPointerExceptions due to an issue with how I am currently storing games. The way I am doing it right now is through a ConcurrentHashMap. Adding to it works fine, without issue, or so I believe. I will need to attach a remote debugger to see what is really going on. However, I do plan on fixing this by storing ANY persistent information in a SQL database. This is for several reasons. One is less memory is taken up as it no longer needs to have the server cache game data. Secondly, it maintains state. If for some reason the server went down in a the middle of a game, I will be able to pull information from those games and let players continue. I believe this is a good approach to go for.
Secondly in Unity, I had an issue in my script that only allowed the creator of a room to see other players. This is because I was adding players for the game in the GameManager class for only the event that handles users entering a room. I thought that the way SmartFox dealt with this was a little different. Right now I have a small injection of code that alleviates joiners of a game (not creators) from not seeing people in the room. However, it is not the proper way to do it and I will be fixing it. Basically, what I did that is wrong, is check to see if the player receiving the transform event is from a player already registered with the GameManager, if not, then create the player. First off, this should not be the responsibility of event messaging handling during regular updates. It is something that should be done on load. So I am seeking to find a fix for it.
Now, for a list of features that the game has over the network:
Right, that is a small update. I will be gone for the next week and will not have any new posts until then. However, *HOPEFULLY* tonight I will have videos of both of my projects for everyone to see - to prove that they are real and not a figment of my computer's imagination.
Check back soon!
I am writing this because of several reasons. These reasons are that I wasn't able to post last night (like I had hopped), and because the reason I could not post has been resolved.
So last night, I spent a majority of the time fixing a bunch of issues with my SmartFox logic and Unity Scripts. Most of these issues were due to poor management and assigning of resources.
Let me start at SmartFox first. I was consistently getting java.lang.NullPointerExceptions due to an issue with how I am currently storing games. The way I am doing it right now is through a ConcurrentHashMap. Adding to it works fine, without issue, or so I believe. I will need to attach a remote debugger to see what is really going on. However, I do plan on fixing this by storing ANY persistent information in a SQL database. This is for several reasons. One is less memory is taken up as it no longer needs to have the server cache game data. Secondly, it maintains state. If for some reason the server went down in a the middle of a game, I will be able to pull information from those games and let players continue. I believe this is a good approach to go for.
Secondly in Unity, I had an issue in my script that only allowed the creator of a room to see other players. This is because I was adding players for the game in the GameManager class for only the event that handles users entering a room. I thought that the way SmartFox dealt with this was a little different. Right now I have a small injection of code that alleviates joiners of a game (not creators) from not seeing people in the room. However, it is not the proper way to do it and I will be fixing it. Basically, what I did that is wrong, is check to see if the player receiving the transform event is from a player already registered with the GameManager, if not, then create the player. First off, this should not be the responsibility of event messaging handling during regular updates. It is something that should be done on load. So I am seeking to find a fix for it.
Now, for a list of features that the game has over the network:
- Public Chat messaging in Lobby and Game
- Up to 8 players in a single Game
- Display of player names over their respective "Ship"
- Programmer Art!
Right, that is a small update. I will be gone for the next week and will not have any new posts until then. However, *HOPEFULLY* tonight I will have videos of both of my projects for everyone to see - to prove that they are real and not a figment of my computer's imagination.
Check back soon!
Thursday, March 20, 2014
Unity Update for Senior Project
Today it is back to work for me and I won't have as much time as yesterday to get programming done. But, I do have some goals for today in regards to my Senior Project.
My goals are as follows:
I know what are causing these issues and I plan to fix them right away.
The issue of spawning directly causes the collision, so I will have the server generate spawn points for each player when they join a room. Secondly, the rotation viewing issue may just be due to sending localEulerAngles to the other player. I will switch it over to send rotations as quaternions.
Also, my updating is sending/receiving every frame, I need to add a delay to this. Perhaps - every 1/6th of a second.
However, I must escape work first!
After I have done all this, I will update here, and on the Unity WIP forum thread I have running found here: http://forum.unity3d.com/threads/235234-StarboundAces-(Senior-Project)
My goals are as follows:
Server-Client Interaction
As it stands right now, the server takes and sends the players transforms in regards to position and rotation and sends it to the other players. It also spawns all players at 0, 0, 0. This leads to two weird effects that I need to take care of. These effects are players being ejected due to collision boxes and remote players' object rotating the farther it gets from the player.I know what are causing these issues and I plan to fix them right away.
The issue of spawning directly causes the collision, so I will have the server generate spawn points for each player when they join a room. Secondly, the rotation viewing issue may just be due to sending localEulerAngles to the other player. I will switch it over to send rotations as quaternions.
Also, my updating is sending/receiving every frame, I need to add a delay to this. Perhaps - every 1/6th of a second.
Display Names
Wouldn't it be nice to see who you are playing? Well, I will send the players' names to each person they are in a game with. This will be a simple, but nice, and common, feature.Lobby Chat
Yet another simple feature to add. I will allow for players to communicate with eachother via text chat. For the first revision there will only be a public room for chatting and everyone can see everything. Also, there will be a world filter.However, I must escape work first!
After I have done all this, I will update here, and on the Unity WIP forum thread I have running found here: http://forum.unity3d.com/threads/235234-StarboundAces-(Senior-Project)
Wednesday, March 19, 2014
Unity, SmartFoxServer, and GameMaker, OH MY!
Well, I set out to do a lot today and now that it is night I am done, and accomplished.
I will start with the less exciting news. I have made the enemies have the ability to attack the player in my GameMaker: Studio project. It was simple, reusing a lot of scripts from the player attack scripts. The workflow increases of reusable code is always a dream.
Now, for the more exciting news: I have deployed our Senior Project to a remote server and now anybody who downloads the source code and runs it in Unity will be able to connect to the server. If anybody is logged in when you make a game, they will see the games and be able to join it. Two players to a game right now. The only thing is that there is no actual game-play as of yet due to the multi-player room being nothing but a bunch of cubes moving around.
The total amount of work to get this done in one day was about ten hours. It was intense and I am so glad that I accomplished this. I know that just talking about it doesn't help people learn from what I have done so please, I urge you, poke around the code on the repository found here:
https://github.com/hollsteinm/GSPSeniorProject
To note, the core of the client model is found in the interfaces. These interfaces are IClient, IListener, and the combination interface of IClientController. I did this so that we could program one player object for both single player and multi-player. This is done by assigning a different server type when the player chooses a game mode. The code for that is found in LaunchGUI.cs. The core of the client messaging system for SmartFox is found in the ingeniously named SFSClient.cs file. I wrapped sending messages so that other developers in my group will be able to pick what message to send to the server for handling based on an enumeration of options. This was more or so done for ease of development.
All in all, it was a real good day for game programming today and I am excited to continue my work on both of these projects.
Oh, and UnrealEngine 4 came out today, so I am super excited to get a subscription and poke around the source code!
I will start with the less exciting news. I have made the enemies have the ability to attack the player in my GameMaker: Studio project. It was simple, reusing a lot of scripts from the player attack scripts. The workflow increases of reusable code is always a dream.
Now, for the more exciting news: I have deployed our Senior Project to a remote server and now anybody who downloads the source code and runs it in Unity will be able to connect to the server. If anybody is logged in when you make a game, they will see the games and be able to join it. Two players to a game right now. The only thing is that there is no actual game-play as of yet due to the multi-player room being nothing but a bunch of cubes moving around.
The total amount of work to get this done in one day was about ten hours. It was intense and I am so glad that I accomplished this. I know that just talking about it doesn't help people learn from what I have done so please, I urge you, poke around the code on the repository found here:
https://github.com/hollsteinm/GSPSeniorProject
To note, the core of the client model is found in the interfaces. These interfaces are IClient, IListener, and the combination interface of IClientController. I did this so that we could program one player object for both single player and multi-player. This is done by assigning a different server type when the player chooses a game mode. The code for that is found in LaunchGUI.cs. The core of the client messaging system for SmartFox is found in the ingeniously named SFSClient.cs file. I wrapped sending messages so that other developers in my group will be able to pick what message to send to the server for handling based on an enumeration of options. This was more or so done for ease of development.
All in all, it was a real good day for game programming today and I am excited to continue my work on both of these projects.
Oh, and UnrealEngine 4 came out today, so I am super excited to get a subscription and poke around the source code!
GameMaker: Studio Project and Unity Senior Project
All right, so this morning is going to be crazy as I have a lot of work to do and little time to do it.
Today, I have two goals in mind. These goals are to add combat logic to my Mystery Game made in GameMaker: Studio and to add networked player movement in my Unity Senior Project using Smart Fox Server X2.
The personal project a.k.a. Mystery Project/Game is coming along smoothly. But I have had issues fighting some distractions, like adding cool features and ridiculous enemies. I need to focus on finishing the basics. And what is more basic than AI combat? Being a small project there will only be three types of enemies that are non-unique. These enemies will be melee, ranged, and magic casters. This will also keep the art overhead low too. Considering that the world enemy AI logic is complete, I merely need to add combat in the battle arenas. (What does this all mean? You'll find out when I am ready to tell you).
As a side note, I also added combat between friendly NPCs and enemy NPCs. It is kind of cute, the enemies chase me and the friendlies chase the AI. Their combat is simple, a basic random roll of who wins. The friendlies have a 48% chance of winning (why let them do all the work) and - unlike the enemy monsters - they die permanently. Oh, and so do the civilians. This has a lot to do of what the actual game is about.
Moving on from the GameMaker: Studio engine, I have a current project in Unity for my Senior Project class.
The Unity project is pretty straight forward. We can fly ships around in a multi-player environment and blast each other in traditional FPS fashion. How is this all achieved? Well, I am working on the client-server software and have chosen to use SmartFoxServer X2 for our server software. Why? Well, extensions are easy to write in Java and it comes with the API for C#, which plugs into Unity without a hitch. Furthermore, I have worked with it before, and so am familiar with how to write the extensions, event handlers, and creating abstract wrappers for the client side. Then, I will deploy it to a remote server.
That is what I am trying to accomplish today (along with some boring reports) in regards to all of my game programming. I will soon have screen shots/videos from each of these projects so that one may feast their eyes upon it.
I will have updates by tonight.
P.S. if you want to have a look at my Senior project, both the client code and server code are on GitHub:
https://github.com/hollsteinm/GSPSeniorProject (just keep in mind to run the multi-player environment, you need to install and configure SmartFoxServer - soon you won't, but for now you do.)
Today, I have two goals in mind. These goals are to add combat logic to my Mystery Game made in GameMaker: Studio and to add networked player movement in my Unity Senior Project using Smart Fox Server X2.
The personal project a.k.a. Mystery Project/Game is coming along smoothly. But I have had issues fighting some distractions, like adding cool features and ridiculous enemies. I need to focus on finishing the basics. And what is more basic than AI combat? Being a small project there will only be three types of enemies that are non-unique. These enemies will be melee, ranged, and magic casters. This will also keep the art overhead low too. Considering that the world enemy AI logic is complete, I merely need to add combat in the battle arenas. (What does this all mean? You'll find out when I am ready to tell you).
As a side note, I also added combat between friendly NPCs and enemy NPCs. It is kind of cute, the enemies chase me and the friendlies chase the AI. Their combat is simple, a basic random roll of who wins. The friendlies have a 48% chance of winning (why let them do all the work) and - unlike the enemy monsters - they die permanently. Oh, and so do the civilians. This has a lot to do of what the actual game is about.
Moving on from the GameMaker: Studio engine, I have a current project in Unity for my Senior Project class.
The Unity project is pretty straight forward. We can fly ships around in a multi-player environment and blast each other in traditional FPS fashion. How is this all achieved? Well, I am working on the client-server software and have chosen to use SmartFoxServer X2 for our server software. Why? Well, extensions are easy to write in Java and it comes with the API for C#, which plugs into Unity without a hitch. Furthermore, I have worked with it before, and so am familiar with how to write the extensions, event handlers, and creating abstract wrappers for the client side. Then, I will deploy it to a remote server.
That is what I am trying to accomplish today (along with some boring reports) in regards to all of my game programming. I will soon have screen shots/videos from each of these projects so that one may feast their eyes upon it.
I will have updates by tonight.
P.S. if you want to have a look at my Senior project, both the client code and server code are on GitHub:
https://github.com/hollsteinm/GSPSeniorProject (just keep in mind to run the multi-player environment, you need to install and configure SmartFoxServer - soon you won't, but for now you do.)
Tuesday, March 18, 2014
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.
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!
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!
Monday, March 17, 2014
Game Maker Scripting for Mystery Game
Well, I spent most of the night scripting for the game and decided to share with people some of the Game Maker Language (GML) work that I am doing.
Right now by project is concerned with basic AI routines such as seek, flee, and flocking techniques. These techniques are easily to prototype using the Game Maker Language.
Seek routines are AI methods that have the Artificial Intelligence look for the player. This can either be to rotate towards (like a turret) or move towards (pretty much everything else). In a simple Finite State Machine - as I have implemented - the AI is typically given a sight range as a condition of 'seeing' the player. When the player or target falls withing this range the AI will start to move towards the target.
Flee routines are essentially the opposite of a seek function for Artificial Intelligence. The AI moves in a direction that is not towards the target. In my game, this is implemented by storing the original spawn {x, y} coordinates. When the player is outside of the seek range, and the AI is outside a certain "wander threshold" the AI will simply return to that spawn point.
Flocking is something that I never really dealt with before in working with Artificial Intelligence. This is mostly because I prefer other game programming areas such as rendering. But, it also has to do with the fact that other game engines used collision boxes and did not allow objects to overlap each other (like players in an MMORPG). This I dealt with by having the AI detect other objects near it. If there was, it would implement a separating velocity between itself and the other AI. This came in handy when many enemies were chasing the player. It prevented them from stacking.
In regards to AI, that is all I really had to do myself for my Mystery Game. Game Maker has some neat path-finding tools built in such as mp_potential_step_object() method. This allowed for easy terrain avoidance in a top down 2-D map.
Right now by project is concerned with basic AI routines such as seek, flee, and flocking techniques. These techniques are easily to prototype using the Game Maker Language.
Seek routines are AI methods that have the Artificial Intelligence look for the player. This can either be to rotate towards (like a turret) or move towards (pretty much everything else). In a simple Finite State Machine - as I have implemented - the AI is typically given a sight range as a condition of 'seeing' the player. When the player or target falls withing this range the AI will start to move towards the target.
Flee routines are essentially the opposite of a seek function for Artificial Intelligence. The AI moves in a direction that is not towards the target. In my game, this is implemented by storing the original spawn {x, y} coordinates. When the player is outside of the seek range, and the AI is outside a certain "wander threshold" the AI will simply return to that spawn point.
Flocking is something that I never really dealt with before in working with Artificial Intelligence. This is mostly because I prefer other game programming areas such as rendering. But, it also has to do with the fact that other game engines used collision boxes and did not allow objects to overlap each other (like players in an MMORPG). This I dealt with by having the AI detect other objects near it. If there was, it would implement a separating velocity between itself and the other AI. This came in handy when many enemies were chasing the player. It prevented them from stacking.
In regards to AI, that is all I really had to do myself for my Mystery Game. Game Maker has some neat path-finding tools built in such as mp_potential_step_object() method. This allowed for easy terrain avoidance in a top down 2-D map.
Side Project on the Way
So a couple of weeks ago I decided on creating a new project that would become a game.
I realize that going solo on making an actual game engine (more than rendering, physics, and collision detection) takes an enormous amount of time and effort. I would love to continue with building a game engine, but it is something I would need to be able to afford-ably work on full time.
So, back to the project. I plan on using a game engine that I already have a license for (from working with a previous developer). That game engine in Game Maker: Studio Pro. I have worked extensively in this engine and am familiar with the scripting language so I hope to produce a project rapidly.
However, I need artists, both for sound and art. This would be my limiting factor as of right now. To see a glimpse of the project, here are a few screen captures of the project with 'programmer art':
What are you seeing? Hopefully just blocks of colored squares, or I question your sanity. But, only time will tell.
If you want to see an earlier unfinished project, there is a link to the Game Maker: Studio Steam Workshop Community:
http://steamcommunity.com/sharedfiles/filedetails/?id=235864463
I realize that going solo on making an actual game engine (more than rendering, physics, and collision detection) takes an enormous amount of time and effort. I would love to continue with building a game engine, but it is something I would need to be able to afford-ably work on full time.
So, back to the project. I plan on using a game engine that I already have a license for (from working with a previous developer). That game engine in Game Maker: Studio Pro. I have worked extensively in this engine and am familiar with the scripting language so I hope to produce a project rapidly.
However, I need artists, both for sound and art. This would be my limiting factor as of right now. To see a glimpse of the project, here are a few screen captures of the project with 'programmer art':
What are you seeing? Hopefully just blocks of colored squares, or I question your sanity. But, only time will tell.
If you want to see an earlier unfinished project, there is a link to the Game Maker: Studio Steam Workshop Community:
http://steamcommunity.com/sharedfiles/filedetails/?id=235864463
Thursday, March 13, 2014
As Promised: Senior Project Discussion
Alright, so this weeks mark the second week into a 16 week project for my Senior year at DeVry. Soon, I will be graduating in June and I think I would like to share the project that we are working on with the rest of the world. So, here it is.
As far as we know right now (since we are in the midst of making a Game Design Document) the game that we plan on producing has a few features. These features would be some form of space combat and multi-player. The genre will most likely fall into some form of a 3rd person action game or first person shooter style.
What we know as facts is that we plan on using the Unity4 game engine for our client side application and SmartFoxServerX2 as our server side technology. This is all in regards to software.
On the hardware side of things I plan on using Amazon's elastic services for setting up a server. I have done it before during my brief time at EverFire and plan on doing it again - solo this round.
Oh, and for those who are technically inclined, the entire project is open on GitHub, so feel free to poke around!
https://github.com/hollsteinm/GSPSeniorProject
Brief, but sweet. Questions about this project are greatly appreciated, so feel free to ask in the comments below.
As far as we know right now (since we are in the midst of making a Game Design Document) the game that we plan on producing has a few features. These features would be some form of space combat and multi-player. The genre will most likely fall into some form of a 3rd person action game or first person shooter style.
What we know as facts is that we plan on using the Unity4 game engine for our client side application and SmartFoxServerX2 as our server side technology. This is all in regards to software.
On the hardware side of things I plan on using Amazon's elastic services for setting up a server. I have done it before during my brief time at EverFire and plan on doing it again - solo this round.
Oh, and for those who are technically inclined, the entire project is open on GitHub, so feel free to poke around!
https://github.com/hollsteinm/GSPSeniorProject
Brief, but sweet. Questions about this project are greatly appreciated, so feel free to ask in the comments below.
Tuesday, March 11, 2014
Reviving this Blog
It has been a long time since I have posted on this blog and I fee ashamed. So I will be continuing to post on this blog for now on with a goal of once a week. I also have a list of what I will be discussing in the near future. Today is just my promise to you that there will be more exciting content to discuss. So, here is a list of what I will be blogging about soon:
It all sounds so exciting, no?
- Multithreading strategies in C++
- Unity and my Senior Project
- Smart Fox Server X2
- C#
- Java
- Space
It all sounds so exciting, no?
Subscribe to:
Posts (Atom)