Last night I had the time to work in the Unreal Engine 4, as I have finished a lot of my Senior Project. I do have a few comments about it in regards to the C++ Programming. They can all be summed up in one word though - Smooth.
Indeed, the C++ programming is a smooth process once you understand the patterns and design of the system itself. Knowing C++ definitely helps too. For instance, yesterday I began implemented my own Inventory system derived from the one found on the Unreal Wiki. It when all as planned with only a minor hick-up in having no support for Unions as a UPROPERTY (So it can be seen and edited in the Visual Scripting Engine - Blueprints).
The ability to program in features with the ease of Unity and its managed scripting engine and the performance of C++ makes me very attracted to using this new engine. Having access to the source code also helps with understanding the core components. I also find that the unity website, wiki, and forums have a wealth of knowledge to start with. Finally, the free games and demos I can download from Epic aid in understanding the system even more.
I am sure I have mentioned before I was never a fan of UDK, so I was a little hesitant to begin with UE4; however, I am glad to be spending the measily $20.00 for this awesome engine and I plan to keep on using it. There are also some nice community works in progress underway such as an Adventure Kit.
Oh, and don't even get me started on how EASY it is to do multiplayer games in UE4.
Decided to share my thoughts and tell you that getting Unreal Engine 4 is worth it!
The Rand() posts of a growing software engineer. Mostly about game programming, old college stuff, and some fun side projects. Comments, discussions, and games are greatly encouraged!
Wednesday, May 28, 2014
Tuesday, May 27, 2014
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!
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:
-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!
Labels:
C#,
Client,
DeVry,
Game,
Game Development,
GUI,
Java,
Senior Project,
Server,
Smart Fox Server,
Starbound Aces
Wednesday, May 21, 2014
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:
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.
Labels:
Client,
DeVry,
Game,
Game Development,
GUI,
Java,
Senior Project,
Server,
Smart Fox Server,
SQL,
Starbound Aces,
Unity
Tuesday, May 20, 2014
Spit and Polish
Its that time of the year again. Spring, everything is clean. Everything that is, except for my code and our project.
It seems that with the rapid development we have been going through, the code has gotten a little messy and non critical errors are leaking through to show themselves in our final product. With only five more weeks to go, we need to fix this and get a nice, clean, game up and running. That is what I have devoted my past few weeks to - cleaning code, cleaning game play, and implementing some necessary features.
Soon, I will have a video up to show all the new features and game play for you to see. I know I keep promising it, but as all programmers/software engineers know, the coding is never done.
Until next time, enjoy!
It seems that with the rapid development we have been going through, the code has gotten a little messy and non critical errors are leaking through to show themselves in our final product. With only five more weeks to go, we need to fix this and get a nice, clean, game up and running. That is what I have devoted my past few weeks to - cleaning code, cleaning game play, and implementing some necessary features.
Soon, I will have a video up to show all the new features and game play for you to see. I know I keep promising it, but as all programmers/software engineers know, the coding is never done.
Until next time, enjoy!
Thursday, May 15, 2014
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:
And here are snapshots of the new ship models by Valentin Oprea:
Player Ship 1 - Texture |
Player Ship 2 - Untextured |
Labels:
C#,
DeVry,
Game,
Game Development,
GUI,
Java,
Senior Project,
Server,
Smart Fox Server,
SQL,
Starbound Aces,
Unity
Wednesday, May 14, 2014
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!
Labels:
C#,
DeVry,
Game,
Game Development,
GUI,
Java,
Senior Project,
Server,
Smart Fox Server,
SQL,
Starbound Aces,
Unity
Wednesday, May 7, 2014
Dumb Coders be Dumb
Today I have learned a very important lesson. This lesson is that in life, spelling, is of the utmost importance. Think about it, if you can't spell your own name, how will people know who you are? If we spelled cities differently each time, how would we navigate to Palo Alto or Aplo Aito? Well, even though computers are logical creatures, they definitely need you - the user, programmer, engineer - to know how to spell.
One of my issues, one of many of my issues, was caused by a simple misspelling. The stack trace told me where the error is. I thought I changed it, but when I uploaded it, I misspelled the directory, therefore leading me down the rabbit hole of "I swear I fixed that" and "I don't know why my code doesn't work."
I may have posted about this twice, but it is a stupid thing to do, misspell words. I really hope it does not befall you on your adventures in game programming.
Now for some real updates. I have finally fixed the code in the Client application to properly display names of users in a game that the player joins. This issues was brought on by how Unity loads levels and some shuffling of code.
If anybody has taken a look at the source code they would know that when a player joins a room, the game manager is prepped with a queue of players who are already in the room, or are joining the room. It supplies the script with both the player's name and the player's id on the network. If the queue is filled, it will copy this data to a new dictionary and iterate over this to put the relevant data in an instantiated object in the game and put it in the player dictionary.
This method worked fine, until player names were not showing up and they had to be added in the update method when the client received a foreign transform message. The instantiation turned out to be happening before a level fully loaded and so was creating players in the previous scene in Unity, and destroying them. This meant they existed, but then didn't exist at the proper moment.
I fixed this by only allowing the queue to be emptied in the multi player or single player scenes. Now the player names and ids are displayed properly and data is passed back and forth without incident. I also set the labels for names to clamp to the view port. This will prevent players from seeing a name of a player who is actually in the opposite direction. It will also now act as sort of a radar on the HUD. I like it, but I need to see if other players enjoy it as well.
Next I will be fixing one last server issue in which multiple death notices go out when a player dies, leading to a whole flood of errors.
Until next time, enjoy game programming and check out the revised version on my google drive.
One of my issues, one of many of my issues, was caused by a simple misspelling. The stack trace told me where the error is. I thought I changed it, but when I uploaded it, I misspelled the directory, therefore leading me down the rabbit hole of "I swear I fixed that" and "I don't know why my code doesn't work."
I may have posted about this twice, but it is a stupid thing to do, misspell words. I really hope it does not befall you on your adventures in game programming.
Now for some real updates. I have finally fixed the code in the Client application to properly display names of users in a game that the player joins. This issues was brought on by how Unity loads levels and some shuffling of code.
If anybody has taken a look at the source code they would know that when a player joins a room, the game manager is prepped with a queue of players who are already in the room, or are joining the room. It supplies the script with both the player's name and the player's id on the network. If the queue is filled, it will copy this data to a new dictionary and iterate over this to put the relevant data in an instantiated object in the game and put it in the player dictionary.
This method worked fine, until player names were not showing up and they had to be added in the update method when the client received a foreign transform message. The instantiation turned out to be happening before a level fully loaded and so was creating players in the previous scene in Unity, and destroying them. This meant they existed, but then didn't exist at the proper moment.
I fixed this by only allowing the queue to be emptied in the multi player or single player scenes. Now the player names and ids are displayed properly and data is passed back and forth without incident. I also set the labels for names to clamp to the view port. This will prevent players from seeing a name of a player who is actually in the opposite direction. It will also now act as sort of a radar on the HUD. I like it, but I need to see if other players enjoy it as well.
Next I will be fixing one last server issue in which multiple death notices go out when a player dies, leading to a whole flood of errors.
Until next time, enjoy game programming and check out the revised version on my google drive.
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.
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.
Labels:
DeVry,
Game,
Game Development,
GUI,
Java,
Senior Project,
Server,
Smart Fox Server,
Starbound Aces,
UI,
Unity
Monday, May 5, 2014
Unity Senior Project Update
I decided to get cracking at fixing some issues that were left over from the last half of my Senior Project. The issue was players were trying to join rooms twice when going into the lobby. Turns out it was just bad programming on the client side. Mistakes happen.
Now I need to fix the final issue on the server which is a null pointer exception being thrown by the Bitswarm socket reader when the last player leaves a room. I am thinking it may be protocol related in regards to data trying to be read from a socket. Not one hundred percent sure, but that will be my goal to finish tomorrow.
Sorry for the lame update, but there really isn't anything cool to show when working strictly server-side.
Now I need to fix the final issue on the server which is a null pointer exception being thrown by the Bitswarm socket reader when the last player leaves a room. I am thinking it may be protocol related in regards to data trying to be read from a socket. Not one hundred percent sure, but that will be my goal to finish tomorrow.
Sorry for the lame update, but there really isn't anything cool to show when working strictly server-side.
The Final Stretch
I knew this day would come eventually. The beginning of the end, as the cliche goes. Today marks the last eight weeks of my time at DeVry. With it, comes the closing hours of my Senior Project - Starbound Aces.
This week we will be spending time organizing data about Alpha gameplay reviews and comments to make some bug fixes as well as fleshing out the game. However, to be quite frank, any efforts to have unbiased third parties to test the game were a complete, miserable flop. Any attempts - on two forums and a couple of social media websites - resulted in only one comment in regards to the game. Thankfully, there are some close friends and allies who were able to play the multiplayer version of the game with me and give some feedback.
Most of the feedback was as follows:
-How do I x?
-Where are you?
-Am I flying?
Indeed, a lot of that is just questions. Which means there are some things in the game that need fixing. First off, a help menu for those who don't know how to play. I spent too much time assuming that people playing would have a natural assumption of 3rd person PC gaming controls. That was ignorance on my part. Secondly, the movement/camera scripts need and overhaul in regards to the actual gameplay. This is the task of the other programmer on the team. Finally, fixing the player name displays to be locked on viewport will give players an idea where other players are at in regards to the game world. Space is too big to hide player names by not locking them to the viewport. A later screen shot will show what I mean by this.
Until next time, enjoy your game programming, because I certainly will - until it doesn't works when it was working before and I have no idea why so I just restart my computer hoping that will fix the issue but that obviously wasn't the issue because it turns out to be some stupid thing I did late at night when I was obviously too tired or drunk to remember doing it and sure I thought it was a cool thing to add into the game but it clearly wasn't a good time to put it in and of course I forgot to commit my latest changes and I already saved and closed so there is no mercy in the Ctrl+Z department which I think is stupid but oh well that is how it goes and it turns out to be that I overrode a method in a class and so the base class was not being called so really the big issue is stupidity and one line of code then that is when game programming is not enjoyable but I still enjoy it anyways.
This week we will be spending time organizing data about Alpha gameplay reviews and comments to make some bug fixes as well as fleshing out the game. However, to be quite frank, any efforts to have unbiased third parties to test the game were a complete, miserable flop. Any attempts - on two forums and a couple of social media websites - resulted in only one comment in regards to the game. Thankfully, there are some close friends and allies who were able to play the multiplayer version of the game with me and give some feedback.
Most of the feedback was as follows:
-How do I x?
-Where are you?
-Am I flying?
Indeed, a lot of that is just questions. Which means there are some things in the game that need fixing. First off, a help menu for those who don't know how to play. I spent too much time assuming that people playing would have a natural assumption of 3rd person PC gaming controls. That was ignorance on my part. Secondly, the movement/camera scripts need and overhaul in regards to the actual gameplay. This is the task of the other programmer on the team. Finally, fixing the player name displays to be locked on viewport will give players an idea where other players are at in regards to the game world. Space is too big to hide player names by not locking them to the viewport. A later screen shot will show what I mean by this.
Until next time, enjoy your game programming, because I certainly will - until it doesn't works when it was working before and I have no idea why so I just restart my computer hoping that will fix the issue but that obviously wasn't the issue because it turns out to be some stupid thing I did late at night when I was obviously too tired or drunk to remember doing it and sure I thought it was a cool thing to add into the game but it clearly wasn't a good time to put it in and of course I forgot to commit my latest changes and I already saved and closed so there is no mercy in the Ctrl+Z department which I think is stupid but oh well that is how it goes and it turns out to be that I overrode a method in a class and so the base class was not being called so really the big issue is stupidity and one line of code then that is when game programming is not enjoyable but I still enjoy it anyways.
Labels:
C#,
Client,
DeVry,
Game,
Game Development,
Senior Project,
Server,
Smart Fox Server,
Starbound Aces,
UI,
Unity
Thursday, May 1, 2014
Unreal Engine 4
Yesterday I purchased a subscription license for Unreal Engine 4. I have to say, it is great that they offer the full source code as well as the ability to build the entire engine. On top of that, after only two hours of playing around in it (including checking out, downloading, and compiling) I am in love.
I have used Unity 4 for the better part of two years now. Mostly was because of the ease of use of the scripting languages in C# and (not-really)JavaScript. This simplicity beat out the UE3 scripting language. But now, it is a whole new game.
UE4 allows for building new game objects directly in the C++ source code. This is amazing! Especially when considering that it links it to their Blueprint Visual Scripting engine. I think I will find myself working mostly in UE4 from now on - while I still get the hang of it.
With that being said, I will still be posting about Starbound Aces starting next week as it will be my last 8 weeks of class before I get my B.S. in Game and Simulation Programming.
Here is a link to Epic Game's Unreal Engine 4 - its worth it! Check it out!
https://www.unrealengine.com/
I have used Unity 4 for the better part of two years now. Mostly was because of the ease of use of the scripting languages in C# and (not-really)JavaScript. This simplicity beat out the UE3 scripting language. But now, it is a whole new game.
UE4 allows for building new game objects directly in the C++ source code. This is amazing! Especially when considering that it links it to their Blueprint Visual Scripting engine. I think I will find myself working mostly in UE4 from now on - while I still get the hang of it.
With that being said, I will still be posting about Starbound Aces starting next week as it will be my last 8 weeks of class before I get my B.S. in Game and Simulation Programming.
Here is a link to Epic Game's Unreal Engine 4 - its worth it! Check it out!
https://www.unrealengine.com/
Subscribe to:
Posts (Atom)