In addition to working on our semester-long projects here at the ETC, students also take at least one elective per semester. This semester I am taking Jesse Schell's Game Design course which so far has been both entertaining and educational! Our first project was to design a new and improved version of hopscotch, my version of which you can check out here. It's funny, even such a simple game as hopscotch has a lot of rules to keep track of. For my redesign, I put together a hybrid of hopscotch and sudoku called Hopsudoku to try and add a puzzle element and make the game more attractive to an adult audience. One thing I underestimated was the physical component. Hopping doesn't sound like a very strenuous activity but hopping for long enough during playtesting does get tiring!
Our second project was to write a list of at least 100 games we've played throughout our lives, listing at least three for each year we've been alive since we were five, and include comments about memorable parts of of each of their designs. You can see my list here. I did my best to avoid overusing sequels as long as I could, but had to break down and do so to fill in some problem years here and there. It was a very interesting exercise to go back and try and remember what stuck out the most for me over my gaming career, it might be fun to go back to it again at some point and try to make the list as exhaustive as possible and see how high a number I can get.
Saturday, February 18, 2012
ETC Semester Project - Spring Entertainment
So with the first semester and BVW behind me, I'm now moving forward as a member of the Spring Entertainment project team here at the Entertainment Technology Center. Spring Entertainment is a client project working for Seven Springs Mountain Resort. Our goal is to create an iPhone game that advertises the variety of experiences available to guests at the resort. You can read more about the project and follow our progress in our weekly newsletters available here.
Friday, December 9, 2011
On Stage at the Fall 2011 BVW Show!
Great news! Two of my teams' worlds from this semester's Building Virtual Worlds class were selected to be featured in the Fall 2011 BVW Show! Each year BVW students are allowed to submit worlds from any round to the BVW Jury for review, who then assemble a show from the best worlds to be put on stage in front of a live audience. This semester over 90 worlds were created, 60 were submitted to the jury, and fourteen of those were selected to be in the show! Here are clips from the show of the two worlds I was a part of. I was a performer on stage in both of them.
Mouse <3 Mouse (yes, that's me in the mouse costume)
Electro Techno Corps (playing the role of Captain Electro in the middle)
The entire show was a huge success! You can watch the whole thing online here:
mms://wetc-tv.etc.cmu.edu/
This marks the end of my first semester at the Entertainment Technology Center! Next up is a short winter break, during which I might find a little time to get back to work on Shining Force PC! After that the next semester starts in mid January which will be a whole new adventure working on a full semester long project as opposed to the short 2-3 week rapid prototyping rounds of BVW. I have to say that this semester has been the most exciting three months I can remember in forever! I've made so many great friends and had a wonderful time creating amazing things together with them! I only hope that the rest of my time here at the ETC will be this rewarding!
Mouse <3 Mouse (yes, that's me in the mouse costume)
Electro Techno Corps (playing the role of Captain Electro in the middle)
The entire show was a huge success! You can watch the whole thing online here:
mms://wetc-tv.etc.cmu.edu/
This marks the end of my first semester at the Entertainment Technology Center! Next up is a short winter break, during which I might find a little time to get back to work on Shining Force PC! After that the next semester starts in mid January which will be a whole new adventure working on a full semester long project as opposed to the short 2-3 week rapid prototyping rounds of BVW. I have to say that this semester has been the most exciting three months I can remember in forever! I've made so many great friends and had a wonderful time creating amazing things together with them! I only hope that the rest of my time here at the ETC will be this rewarding!
Monday, December 5, 2011
Building Virtual Worlds - Round 5 - Electro Techno Corps
The theme of Round 5 of Building Virtual Worlds is Its Showtime! Students are given one month and are tasked with building a world that is big on showmanship and spectacle with the goal of being featured in the Building Virtual Worlds Show at the end of the semester. Unlike previous rounds, students are permitted to form their own teams and pitch a concept to the professors or take the luck of the draw and be assigned to a random team like in previous rounds. I was placed on a random team and the world we came up with was a giant robot themed game called Electro Techno Corps (a pun on ETC.) The world is in the vein of saturday morning cartoons and the Mighty Morphin Power Rangers. Three performers share two Wiimotes and two nunchucks to pilot a giant robot against a mad scientist whose giant creations run amok in the city. The current video only has the game aspect of the world on display, if and when a version that also includes the live performers becomes available I will update this post. Update: a version with live performers is now online, check it out in this post!
Despite the large time frame, one of the major challenges of the round is time management and proper scoping of the project. Many teams reached too far and ended up having to scale way back or start over completely around the halfway point in the round. My team just barely managed to finish our world based on our original plan, which was way too close for comfort. I wish we would have cut one of the events early on and spent more time on polish, playtesting, and fine tuning, but thankfully everything worked out in the end.
One of the more interesting aspects of the project was using CityEngine to model the city rather than doing it by hand. Our texture artist, Anisha Deshmane, spent a lot of time in undergrad working with CityEngine and we were able to get the city modeled, exported to 3DSMax, trimmed down, and imported into Unity in under 2 days! It saved us a lot of time and effort and looked great in game, which let us spend more time and effort on other aspects of the project.
Despite the large time frame, one of the major challenges of the round is time management and proper scoping of the project. Many teams reached too far and ended up having to scale way back or start over completely around the halfway point in the round. My team just barely managed to finish our world based on our original plan, which was way too close for comfort. I wish we would have cut one of the events early on and spent more time on polish, playtesting, and fine tuning, but thankfully everything worked out in the end.
One of the more interesting aspects of the project was using CityEngine to model the city rather than doing it by hand. Our texture artist, Anisha Deshmane, spent a lot of time in undergrad working with CityEngine and we were able to get the city modeled, exported to 3DSMax, trimmed down, and imported into Unity in under 2 days! It saved us a lot of time and effort and looked great in game, which let us spend more time and effort on other aspects of the project.
Sunday, December 4, 2011
Building Virtual Worlds - Round 4 - Mouse Heart Mouse
Building Virtual Worlds Round 4 is the Storytelling round. Groups are given three weeks to build a world that lasts 3 to 5 minutes that tells a complete story. Students have two days to come up with and pitch two story ideas to the professors and the class and receive feedback from them. They then choose one of these ideas to build storyboards for, which are presented at the end of the first week. Over the next two weeks students build the world laid out in the storyboards.
My group’s story told the tale of a mouse who meets a computer mouse atop a desk in a messy dorm room while scavenging for food. The two fall in love at first sight, but are separated when the owner of the room returns and sits down at his desk and reaches for his computer mouse but grabs the furry mouse instead. Shocked, he flings the mouse away and runs from the room screaming. Our hero must find a way back to the top of the desk to reunite with his love, and then the two must find a way to escape the room and enjoy their freedom and their new life together.
My team this round worked exceptionally well together! We all really liked the idea we came up with and that lead to very good buy in from all the members of the team. Everyone made strong creative contributions to the project and we all worked very hard to make Mouse <3 Mouse a big success! One of the things that I believe greatly contributed to that success was our choice of platform, the Nintendo Wiimote. Since this was a small, simple piece of hardware, we were free to use it at our desks and we could playtest and iterate constantly unlike the rounds where I worked with the Kinect. Since the Kinects and televisions were in very short supply, teams had to schedule limited time slots to playtest and it was harder to get a feel on how the world plays and make adjustments when working with that platform. The freedom to playtest regularly on the Wiimote made it easier to fine tune the controls and left more time to polish the room and make it as lively and interactive as possible.
My group’s story told the tale of a mouse who meets a computer mouse atop a desk in a messy dorm room while scavenging for food. The two fall in love at first sight, but are separated when the owner of the room returns and sits down at his desk and reaches for his computer mouse but grabs the furry mouse instead. Shocked, he flings the mouse away and runs from the room screaming. Our hero must find a way back to the top of the desk to reunite with his love, and then the two must find a way to escape the room and enjoy their freedom and their new life together.
My team this round worked exceptionally well together! We all really liked the idea we came up with and that lead to very good buy in from all the members of the team. Everyone made strong creative contributions to the project and we all worked very hard to make Mouse <3 Mouse a big success! One of the things that I believe greatly contributed to that success was our choice of platform, the Nintendo Wiimote. Since this was a small, simple piece of hardware, we were free to use it at our desks and we could playtest and iterate constantly unlike the rounds where I worked with the Kinect. Since the Kinects and televisions were in very short supply, teams had to schedule limited time slots to playtest and it was harder to get a feel on how the world plays and make adjustments when working with that platform. The freedom to playtest regularly on the Wiimote made it easier to fine tune the controls and left more time to polish the room and make it as lively and interactive as possible.
Saturday, October 15, 2011
Building Virtual Worlds - Round 2 - The Pharaoh's Messenger
Building Virtual Worlds Round 2 is the Naive Guest round, the assignment is for students to build an experience for a user who knows nothing about their world. At finals for the round a naive guest is given the controls and the team who built the world is permitted at most one verbal instruction to help the guest complete the world, all other instruction must be given from within the game.
My team's world, The Pharaoh's Messenger, used the Head Mounted Display platform as its interface. The HMD is a set of goggles the guest wears coupled with up to four positional and rotational sensors that can be used any way a team wants. Our team used two, one on the HMD goggles to update the guest's view of the world based on what direction they were looking and another attached to a physical ship's wheel prop that the team assembled that used rotation data to steer the ship. The wheel was also meant to communicate as clearly and directly as possible to the guest what the interface was and how to use it. Instructions in the introduction were given using pictures only since we did not want to assume the guest necessarily even knew English.
The key to the round was playtesting, the challenge being that once someone playtests, they're no longer naive about the world and further input about their experience on successive runs becomes less useful. For instance, my initial implementation of the steering interface was actually rather counter intuitive, but since I had been testing so much from my workstation using the mouse and not as much on the HMD hardware in the lab I underestimated how off the interface actually felt. Once I got some testers in front of the game that were not on my team and saw how much trouble they had steering, I scrapped the original implementation and started over and ended up with a much more natural feel for the steering. Further testers we brought in were also very helpful in redoing the visual aesthetic based on what they thought they saw in the world rather than the reality of what we put there, which is how the game ended up being set in Egypt on the Nile river rather than on a generic river on a grassy plain. Even the title ended up being a helpful tool to convey a ton of important information: who the player is, the time and place, and what their objective is.
Round 2 was an interesting learning experience for a lot of reasons, one of which was from working on a larger team of 5 instead of the usual 4. I did a lot of things with the project to enable and encourage the other team members to contribute to the scene file in Unity, which had its pros and cons. It got the team more involved in working with the project and Unity itself which was good for morale and educational for the people on the team who had not done a lot of hands on work yet with Unity. Myself, our texture artist Sean, and our sound designer Ricardo could often all be working in the scene at once, but as Unity scene files are binary, not text, changes cannot be merged, only accepted or discarded. We lost some balance and tuning tweaks at once point and old bugs crept back in that I thought I had fixed. I had gotten into the habit of usually discarding my changes to the scene instead of committing them since I often assumed Sean was making level layout changes and that his changes would involve more work to reproduce than mine. Better communication about who was working in the scene file at any given time would have made that process go a lot smoother.
My team's world, The Pharaoh's Messenger, used the Head Mounted Display platform as its interface. The HMD is a set of goggles the guest wears coupled with up to four positional and rotational sensors that can be used any way a team wants. Our team used two, one on the HMD goggles to update the guest's view of the world based on what direction they were looking and another attached to a physical ship's wheel prop that the team assembled that used rotation data to steer the ship. The wheel was also meant to communicate as clearly and directly as possible to the guest what the interface was and how to use it. Instructions in the introduction were given using pictures only since we did not want to assume the guest necessarily even knew English.
The key to the round was playtesting, the challenge being that once someone playtests, they're no longer naive about the world and further input about their experience on successive runs becomes less useful. For instance, my initial implementation of the steering interface was actually rather counter intuitive, but since I had been testing so much from my workstation using the mouse and not as much on the HMD hardware in the lab I underestimated how off the interface actually felt. Once I got some testers in front of the game that were not on my team and saw how much trouble they had steering, I scrapped the original implementation and started over and ended up with a much more natural feel for the steering. Further testers we brought in were also very helpful in redoing the visual aesthetic based on what they thought they saw in the world rather than the reality of what we put there, which is how the game ended up being set in Egypt on the Nile river rather than on a generic river on a grassy plain. Even the title ended up being a helpful tool to convey a ton of important information: who the player is, the time and place, and what their objective is.
Round 2 was an interesting learning experience for a lot of reasons, one of which was from working on a larger team of 5 instead of the usual 4. I did a lot of things with the project to enable and encourage the other team members to contribute to the scene file in Unity, which had its pros and cons. It got the team more involved in working with the project and Unity itself which was good for morale and educational for the people on the team who had not done a lot of hands on work yet with Unity. Myself, our texture artist Sean, and our sound designer Ricardo could often all be working in the scene at once, but as Unity scene files are binary, not text, changes cannot be merged, only accepted or discarded. We lost some balance and tuning tweaks at once point and old bugs crept back in that I thought I had fixed. I had gotten into the habit of usually discarding my changes to the scene instead of committing them since I often assumed Sean was making level layout changes and that his changes would involve more work to reproduce than mine. Better communication about who was working in the scene file at any given time would have made that process go a lot smoother.
Building Virtual Worlds - Round 1 - The Shaft
So I finally have a free moment to start sharing some of the fruits of my labors over the past several weeks of my first semester here at CMU's Entertainment Technology Center! The central course of the first semester is Building Virtual Worlds, a rapid prototyping class where students are divided teams of 4 or 5 and are tasked with building interactive experiences over two weeks. It's all about teamwork! We all had one week to do a solo project to get the hang of the tools we would be using, C# and Unity3D in my case, and then we were off!
My round one project was The Shaft, an adventure game where the player wakes up at the bottom of a shaft in the earth in the middle of a heavy rainstorm and has to find his way out while avoiding hazards like drowning in rising waters, bats, and rockslides. It used the Microsoft Kinect as it's player interface with a simple gesture system I built, which came together quite smoothly thanks to the Kinect wrapper for Unity written by our upperclassmen!
C# took a little getting used to but thankfully it is close enough to C++ that I was able to adjust quickly. I still feel like I am being lazy letting the system do garbage collection for me, but I'll get over it! Unity3D itself is also very nice, and uses a lot of the same paradigms I use in SFPC, which also helped make for a quick learning curve.
My round one project was The Shaft, an adventure game where the player wakes up at the bottom of a shaft in the earth in the middle of a heavy rainstorm and has to find his way out while avoiding hazards like drowning in rising waters, bats, and rockslides. It used the Microsoft Kinect as it's player interface with a simple gesture system I built, which came together quite smoothly thanks to the Kinect wrapper for Unity written by our upperclassmen!
C# took a little getting used to but thankfully it is close enough to C++ that I was able to adjust quickly. I still feel like I am being lazy letting the system do garbage collection for me, but I'll get over it! Unity3D itself is also very nice, and uses a lot of the same paradigms I use in SFPC, which also helped make for a quick learning curve.
Sunday, August 28, 2011
Exciting Changes Ahead!
I have some great news to share! I've been accepted to Carnegie Mellon University's Entertainment Technology Center graduate program! I'll be working very hard towards earning a Master of Entertainment Technology degree over the next two years. First semester begins tomorrow! It's very exciting. I have several friends who are graduates from this program who all speak very highly of it, and it was their tales that inspired me to reach for the stars and apply.
What does this mean going forward? Odds are, you'll be seeing a lot fewer SFPC updates, but with any luck and a little free time (I hear that's in very short supply for ETC students!) you'll see some new posts on some much bigger and much different projects that I'll be working on in the months ahead.
For those of you who have been eagerly following my progress on SFPC, please know that the project remains very important to me and I intend to work on it more in the future when I have the time. All my hard work on SFPC was what earned me this opportunity, and I don't intend to abandon it. Ultimately this is a very good thing for the project. I'll be making lots of new friends I could possibly recruit to help out with graphics, sound, or code. My own skills will undoubtedly grow far greater and I'll be much better equipped to make SFPC even better.
And with that, I'm off to have my world turned upside down and inside out, and have my mind blown. Wish me luck!
What does this mean going forward? Odds are, you'll be seeing a lot fewer SFPC updates, but with any luck and a little free time (I hear that's in very short supply for ETC students!) you'll see some new posts on some much bigger and much different projects that I'll be working on in the months ahead.
For those of you who have been eagerly following my progress on SFPC, please know that the project remains very important to me and I intend to work on it more in the future when I have the time. All my hard work on SFPC was what earned me this opportunity, and I don't intend to abandon it. Ultimately this is a very good thing for the project. I'll be making lots of new friends I could possibly recruit to help out with graphics, sound, or code. My own skills will undoubtedly grow far greater and I'll be much better equipped to make SFPC even better.
And with that, I'm off to have my world turned upside down and inside out, and have my mind blown. Wish me luck!
SFPC - August 2011 Update
So, it's been a while since I've done any updates on SFPC. I'll admit, things definitely slowed down for a while, what can I say, I needed a break (or two)! Despite the lack of posts, I have gotten a lot of work done over the past few months, though the bulk of it was not really video or blog post worthy. This release represents the sum of the year's changes so far, which includes lots of bug fixes, a major revamp of the movement code for performance reasons, and some new editor features and engine enhancements.
There's no new gameplay map to try, hence the lack of a video. The main draw of this release is the enhanced editor, which includes several features which should be a big deal to anyone interested in making maps. Press the Home key to toggle between Play and Edit modes.
- The engine now supports variably sized maps, anywhere from a minimum of 28x20 tiles (two screens wide by two screens tall) to a max of 255x255.
- The editor now supports a sort of command console, think of the ~ menu from shooters like Quake. From within the editor, press F12 to open the console script. It opens a regular script window in Notepad. Enter whatever script commands you like, save the file, then press F9 to run the script. It is meant for one-and-done commands, and the file is wiped each time it gets loaded. Two new script commands have been added specifically for use with the console:
- The editor itself now has a more robust tile editing system:
Please feel free to email me if you have any questions on making maps or scripting or to let me know about bugs, or you can post in the comments below. If anyone makes a map and would like to share, let me know, I'd love to see them!
There's no new gameplay map to try, hence the lack of a video. The main draw of this release is the enhanced editor, which includes several features which should be a big deal to anyone interested in making maps. Press the Home key to toggle between Play and Edit modes.
- The engine now supports variably sized maps, anywhere from a minimum of 28x20 tiles (two screens wide by two screens tall) to a max of 255x255.
- The editor now supports a sort of command console, think of the ~ menu from shooters like Quake. From within the editor, press F12 to open the console script. It opens a regular script window in Notepad. Enter whatever script commands you like, save the file, then press F9 to run the script. It is meant for one-and-done commands, and the file is wiped each time it gets loaded. Two new script commands have been added specifically for use with the console:
- TileFill tilenum layer x1 y1 x2 y2 - Does a fill on the active map from x1, y1 to x2, y2 of the specified tile on the chosen layer. Must be a valid, in bounds rectangle, or nothing will happen. The editor UI now shows the corresponding integer version of the active tile for use with this command. Layers are background = 0, overlay = 1, foreground = 2. Great to make a large space, or even the entire map, get set to a specific tile, for instance an indoor map might use a pure black tile on the edges instead of a grass tile.
- CreateNewMap "mapname" width height - Creates a new folder structure in the /maps/ folder for the specified map name, as well as blank default map and event scripts. The editor does not load the new map immediately, the choice to save unfinished work (press F5 to save) and switching to the new map with either F1 to load maps or the Warp command in the console script is left up to the user.
- The editor itself now has a more robust tile editing system:
- The editing cursor now supports brush sizes. Increase or decrease the size of the brush with the Page Up and Page Down keys, from 1x1 up to 5x5. Changing the brush size fills the brush with the active tile.
- The editing cursor now also shows the contents of the current brush at half transparency over top of where it is pointing.
- The C key is still used to copy tiles, and will now copy the contents of the selected area to the entire brush.
- Any time the user changes layers or modes within the editor, the contents of the brush is erased and the size is set back to 1x1.
Please feel free to email me if you have any questions on making maps or scripting or to let me know about bugs, or you can post in the comments below. If anyone makes a map and would like to share, let me know, I'd love to see them!
Tuesday, December 28, 2010
2010 Year in Review
It's hard to believe it's already been a year since I started sharing my progress on SFPC here! In that time I've gone from what amounted to a simple map viewer and editor that could show a few text windows to something that is really starting to resemble a game, as can be seen below!
Want to try the demo for yourself? Download it here.
Over the past 11 months, new additions to the engine have included:
Want to try the demo for yourself? Download it here.
Over the past 11 months, new additions to the engine have included:
- Music and sound effects via the Audiere sound library
- A custom scripting language used both to control game events and logic and construct game assets such as characters and equipment
- A turn-based strategy RPG combat system with basic enemy AI
- Animated battle cutscenes that show the results of each engagement playing out on the battlefield
- A more robust system of windows and menus that tie the game together
- Some slides (.pdf) discussing some of these features in more detail are available here.
Sunday, December 5, 2010
SFPC - December Combat Test Video #6
This time around I've got two new features up and running: attack range based on a character's equipped weapon, and target selection and confirmation. Weapon graphics ended up getting put on the back burner for a bit, but they're still in the works.
I didn't work much on new features for SFPC in November. I've been reading some good books and sharpening my general C++ skills, so I went through a lot of my older code and did some clean up and general maintenance to apply what I've learned. Still a lot of code left that could stand to be polished and tweaked, but I decided to take a break from all that and do some new features and a video.
Saturday, October 30, 2010
SFPC Items Update
Click here to view on YouTube to go fullscreen and HD
Two updates in one day! Here we have the Items update, featuring scripted items and the new equipping windows. Also of note is the new colored text system, which simply *1works like this.*0 The *1 would set the text color to orange, then the *0 would set it back to white.
The next update will probably be another combat one, in which I actually do what I set out to do when I took this detour, which is have weapon graphics display in combat. Ranged attacks should also be pretty easy to implement now as well.
Two updates in one day! Here we have the Items update, featuring scripted items and the new equipping windows. Also of note is the new colored text system, which simply *1works like this.*0 The *1 would set the text color to orange, then the *0 would set it back to white.
The next update will probably be another combat one, in which I actually do what I set out to do when I took this detour, which is have weapon graphics display in combat. Ranged attacks should also be pretty easy to implement now as well.
SFPC Editor Demo Video
Part 1: Click here to view on YouTube to go fullscreen and HD
Part 2: Click here to view on YouTube to go fullscreen and HD
These are long overdue! Here you can see how I use the SFPC editor to create maps and script events. I'd like to believe that this system is simple enough that a novice could dive right in and be making maps pretty quickly given a little time, documentation, and encouragement. Part of the building up of that "documentation" is videos like this.
Part 2: Click here to view on YouTube to go fullscreen and HD
These are long overdue! Here you can see how I use the SFPC editor to create maps and script events. I'd like to believe that this system is simple enough that a novice could dive right in and be making maps pretty quickly given a little time, documentation, and encouragement. Part of the building up of that "documentation" is videos like this.
Sunday, August 22, 2010
SFPC - August Combat Test Video #5
This week the big new feature is combat animations! They're still pretty basic, no weapon graphics yet, I need to improve the item code a lot first before that happens, but aside from all the punching going on, things look pretty good!
Monday, August 16, 2010
SFPC - August Combat Test Video #4
Another productive weekend! Lots of bug fixing, under the hood changes, and asset ripping, but a handful of new stuff as well, hence the video. Scrolling text may look simple to the untrained eye, a little thing we all take for granted, but it took a good bit of work to get it looking right and behaving alongside everything else. Battle movement has also received a tune up, characters can move through (but not stop in) squares occupied by allies, and enemy squares are excluded from movement range calculations.
Sunday, August 8, 2010
SFPC - August Combat Test Video #3
Another month, another video! Usually I code for an hour or two here and there, typically in the morning before work, but today I got totally in the zone and put in something like 10+ hours! Got so much done! Combat is in a much better state now, cleaned up the existing battle code a ton, the new system is a lot more robust and easier for me to expand upon. New features since last time include:
- Battlefield Land Effect and Stats windows
- Basic Cutscenes (no character animations) with fade transitions
- Auto-advancing text windows in cutscenes
- Critical hits and double attacks
- Music switching into and out of cutscenes
I also made tons of changes behind the scenes I won't drone on about, but one last thing worth mentioning that I did start on was damage types (physical, fire, cold, etc). They're not taken into account for resistances or anything just yet, but the skeleton is there!
Obviously the next big milestone is going to be combat animations. Ideally I can have basic animation up and running for the next video, hopefully before September, but we'll see how things go. I also have lots of research ahead of me on getting my numbers right for calculating hits, misses, damage, special attack rates, and so on. Heck, I might be open to taking on a volunteer to help do a lot of that kind of digging for me. If anyone's interested, shoot me an email or leave a comment!
Friday, July 16, 2010
SFPC - July Combat Test Preview Video #2
So, more updates, more often. Check!
Finally something that actually resembles very basic but functional combat! My numbers are still way off, I'm sure, but I now have:
- The basic Attack/Magic/Item/Stay menu is functional. Magic and Item do nothing, a lot of work needs done before they come online, but Stay and Attack are up and running as you can see above.
- Units can attack each other, do damage, and are removed from the battlefield when they run out of hit points.
- The battle ends when there are no enemies left on the field, which you can see when the debug info goes away at the end of the video.
Other than all the stuff left to do, what I really need right now is more accurate formulas. None of the FAQs I have sifted through so far have the kind of info I need, at least not at first glance. For now, I'm essentially rolling 1d20 behind the curtain to see if an attack hits. A 20 is a crit (5%), a 4-19 is a hit (80%) and a 1-3 is a miss (15%). Damage right now is just attacking character's Atk minus defending characters Def, +/- 1. I still need to work counterattacks and double attacks into the mix as well, implement gold and how much gold an enemy is worth, how to award EXP, leveling up... so much left to do, but at least it's coming along.
If anyone has the exact formulas any of the SF games use, or can point me to a good resource that would save me a lot of time and effort doing research replaying parts of the original games over and over and over, please, let me know!
Friday, July 9, 2010
SFPC - July Combat Test Preview Video
I wouldn't call this the official July video, but I felt like seeing if I could do a quick video this morning and maybe try having smaller videos more often. I had to quickly reinstall VirtualDub and FRAPS first this morning since I forgot to reinstall them when I put together my new PC, and the video compression settings were a little off so the video quality is not where I usually like it.
Anyway, this primarily shows off the range checking code. I've tested it on ranges up through 5 and it works fine, but I just have it set to do a plain melee range check for the video. The game loops through the established initiative order, which is currently just all characters in the battle sorted based on agility. (Is this correct? I don't know! Feel free to chime in below in the comments!) The code looks for any potential targets within range and just lists them in the debug info. Note that the Dark Dwarves are not AI controlled at this point, that's still a ways off, I'm pulling all the strings here with the keyboard. They are, however, on the enemy team. You'll notice for instance when Sarah does a range check near the end of the video, it does not list Bowie or Chester as valid targets. Only units on the opposing team will show up on the target list.
I've been dragging my feet on doing the next post on the scripting system, I should work on that soon. As a hint for the question from last time: what happens to the chest when you leave the map and return later? Also on that note, from the comments, BNC was right about the chest-opening music, and I didn't even think of that part! I'll have to work that in eventually, too.
Friday, June 18, 2010
SFPC Scripting - Treasure Chest
So as I mentioned in my last post on the new features in the June update, SFPC now has its own scripting language used to build content for the game. Here's a basic script for a treasure chest from the demo:
!SFPC_Script "Chest 1 - Long Sword"
# Only runs after the chest has been opened.
FlagNeeded "Castle1_Chest1"
DialogueWindow "BOWIE looked in the chest.^It was empty."
End
NoFlag "Castle1_Chest1" # Only runs if the chest is still closed
SetOverlayTile 27 44 49
PlaySound "open-chest.ogg"
AddItem "Long Sword" "opened the chest."
SetFlag "Castle1_Chest1"
End
Let's break it down line by line:
!SFPC_Script "Chest 1 - Long Sword" - The opening !SFPC_Script just identifies this as a valid SFPC script file. The "Chest 1 - Long Sword" in quotes is the name of the script that gets shown in the editor when placing events. For instance, the many empty barrels that are scattered about the map all run the same script. If I place a few barrel tiles on the map then write a script for them, I only need to do it once, then I can place as many empties as needed, and I can flip back through the list of events easily to get back to that script and just place more copies later as the map expands.
# Only runs after the chest has been opened. - The # signifies that this and everything past it on this line is a comment, similar to // in C++ or /* */ in C. The scripting engine ignores everything else on a line after it hits a #. As can be seen later in this same script, this doesn't have to be the only thing on the line, comments can be at the end of a line after other script commands have already been run.
FlagNeeded "Castle1_Chest1" - Checks to see if a flag named "Castle1_Chest1" has been set or not. First, a quick aside about "flags". The game engine keeps a collection of flags, which are just strings of letters/numbers/etc. Any string of characters between quotes can be a flag. They're kind of like boolean true/false variables. Back to FlagNeeded! This command asks the engine to see if a flag named within the quotes exists. If it does, move forward and run the script commands on the following lines. If the flag has not been set, ignore all commands from here until the next End statement, which in this case is two lines down. The indentation on the commands that follow is optional but helpful, it keeps the script readable and helps show at a glance where one conditional statement like a FlagNeeded begins and ends.
DialogueWindow "BOWIE looked in the chest.^It was empty." - A DialogueWindow is a single window that shows up on the bottom of the screen for displaying text that draws in one character at a time. The text in the window is processed automatically to wrap from one line to the next. The manual '^' tells the string processor to show the paused text triangle at that point and wait for user input before clearing the window and showing more text.
NoFlag "Castle1_Chest1" - Similar to FlagNeeded, NoFlag checks to see if the flag in quotes is set and only runs the code between itself and the next End statement if the flag is NOT set.
SetOverlayTile 27 44 49 - Places the 27th overlay tile in the current tileset at coordinates 44x, 49y on the map. The top left corner of the map is 0, 0. Similar commands exist for SetBackgroundTile and SetForegroundTile. The draw order, from bottom to top, is Background, Overlay, characters, Foreground.
PlaySound "open-chest.ogg" - Pretty self explanitory, the AudioMgr code plays the requested sound. In this case it's an ogg vorbis audio file, but since I'm using Audiere for my sound lib at the moment, it can also play .wav or .mp3 files as well. The sound plays one time and is not looped.
AddItem "Long Sword" "opened the chest." - Runs the AddItem command, adding the item specified in the first parameter with the text in the opening DialogueWindow from the second parameter. If we were looking in a vase the text would be something like "looked in the vase." but it could just as easily say "checked inside the fireplace." or "searched behind the painting." or any number of options depending on the situation. The AddItem code then goes on to attempt to add the selected item to each character's inventory until it finds someone who has room to hold it, or gives up if everyone is full. I still don't have a working solution yet for the fringe case of opening a chest if the party has no room whatsoever (though I do have some ideas), currently in that case the item is lost for good and the chest remains open, but eventually the item will have to be put back in the chest and the chest will need to be closed back up again.
SetFlag "Castle1_Chest1" - I've already touched on the checking of flags, this command simply sets the specified flag to exist and be set to true.
Now, let's go back and put it all together and spell the whole thing out in english! If the flag Castle1_Chest1 has been set, we know the player has already opened the chest, so if they interact with it, just show that it is empty. If the flag was not set however, the item is still in the chest, so let them have it. Replace the closed chest tile with the open chest tile (27th in the overlay tileset), play the open chest sound, run the AddItem command to actually give the party the item and make sure someone with a free hand gets it, then finally set the Castle1_Chest1 flag so that this chest stays empty. It's a chest, not a sword dispenser, after all.
There's one thing missing here though, which I leave as an exercise for the reader. Point it out in the comments, and I'll cover what's missing in the next post on scripting for SFPC!
!SFPC_Script "Chest 1 - Long Sword"
# Only runs after the chest has been opened.
FlagNeeded "Castle1_Chest1"
DialogueWindow "BOWIE looked in the chest.^It was empty."
End
NoFlag "Castle1_Chest1" # Only runs if the chest is still closed
SetOverlayTile 27 44 49
PlaySound "open-chest.ogg"
AddItem "Long Sword" "opened the chest."
SetFlag "Castle1_Chest1"
End
Let's break it down line by line:
!SFPC_Script "Chest 1 - Long Sword" - The opening !SFPC_Script just identifies this as a valid SFPC script file. The "Chest 1 - Long Sword" in quotes is the name of the script that gets shown in the editor when placing events. For instance, the many empty barrels that are scattered about the map all run the same script. If I place a few barrel tiles on the map then write a script for them, I only need to do it once, then I can place as many empties as needed, and I can flip back through the list of events easily to get back to that script and just place more copies later as the map expands.
# Only runs after the chest has been opened. - The # signifies that this and everything past it on this line is a comment, similar to // in C++ or /* */ in C. The scripting engine ignores everything else on a line after it hits a #. As can be seen later in this same script, this doesn't have to be the only thing on the line, comments can be at the end of a line after other script commands have already been run.
FlagNeeded "Castle1_Chest1" - Checks to see if a flag named "Castle1_Chest1" has been set or not. First, a quick aside about "flags". The game engine keeps a collection of flags, which are just strings of letters/numbers/etc. Any string of characters between quotes can be a flag. They're kind of like boolean true/false variables. Back to FlagNeeded! This command asks the engine to see if a flag named within the quotes exists. If it does, move forward and run the script commands on the following lines. If the flag has not been set, ignore all commands from here until the next End statement, which in this case is two lines down. The indentation on the commands that follow is optional but helpful, it keeps the script readable and helps show at a glance where one conditional statement like a FlagNeeded begins and ends.
DialogueWindow "BOWIE looked in the chest.^It was empty." - A DialogueWindow is a single window that shows up on the bottom of the screen for displaying text that draws in one character at a time. The text in the window is processed automatically to wrap from one line to the next. The manual '^' tells the string processor to show the paused text triangle at that point and wait for user input before clearing the window and showing more text.
NoFlag "Castle1_Chest1" - Similar to FlagNeeded, NoFlag checks to see if the flag in quotes is set and only runs the code between itself and the next End statement if the flag is NOT set.
SetOverlayTile 27 44 49 - Places the 27th overlay tile in the current tileset at coordinates 44x, 49y on the map. The top left corner of the map is 0, 0. Similar commands exist for SetBackgroundTile and SetForegroundTile. The draw order, from bottom to top, is Background, Overlay, characters, Foreground.
PlaySound "open-chest.ogg" - Pretty self explanitory, the AudioMgr code plays the requested sound. In this case it's an ogg vorbis audio file, but since I'm using Audiere for my sound lib at the moment, it can also play .wav or .mp3 files as well. The sound plays one time and is not looped.
AddItem "Long Sword" "opened the chest." - Runs the AddItem command, adding the item specified in the first parameter with the text in the opening DialogueWindow from the second parameter. If we were looking in a vase the text would be something like "looked in the vase." but it could just as easily say "checked inside the fireplace." or "searched behind the painting." or any number of options depending on the situation. The AddItem code then goes on to attempt to add the selected item to each character's inventory until it finds someone who has room to hold it, or gives up if everyone is full. I still don't have a working solution yet for the fringe case of opening a chest if the party has no room whatsoever (though I do have some ideas), currently in that case the item is lost for good and the chest remains open, but eventually the item will have to be put back in the chest and the chest will need to be closed back up again.
SetFlag "Castle1_Chest1" - I've already touched on the checking of flags, this command simply sets the specified flag to exist and be set to true.
Now, let's go back and put it all together and spell the whole thing out in english! If the flag Castle1_Chest1 has been set, we know the player has already opened the chest, so if they interact with it, just show that it is empty. If the flag was not set however, the item is still in the chest, so let them have it. Replace the closed chest tile with the open chest tile (27th in the overlay tileset), play the open chest sound, run the AddItem command to actually give the party the item and make sure someone with a free hand gets it, then finally set the Castle1_Chest1 flag so that this chest stays empty. It's a chest, not a sword dispenser, after all.
There's one thing missing here though, which I leave as an exercise for the reader. Point it out in the comments, and I'll cover what's missing in the next post on scripting for SFPC!
Tuesday, June 15, 2010
SFPC - June Update
So here it is, the next big update. So much has changed since April, here's a list of some of the big stuff:
- Audio: music and sounds now work. Currently using the Audiere sound library, but that could change down the road.
- Events: In the previous demo, I explained that I couldn't handle events that contained multiple commands yet. That limitation has been dealt with by implementing...
- Scripting Engine: Way back in the day, while I was just a comp sci undergrad, I worked with Nathan Yam creating levels and scripts for our RPG clones, Dream Quest 2000, Dream Saga, and DWPC. The scripting system I have put together for SFPC is based on my experience working with the DreamVision scripting language Nathan created. Other than a very similar scripting syntax, however, it is entirely my own code.
Many game aspects are assembled via scripts: NPCs, party members, events, game startup, map startup. Eventually even more systems will be handled via scripting, like items and spells, but for now those systems are hard coded. I'll be writing some separate posts about the scripting system and showing off some examples.
- Flag System: a backbone of the scripting system is the Flag system. A script can set and check for the presence or absence of flags and then run or not run commands accordingly. This opens up a ton of potential.
Keep an eye out for some scripting examples to be posted soon!
Tuesday, April 13, 2010
SFPC - April Update
Another new video showing progress on events. Currently events are simple, single commands. I have a plan to upgrade to complex multi command events, and hope to have that done and a video uploaded soon.
Monday, March 29, 2010
SFPC - March Update
Here's a brief video of some of the updates to SFPC I've been working on recently. Take a look!
Friday, January 29, 2010
Welcome!
Thanks for stopping by to check out my game development portfolio! Since this is in a blog format, to read posts in chronological order, start at the bottom and work your way up or click the following links!
More material will be added as time goes on and my portfolio grows, and as I clean up and reformat some of my older works.
Left 4 Dead Custom Level - Celtic
Here is a brief YouTube video walkthrough of my custom Left 4 Dead map, a recreation of the first floor of the office building where I work.
Originally scheduled to debut at a LAN party for charity hosted at my work back in the fall of 2009, but the LAN party got postponed. Tentatively rescheduled for Summer 2010, I hope to have both floors completed and Survival mode fully playable by then.
Originally scheduled to debut at a LAN party for charity hosted at my work back in the fall of 2009, but the LAN party got postponed. Tentatively rescheduled for Summer 2010, I hope to have both floors completed and Survival mode fully playable by then.
Shining Force PC
Shining Force PC is a work in progress to recreate Sega’s classic Strategy RPG for the PC using C++ and OpenGL. My goal with SFPC is to develop a robust RPG game engine that eventually expands on the original game’s features while not making it overly complex or losing sight of what makes the originals so much fun.
The Original
What is Shining Force? Shining Force is a strategy RPG by Sega from the early 90s. When talking to others about Shining Force, I always find myself using the phrase “elegance in simplicity” to describe it. The game features a simple, straightforward user interface, character statistics and game mechanics that are easy to understand, and an overall enjoyable combat system that is quick to pick up but also has a surprising amount of depth to it. You can see some YouTube videos of gameplay montages from the original Sega Genesis versions of Shining Force 1 and 2 here:
Shining Force 2:
Shining Force 1
Why Remake It? First and foremost, because it is fun! I have many fond memories of the summer back in high school when I loaned my Super Nintendo and all my Final Fantasy games to a friend in exchange for his Genesis and these Shining Force games he had been so enthusiastic about. I could quickly see why he enjoyed them so much! To this day, Shining Force tends to stay at the top of the charts of Genesis games at GameFAQs: http://www.gamefaqs.com/console/genesis/ While it enjoys its own cult following, it has nowhere near the popularity of bigger RPG franchises such as Final Fantasy and Dragon Quest. Both of those series’ have had plenty of fans attempt remakes over the years, and I’ve worked in a supporting role on such projects myself in my time with Firebell. Indeed, it was working on those remakes that originally inspired me to attempt remaking Shining Force, but this time as my own solo project, coded from scratch. Much of what I learned working on those projects continues to guide how I design and build SFPC.
The Code
Progress, Features, and Goals: The SFPC engine currently implements many of the core elements required to make a console style RPG: animated, player controllable characters that can move around on a square grid, a camera that can smoothly transition from character to character, windows and menus scalable to any size that render text from either variable or fixed width bitmapped fonts, and a multi layered map that can be edited with the in-game editor. My next major goal is to implement a scripted Event system to get all of these individual parts to work together to create an actual game experience rather than the features demo that exists today. Once events are running, work can continue on the actual combat system, the ground work of which is already in progress with the Land Effect based movement and character stats that can be seen in the current build. After that, sound and gamepad based input are a little further out on the horizon. In the long term, I’ll be looking to get an artist or two to help me create original assets to create a full original game. I would also like to eventually try implementing both co-op as well as competitive multiplayer modes, both locally and online. This last feature has some interesting implications, as I can think of another far more recent multiplayer strategy RPG based on a square grid that I also enjoy that is just begging for a good online implementation: 4th Edition Dungeons and Dragons.
Progress, Features, and Goals: The SFPC engine currently implements many of the core elements required to make a console style RPG: animated, player controllable characters that can move around on a square grid, a camera that can smoothly transition from character to character, windows and menus scalable to any size that render text from either variable or fixed width bitmapped fonts, and a multi layered map that can be edited with the in-game editor. My next major goal is to implement a scripted Event system to get all of these individual parts to work together to create an actual game experience rather than the features demo that exists today. Once events are running, work can continue on the actual combat system, the ground work of which is already in progress with the Land Effect based movement and character stats that can be seen in the current build. After that, sound and gamepad based input are a little further out on the horizon. In the long term, I’ll be looking to get an artist or two to help me create original assets to create a full original game. I would also like to eventually try implementing both co-op as well as competitive multiplayer modes, both locally and online. This last feature has some interesting implications, as I can think of another far more recent multiplayer strategy RPG based on a square grid that I also enjoy that is just begging for a good online implementation: 4th Edition Dungeons and Dragons.
Overview Presentation: Look over the PowerPoint presentation I put together outlining some of the features of my code here. It features details about my classes their and functions, graphs of inheritance relationships, and some diagrams of the flow of certain parts of the program.
The Learning Experience
OpenGL: The SFPC you see today is actually my second revision of the project. The first was built using DirectDraw. Today’s SFPC benefits greatly from the rewrite on many levels. First, just in general doing the rewrite let me keep the strongest parts of the old code and shed the weaker ones and the project is far more flexible and easier to work with now than it was before. Next, while working with OpenGL meant making some small concessions, the rewards are plentiful. Shining Force operates on a grid of 24x24 tiles, but OpenGL requires textures be sized to powers of 2. This was easy to get around by writing code that scales a square buffer to the smallest power of two that can hold the incoming image, fills it with pure magenta and an alpha value of 0, then copies the actual data into the buffer. Any magenta in the incoming 24bit color image gets its alpha value set to 0 as well. The buffer is then converted into a texture by OpenGL and stored in an instance of my Texture class, which holds the texture, the source data dimensions, and the actual data dimensions. For basic tiles, this is 24x24 for the data dimensions and 32x32 for the actual ones. With that one major workaround out of the way, I am able to have alpha blending, texture flipping, mirroring, and stretching, full screen fade ins and fade outs, and tinting of any or all textures to any color, all very quickly and easily. My DirectDraw based code did not have anywhere near that many features! While on the topic of OpenGL, I feel I should mention that I learned basic OpenGL using the first ten NeHe OpenGL tutorials from http://nehe.gamedev.net. I wrapped up the NeHe OpenGL initialization code into my own bluGL class, set the screen to use orthographic projection to treat the screen as a 2D space, and things have been running smoothly ever since!
OpenGL: The SFPC you see today is actually my second revision of the project. The first was built using DirectDraw. Today’s SFPC benefits greatly from the rewrite on many levels. First, just in general doing the rewrite let me keep the strongest parts of the old code and shed the weaker ones and the project is far more flexible and easier to work with now than it was before. Next, while working with OpenGL meant making some small concessions, the rewards are plentiful. Shining Force operates on a grid of 24x24 tiles, but OpenGL requires textures be sized to powers of 2. This was easy to get around by writing code that scales a square buffer to the smallest power of two that can hold the incoming image, fills it with pure magenta and an alpha value of 0, then copies the actual data into the buffer. Any magenta in the incoming 24bit color image gets its alpha value set to 0 as well. The buffer is then converted into a texture by OpenGL and stored in an instance of my Texture class, which holds the texture, the source data dimensions, and the actual data dimensions. For basic tiles, this is 24x24 for the data dimensions and 32x32 for the actual ones. With that one major workaround out of the way, I am able to have alpha blending, texture flipping, mirroring, and stretching, full screen fade ins and fade outs, and tinting of any or all textures to any color, all very quickly and easily. My DirectDraw based code did not have anywhere near that many features! While on the topic of OpenGL, I feel I should mention that I learned basic OpenGL using the first ten NeHe OpenGL tutorials from http://nehe.gamedev.net. I wrapped up the NeHe OpenGL initialization code into my own bluGL class, set the screen to use orthographic projection to treat the screen as a 2D space, and things have been running smoothly ever since!
Static and Dynamic Data: At the beginning of writing this new revision of SFPC, I was using a lot of statically created data in the GameEngine Initialize function and storing pointers to it inside of my GameObjectMgr. Commonly used textures, such as window borders and frames as well as GameFonts, are stored in their own singleton based manager classes. One of the more recent features I implemented was the Shining Force style ActionMenus, which are handled by MenuMgr and are dynamically constructed and destructed. Now that I am more comfortable with this and am more confident removing objects from GameObjectMgr, I intend to transition away from so much static data in the near future. This will hopefully give me a lot more flexibility as I move forward with the project!
The Demo
YouTube: I've embedded a video walkthrough of the demo in its current state below:
Download: A download of this playable demo is available here. Requires a Windows based PC with an OpenGL capable video card.
Subscribe to:
Posts (Atom)