Showing posts with label Project CAS. Show all posts
Showing posts with label Project CAS. Show all posts

Friday, May 17, 2013

Summer 2013: Week 1

Getting prepared for an Orphan Adventure Game.
This is the first of a series of weekly updates for the blog and today, I figure I'll talk a little bit about Orphan Adventure Game. If you are not interested in OAG, then at the end of this blog post I introduce a new topic that may offer insight to the world of student developers (at least at Champlain College in Burlington, Vermont).

Orphan Adventure Game

OAG is currently a project that I plan to prototype and develop with Matt Barrett and Jack Yeates over the next seven to eight weeks. I explained the concept of the game in my previous update, but to simplify, it's a three phase RPG where you explore, shop and battle as a rag-tag group of musical orphans. The phases take inspiration from various rouguelikes, Second Wind, Final Fantasy, Mother 3 and The Binding of Isaac, though these mostly inspire the exploration and shopping systems. The battle system is based on musical orphans using sounds and music to defeat their foes, but it's not a rhythm-based system. It's in it's early stages, but as time goes on and more progress is made, I'll reveal more about it.

The game's prototype is going to be made in AS3 as to give it a large, easily-accessible target audience and distribution stream, but the full-game, assuming the prototype(s) pan out, will be written for other platforms. I'm aiming to release a full-version of the game as a multi-platform, browser/mobile/personal computer venture, but judging by how poorly AS3 handles sound, I may end up abandoning browsers. We will see.

