Sword of the Sorcerer

We finally reached the end. Our game is finally done for the semester at least. Seeing as how we were accepted to Steam and are a company technically. This was such a great experience learning about VR, Unreal, and just this team created an unbelievable experience. At the end I was jumping from sounds, to debugging, to menus and other UI elements. We had a lot of fun and this experience with UI was unbelievable.

At the end of the project we decided we had to fix the menus first. Although they all worked, there was an issue with the orientation. As I worked on fixing that I managed to make some menus stop appearing completely destroying the game. After a bit I realized, why not save the orientation of the original menu used to begin the game and apply that. Once that started our menus were consistently usable and appeared easy for the player to find.

While solving our orientation issue I was working on fixing the menu only showing up in front of the player once and the remaining wherever it spawned otherwise. I decided to fix it easily and just save the original position and apply it, after a silly mistake that worked perfectly.

The shield UI was updated a lot toward the end. At the end we had the letters all animated and the crystals animated while damage is taken it was hard work but worth it. Overall the application of everything has been interesting, but difficult and fun.shield

shieldDead

Advertisements

The Fox and The Dragon

So far this semester and technically for 2017, I have only had one game focused on for this blog. After a lot of work I am happy to discuss my other project. Right now a few of us are working on a small game targeted toward a younger audience. The idea is that the players will pick a fox or dragon at the start and begin their journey to save, rule, or ruin a kingdom. Choices have consequences and puzzles will pop up throughout as missions to give the player more involvement.

This game is one we discussed the previous semester and the idea of working together even earlier in efforts to have a nice game we’re proud of. Right now the idea is simple, a puzzle where the dragon will fend off enemies in order to keep others safe. The code behind it all is rather simple, first was the enemy.

Starting the enemies

So I have worked in Unity before, but the last time I had a few people around me who knew enough to help when I got stuck so I revisited it for this 2D adventure. Now the enemies were a little troubling to start since I hadn’t worked on AI to seek in quite a while. following the idea that the player would be stationary and the enemies would be coming it started out with a simple move to, or rather move towards. It worked and was enough I could test, but after a while I realized that this wasn’t enough. I needed to have the result of reaching the player and the enemy destroying itself when it happens for a fair attempt.

After these realizations my update went from one single line to enough to reach what we need. searchupdate

After that I moved on, but now with this puzzle or mini-game just about finished I realized one more aspect could improve this. Making each enemy a random color. This would keep the player in a clear mind that they were an enemy while waiting on the art and give some more variance to what a player sees each time an enemy appears.color-change

The only real struggle here was remembering the random for Unity colors was between 0 and 1.

Spawner Time

So the last time I used Unity we moved away from spawners since I had some issue with the logic of Unity spawning items. After the experience in Unreal and some more general knowledge the whole plan went by much faster. The spawner didn’t take much time and I was able to add in loading from a file. That part has been trickier just due to it not loading properly, but I have finally gotten it to a way it works well and will soon automate better than a switch for however many puzzles we have in one full game. The enemies spawn with a speed in a random range and this is going to be used to add even more to the puzzle experience.

Player

The player was by far the simplest thing although most likely the least efficient right now. I have thought of ways to improve efficency and will be implementing them as soon as time allows. Right now it locates any enemy on screen and will test how far they are. The time is minimal now, but more enemies means more time means this will be fixed at some point soon.

 

Up Next

We have a lot of plans for this game and hope to maybe even market it. The next step is the second puzzle type for the dragon and then starting on the fox options. For now This is what we have but it is running and we can officially demo it like we need to tomorrow.

Development Environments

First Experiences a.k.a Production 1 and Freshman Year

Through out my time at Champlain I had to work in a few environments for class whether or not by choice. It started with visual studio and after barely using that I was thrown into flash and ActionScript 3. I don’t want to particularly highlight that, but what I can say is at that I started to notice my adaptability to environments. By the time I first worked on a team I had gone through using ActionScript 3 with FlashDevelop and XNA in Visual Studio.

The first team we worked in flash again, but it was mostly FlashDevelop with a library called FlashPunk. To sum up the semester of flash it wasn’t easy, but I managed to work on two games that came out amazing and one that showed a lack of confidence hurts. The game that first went well still used FlashPunk and went well when we considered the time frame. The second one was pure flash and ActionScript, which made making it for mobile a little more difficult. Overall that game played out well too and even had accelerometer controls for the platformer section (which was my part).

Production 2: Where the Challenge Amped Up

That began a lot of things and the next year added more. I’m going to skip strait to our first game. Pictures are up all over this blog featuring some of what we did. We made a first person platformer with a slowdown mechanic. This team had a lot of ups and downs, but overall we made a great game. All of it was completed in about 12 weeks starting seriously from the third week of classes. The game was made in Unity, an engine which I had never even opened prior to this class. The game itself is simple, but considering the three week period I couldn’t touch it due to a potential design change, a lot was done in 9 weeks. Take in part the time, the new engine, and the sole programmer, it isn’t so simple anymore.

Download Escape Artist for Windows Here: Escape Artist Windows Zip

Download a Mac Build Here: Escape Artist Mac Zip

Capstone: We Did  A Lot In A Short Time

At this point the only other game I have really worked on was my Capstone game Cure. The premise garnered a lot of hope. Although we only got the semester to work on it, the idea was well thought out just missing pieces due to the time constraint. According to the class we had twelve weeks to make this game, my team had trouble deciding what game to go forward with and eventually decided on Cure. This time around I was once again the only programmer and once more in an engine I had never used before, Unreal Engine 4. We had 8 weeks or less, the time we really started still isn’t remembered clearly. Each week we had a major leap that the professors were impressed by, we weren’t going to let the time constraint hold us back. Overall the game came out well, even if we didn’t move forward. We realized recently the idea itself was huge and would have led to a lot of work either way where it may be better we didn’t wind up as one of the teams moving ahead.

Download Cure for Windows here: Cure