Currently, I am working on making sounds work smoothly in AS3 and as far as the prototype is concerned, I think that I am satisfied with what I have. I'm more or less brand new to the platform and I'm not using any libraries or anything (since I'm preparing for college classes that will make me use AS3), so next on my list of things to figure out is moving between phases and therefore between "rooms". My projected path is as follows:

  1. Make sure sounds are working and write fade-in/fade-out functions.
  2. Determine how to switch between phases (combat, exploration, and shop) and move between rooms.
  3. Begin prototyping of combat phase without an inventory. This will require basic character classes and stats.
    1. While doing this, I will also work on a message-box/dialogue/text-handling system to display text elegantly.
    2. I will also begin messing with animations and visual assets.
  4. Begin work on exploration phase.
    1. This will include writing something that will randomly generate rooms, but will allow me to create scripted events for the plot progression.
  5. Begin work on shopping phase.
    1. This will involve writing an basic inventory system, though this system may be written sometime earlier.
  6. After making sure the phases are fun, I'll begin polishing the phases.

Motivated Design: Part 1

Aside from creating Dolphin Squadron and starting on a variety of other projects like Orphan Adventure Game and Voyage, my freshman year at Champlain College also introduced me to a slew of potential problems that I didn't know existed, namely the lack of motivation, cloud of resentment and propagation of rivalry (sometimes negative) among some aspiring game developers. The most startling thing about this though was that these problems were being partially created by me and my team! This realization was definitely a sort of wake up call for myself and for the rest of us (we were trying to inspire people, not demotivate or upset them!), so, over the next couple of weeks, I think that I'll discuss the issue of motivated design and developers at Champlain College and abound.

An Introduction to the Issue

The issue arose when we found that our loosely defined "team", ACPC Productions, was being resented for being composed of people who, as freshmen, were very vocal about wanting to make games. Because we had actively sought out and "allied" with talented people that we worked well with, we had inadvertently upset a pretty large group of people (freshmen and upperclassmen included) that saw ACPCP as two things: an entity that was attempting to "steal" talented people away from the other developers and a clique of pretentious asshats that thought that because we had a team, a name, and ideas, that we were better than everyone else.

At first, I found it absurd that people would think something like that about us--all we wanted to do was make games and as a group that's what we did--so when we heard this from Brook, the team was more or less devastated and many of us took the news to heart. But as time went on, we began to realize that we could have potentially been upsetting people because of what we were trying to do. We wanted to make games, but so did everyone else. The problem was that with the way we approached game development, we came across as pretty self-serving or at least cliquey. We wanted to inspire people, but we were doing the opposite.

All Talk, No Games
We actively work on a lot of projects. Screenshot from the document I use to manage our "teams" and projects.
Because we work on a lot of projects (not all games), speak openly about most of them and then create and release a lot of promotional artwork (but few prototypes), we can be seen as a team that is all talk and no games. And judging by this list, which doesn't include a couple of my projects like City Across the Sky (prototype) or Voyage (concept), you can see that we do, in fact, work on a lot of projects, with only two being anywhere near completion: Dolphin Squadron and End Love. 

In addition to this, we were fairly large. This upset people and made it look like we were just arbitrarily adding people to the "clique". This was especially harmful because the whole team is usually never working at the same time. Dolphin Squadron, for example, was developed by myself, Brook and Jack Yeates, with the rest of the team occasionally doing QA and usability testing. Even more so than that though, was how we over-scoped our games at various game jams in an effort to push ourselves as hard as we could go. This led to the development of the idea that we couldn't really finish anything and spread it through a public, developer-centric space. 

A New Idea: The EDC

At that point pretty much, ACPCP and the idea of us being the group to inspire other groups at our college, was fucked. We had to improve our image, get rid of the name or do something else. James Shasha (Designer) was keen on the idea of getting rid of the name and starting anew; Brook Chipman (Artist) wanted to reduce the size of the team down to the original members (the Project Clusterfuck team); I didn't know what I wanted to do. I didn't want to kick anyone out and I didn't want to lose the name that we started with. I also just wanted to work on and finish Dolphin Squadron. I just wanted to make games.

We decided to reorganize around this idea of a community of student developers. A place where anyone could go and work on anything they wanted. We designed a club that acted as a place for people to go to pitch ideas, form teams and make progress. Pretty much what we did within ACPCP, but open to everyone and not just the members of our clique. That was the idea behind the EDC, the Extracurricular game Developers of Champlain. We turned it into a club and suddenly, a lot of the negative emotions began disappear, and people seemed genuinely interested in the idea.

PART TWO OF MOTIVATED DESIGN NEXT WEEK.

Expect Greatness.
Ryan Huggins~



Friday, July 20, 2012

Postmortem: City Across the Sky

To start off this blog, we can take a look at my very first video game (and only game half-worth a release), City Across the Sky, originally known as Project CAS. (It was about 95% or so complete before I stopped development to move onto something else.) Besides some missing things however, I tend to call the game complete as of 7/1/2012


City Across the Sky (Download Link)
Project CAS began as an idea for a small, innovative video game that would help me learn the basics of programming and design. Little did I know that what I originally thought would be a small game would end up being designed as a game much larger than originally intended.

The original premise of the project was a fairly simple, yet dark one. You are a single mother who lives on a small island off the coast of somewhere and your son disappears into thin air--at the same time, the main character is also dying of a degenerative disease known as Zero, making it impossible for you to truly control your emotions. Gameplay was supposed to be a mix of Castlevania and Megaman with the focus on exploration as opposed to combat. The kicker was in a concept that I had designed called degenerative gameplay, where rather than steadily increasing the difficulty of enemies to boost the game's overall difficulty, the player character would slowly "degenerate", lose levels and become weaker. Through this system (that was never actually implemented), the game would become more difficult the longer the player took to complete it while enemies stayed at more or less a stable level of difficulty. I still think that the idea is a feasible one and one worthy of being implemented into one of my projects. Alas, my skill set was too limited at the time and I made far too many mistakes early on to get the idea working (and feeling) the way I had wanted it.


Development Story

Essentially, the development of Project CAS was pretty much flawed from the very beginning and for anyone who reads this, I hope they learn to not make the same mistakes as I did. During the "design stages" if you can even call them that, I wrote a base outline for a story following about 113 plot milestones (what I considered a small amount) and drew a couple of graphs depicting how I wanted degenerative gameplay to flow. That's it. I look back now and wonder why the hell I decided to completely skimp on the design for my first developed project when I have literally written hundreds of pages of designs for other projects (that I am STILL designing to this day). I feel like I should have known that without a design or a general outline of actual goals to meet (in relation to creating a compelling gaming experience) that the project was destined to fail. That is one half of the story of Project CAS. The other half is a very dramatic experience with inexperience--one that caused the development of the project to drag on...and on...and on... In fact...

It was almost a year and a half before I realized that I just didn't like the way the game was going anymore.* So, I dropped it (after lots of internal debate and struggle, as well as discussion with my game development partner, Jacques Yeates).

*Do not let this situation happen to you. Ever. Period. AT ALL. Zero percentage of chances. It drains you physically and mentally. Try not to force yourself to work on something that you don't have to and you are no longer inspired to work on, especially while you are young. In the end, you'll regret a lot of the time you spent and you probably won't learn as much as you could had you decided to move on.**

**At the same time, don't just quit and move from project to project. Sometimes, it's worth it to stick it out and finish something, even if you don't like it. Just don't spend two years doing it.

Regardless, it was a pretty long time before I realized that what I was working on just wasn't coming together, but I tried to force myself to work for months and eventually just burned myself out. I recommend to any young developers that if you're not feeling a project, then reevaluate and think hard on it's worth and then decide to continue or quit.


Early Development
"Prototyping"
While I like to call the early graphics of Project CAS my "prototype" version, it was really an excuse to ignore people's criticisms about the game and learn the basics of scripting with Game Maker (it took me a full three months of dedicated hatred to get collisions to work before I decided to rewrite the "physics" of the engine to my specifications [a fairly difficult thing for someone so new to scripting]). However, in the end, I got all the movement working, threw in some placeholder art (about the best I could manage since sprites and colors aren't my forte at all) and even some enemies before showing some friends what I had "created". (When your very first non-mentored programming project gets glances and uninterested "that's cool, man" comments from your friends, something should strike you as immediately wrong.) But for me it was, ":O REALLY?!" so I kept on working on tiled maps that weren't even tilesets and on learning to code, while expecting people to love my game despite it's mediocre graphics, horrible controls (not to mention an overpowered wall climbing ability) and lack of a definitive goal. Unacceptable, even for a junior in high school and eventually I almost quit because I just wasn't feeling it anymore.

But then, enter Jacques (back then I called him by his internet alias Nekomage), with his decision to help update the graphics with me, we created some concept art for the new look (viewable here) that eventually led to the graphics that the game ended up with today.

Uhh, Half Development?
But still not a good game. Which is the desire.
With Jacques' help, I was able to renew an already waning desire to work on a project with graphics that I didn't particularly like, or even enjoy working on. And by the time of the game's pseudo release (only here and a few various other links scattered around), the graphics and overall aesthetic/feel of the game may be one of the only things that I'm proud of. (Music as well, but I had very little influence on the quality of that).

But the issue was never really the graphics, the issue was a mixture of inexperience and lack of direction. Even once I recruited Jacques onto the project (originally just the composer for the game), he explained to me (later) that there was a general lack of direction, but assumed that I knew what I wanted and just kept quiet. I had wanted to design and then make a game where exploration was key, but I was too inexperienced with coding and design to even design a game that had a focus! I wanted combat! I wanted great graphics and music! I wanted exploration! A great story! Lots of items and things to find! I wanted too much for a first game. What I should have wanted was a focused experience and that is the center of what I learned from developing CAS. Instead, I tried for awhile to just include everything, even when I just didn't know how to code it. But, because of this failure, I later learned to focus. I learned that I should design and prototype before execution.
These are important things to understand as a new designer/developer of video games and I can't and will not be the last person to make that mistake. When you want to make something good and you're new to the whole thing, just start small; and I mean actually small. Not what you think is small, not 113 damn plot points spanning across 16 locations. Choose something simple--like jumping, sliding, displaying dialogue (which is actually harder than you'd probably imagine if you want it to look nice)--and build something around that. For new indie developers, or new developers in general, focus is key. Stay focused and you'll build a better experience.
And hence the crux of early/mid development of Project CAS.


Late Development
The least fun part. Seriously. It is a draaaaaaag.
After realizing that I made a terrible mistake dragging the game out for so long, I wished I could have stopped earlier, but I had partially dedicated the project to a "graded" assignment in school--the CAS (Creativity Action Service) Project for my IB diploma*. I had to turn in something, so I pushed forward...and it was a terrible push. I cut the game to almost 25% it's original size and scope, restarted the project, removed a lot of the mechanics (like overpowered wall climbing, which became ledge climbing), and rewrote all of the cutscenes to accommodate for the new (absolutely horrendously written) plot and story.

Problem is, because of a lack of time I kept ALL of the old maps** (which were originally designed for the older mechanics) and wrote the new story around what I already had in place. I then created the new project, dubbed CASmini, in around 6 months*** and hoped everyone would just ignore the fact that it was a giant mezclado-turd of a game (design-wise and story-wise) with elements coming in from all the variations the game went through, when it should have been rebuilt from the ground up to accommodate the new mechanics.

* Which I didn't end up getting, partially due to the hours (which reached into literal full weeks) spent working on CAS instead of studying.

** DON'T DO THIS.

***Not nearly enough time.


I never even added the brick decal to the rest of the city (and I removed this whole map).

In fact, the only redeemable parts of the game are the portions I mapped and designed after the new mechanics were factored into the design equation (intro tutorial, and the factory), whereas everything else is pretty much just empty space with nothing happening. But, I kept on working and as a little voice inside of my brain kept telling me to quit (almost like clockwork) I kept on working, and working, and working. I burned myself out and that was it (this was June of 2012). I really just couldn't mentally handle it anymore.

That day, I talked to Jacques and we decided to end it; I added in what I could in the last days, closed the window and have only opened it to fix a bug or two people found while trying it out. In the end, I was supremely disappointed in myself for working so hard to create something so abysmal, but I feel so free now that it's done, or at least over. I learned so much about the process that it's ridiculous how empowered I feel almost a month later working on something new. The best part though, is almost immediately after closing the window for that "last" time...everything that I had once held near and dear to my heart and was once passionate about prior to the uninspired crunch...it all rushed back into me. After almost 8 months of terminal artist's block, I was suddenly inspired to draw again and images filled my mind. It was fantastic.

I had new ideas again! And slowly, but surely, haunting images of the City Across the Sky left my mind and were replaced with new concepts and a feeling of happiness that is difficult to explain in words. It just is. I was just happy to be "done". In other words: I was free.

But by being free, I knew I had to use that inspiration to get into a brand new project; but this time, I had to make sure I did it right. And here I am, dog-sitting at my girlfriend's house while she is away with family, writing a blog post about how terrible of a designer I was, and maybe still am, in order to understand myself and my mistakes better. Something I would have never (and could have never) done had I still been working on CAS.

But, the point of being young is to learn, and the point of making games (in my opinion) is to have fun, to make fun, and to get better so that you can inspire others to experience something you've or they've always wanted to do, maybe through your games or otherwise...but ultimately, it's about your experience and what you get out of making the game that matters, because at the end of the day, what's a player, but another person living your projected experiences through the medium of your choice. Video games. :D

Expect Greatness.
A Postmortem by Ryan Huggins.
Siifour Studios

Thanks for Reading~