Blog for Michael Perry at GarageGames.com

Documentation Announcements

Michael Perry — 2008-09-04T17:37:34+00:00

Documentation and YOU!

Greetings again everyone! For those of you steadily following the documentation updates, I have answers to some of your questions as well as a few new announcements. Let's get right to it:

A Peak Inside the Process

I'm sure most of you developers out there would rather know more about how our engines are developed, but the documentation process is slowly reaching the same level of difficulty and complexity. I'm currently staring at a big white-board that is covered top-to-bottom, left-to-right of documentation notes and deadlines that extends out to early next year...wow...

As I mentioned in my last blog, a whole system had to be developed to manage and improve the documentation for all of our products (Torque Engines). Beyond the tech, which involves developing a decent amount of php, html, and java modules, a routine schedule was necessary. What I work with is no ordinary schedule; I have a schedule for engine releases, a weekly development schedule, semi-monthly updates to the landing pages and official docs, and so on.

Bored yet? Well, this is the time to perk up. All that scheduling talk is not to garner pity (none of that "woe unto the poor doc writer" nonsense). This was my not-so-subtle way of stating, starting this month, there will be some kind of documentation related update every week of the month. If there are enough important changes, I will blog about them at the end of the month to make sure you know what to look for.

IRC Hour

This is an announcement I'm pretty excited about:

What It Is: IRC Hour is a chance for the community to have real-time talks with myself and our site admin, David Montgomery-Blake. The subject of these talks is to discuss official docs, tutorials, and possible community contribution. We will be using the GarageGames IRC channel hosted by MaxGaming OnLine.

What It Isn't: Debugging other people's code, marathon one-on-one help sessions, discussing the future of GG or Torque Engines, soap-box rants, etc.

Organization: Each session will focus on specific technology: TGB and TX will share one session, TGE and TGEA will share another. To maintain order, David and I will come up with leading questions that will determine the topics for each session. Due to the nature of IRC, patience and civility will be required to maintain order and convey everyone's thoughts.

When: Each session will happen on Thursday, at 3:00 pm (PST). To avoid complete chaos and lacking time for all the possible issues, we are going to have 2 IRC Hours a month.
- TGB/TX - 2nd week of the month.
- TGE/A - 3rd week of the month.

If the concept proves popular and attendance increases, we may split TGB and TX up into their own times. The first TGB/TX IRC Hour will happen on Sept. 11, and the first TGE/A will be on Sept. 18.

Purpose: Primarily, this will be another great source of feedback that can be used to improve documentation. Bonus benefits include: getting help with an official tutorial, venting directly to an employee about the state of the docs and tutorials, become a part of an official process in GG, and so on.

How to Contribute

Quite a few people have e-mailed me directly with feedback and helpful suggestions on the current docs. Some community members wish to go the extra mile by writing their own docs and tutorials. First off, that is AWESOME.

If you want my involvement in your documentation project, such as checking in on it, reviewing the material, performing a final pass, preparing it for the official docs, etc, here is how I suggest you start:

1. E-mail me directly (my address is found in my profile), with the word "Documentation" some where in the title.

2. In the e-mail, let me know who you are (if we haven't spoken before) and what you want to do. From there, I can start providing you with feedback and general direction.

I want to stream line the process that will take your tutorials and documents and get them into official documentation. Afterwards, I will shine a bright and happy light on you and your work for the rest of the community to see.

Summary

There you have it, folks. I've peeled back another layer surrounding the new Doc System. . .you, the community, are a part of what makes the system work. It's a great cycle: documentation is written for you, and by providing feedback you help the documentation writing process.

David and I look forward to seeing you in the GarageGames IRC channel. If you have any questions about IRC Hour or writing docs, feel free to contact me at any time.

Until next time!

New Documentation System

Michael Perry — 2008-08-14T16:41:46+00:00

New Documentation System Has Arrived!

In my last .plan, I hinted that there would be a huge second announcement regarding documentation. This is the announcement. When I was first contracted by GG, I was mainly working on content generation for TGEA. However, when I was hired on as a full time employee the real work began. Going beyond simply writing tutorials and reference docs, it was time GarageGames implemented a full Documentation System.

Before I continue with the .plan, the following links show off the new documentation pages, content, and system:

Main Landing Page

TGE Landing Page
TGE Official Documentation

TGB Landing Page
TGB Official Documentation

TGEA Landing Page
TGEA Official Documentation

TorqueX Landing Page
TorqueX Official Documentation

Artist Landing Page

You can find these links in our updated menu bar at the top of the website:

To understand the Doc System and what I do at GarageGames, allow me to explain the documentation process I use. I have consolidated all of my work as Documentation Engineer into 3 categories: Content Generation, Organization, and The Doc System.

Content Generation

When most users think of documentation work, they are thinking about content generation. Tutorials, reference docs, how-tos, and so on. You would think this would take up the majority of my time, and perhaps later on it will. However, the Torque Technology docs need a lot more than just new tutorials. Which brings us to...

Organization

If you've been following any of the various documentation feedback threads in the forums, there has been a major demand for re-organization of what docs are available to the community. Contrary to popular opinion, there is a ton of very useful tutorials for the various Torque engines. However, these tutorials are scattered across the forums, GG resources, TDN, and personal websites with no GG affiliation. 1/3 of my job is to locate and consolidate these resources. This is why we have new landing pages for all of our engines. I'll talk about those in just a minute. I have to organize more than just existing content...for those of you who have been contributing, you'll notice I have also been organizing all the feedback and doc-related contributions from the community.

The Doc System

This part of my job has been unknown to the community. Previously, there was not much of what you could call a "system" for our documentation. The Doc System, previously (and jokingly) code named "Project-X Zombie Raptor," is my long term project as Documentation Engineer for GarageGames.

Over the years, various tools have been developed which allow previous doc writers to generate new content and formats. Those who wrote Torque docs before I came on board spent a decent amount of their time developing these tools and trying to plan for the future.

Now that I'm at the head of documentation efforts, I am consolidating those tools and plans. The other two components (content generation and organization) feed directly into The Doc System. Simply put, The Doc System is all the new technology and design that will allow the doc team to generate new content and deliver it to you as frequently as possible, independent of engine point releases.

The Documentation Team

Quite a few community members believe I am the first and only documentation person at GG. I've said before that I am a part of a documentation "team". Now, if you have any complaints or suggestions about documentation, you should still e-mail and talk to me directly. However, I have relied on the following GG employees to get this project off the ground and out the door.

The tools I use to generate the new docs, such as the TGEA Official Documentation, were created by Matt Fairfax and Matt Langley. GO TEAM MATT!

The person responsible for the awesome artwork and web code of the new landing and engine pages is Jason Hetu. Jason also helped with the design, making sure we kept things attractive, clean, and organized.

While you won't find it in her profile, and though she might argue, I'm going to count Deborah Marshall as a member of the documentation team. Deborah is the person I report to. She keeps me in line, organized, and motivated. I may be driving the documentation effort, but she has the keys to the car. At the very least, she provides feedback and performs edit passes on what I submit.

Assisting with QA, is Kenneth Holst. Checking all of these new pages for dead links, web errors, and so on would have taken a lot more of my time if I was alone.

Of course, we can't forget about the various engine devs who authored the hundreds of engine reference docs, like Stephen Zepp and other writers I have yet to track down =).

Rock Star Community Members

When I created the documentation threads in the public forums, I had faith that I would receive positive, constructive, and overwhelming amounts of feedback. I was not disappointed =) As with this first major doc update, I will be drawing from the community to find out what new content I should create and how it can be organized.

For this particular update, I chose to focus heavily on updating the TGB and Artist doc content. TGB was chosen because it has the most amount of features (Doc System, not engine) I wish to utilize. I also chose Artists because they have received the least amount of documentation attention over the past few years. If you go to the TGB Doc Feedback Thread or the Artist Feedback Thread, you can read how much the following users have helped make this release happen:

If you are TGB developer, you will be happy to know that I addressed nearly every single issue and suggestion posted by these awesome TGB users:
Jeramy79
Patrick Shaw
Shaz
Oscar Taylor
Mike Lilligreen
amaranthia
Kevin James
BlueRaja
James Ford

I am not an artist, so the following community members posted feedback that was critical in creating the new Artist Landing Page:
L Foster
Benjamin L. Grauer
Joseph Greenwalt
Mark Dynna

I can't stress enough how important the documentation feedback threads are. In my eyes, those who post are rock stars and are helping out the entire community with each suggestion. I'm happy to shine a spotlight on them for their contributions. Awesome work, everyone!

Conclusion

So, this concludes the second part of my major documentation announcement. I could have posted several more images and descriptions of the new doc pages, but I want to give you all a chance to browse through. Remember, any bugs, suggestions, or criticism should be posted in the various documentation feedback threads. You can also e-mail me directly using the address posted in my profile.

Adding new landing pages and online documentation is just the first step. I have to say, it's one helluva first step! I'm about to start a cycle of heavy content generation for all the engines, but in between I will be working on The Doc System.

If there are any major updates about content or system updates, I'll be sure to post a new .plan. Thanks for taking the time to read through all of this, and thanks to everyone for their help thus far.

In the mouth of madness...

MAJOR Documentation Announcement 1

Michael Perry — 2008-07-11T00:12:23+00:00

Part 1...

Hey everyone. Thanks for taking the time to read this blog. On top of the GG community reading this, I've sent a link of this blog to my friends and family as well.

This is indeed a HUGE announcement, but it requires an introduction. I never really introduced myself to the GarageGames community...soooo...

This is me...(taken in Englewood, FL)

For those of you who don't know, I've been working two jobs since GDC 2008 which was this past February. One was my full time job as a simulation programmer in Orlando, FL, working for a Department of Defense contractor. The other was a part time contractor for GarageGames, writing documentation for their game engines.

While at GDC, I finally got to meet some GarageGames employees that I've only spoken to online. Thanks to the help of Deborah Marshall I managed to get an introduction to Matt Fairfax. He recognized me from of the free tutorials I wrote for TGE and asked me if I was willing to create official docs on a part time basis. I jumped at the opportunity, having always wanted to become a GG Associate and help the community.

Surprisingly, I've really enjoyed writing Torque documentation and feel like it's helping everyone out. The only thing that's bugged me is that I just don't have the time to work on documents with my current job. So, recently I had to make a tough decision.

I haven't been happy working at my day job for some time. I still love programming; I just don't think developing serious simulations is what I want to do.

That's why I put in my two weeks notice. I'll no longer be working as a simulation programmer...

That's not all

After discussing it with the love of my life, Heather, we've decided it is time to see another part of the world. At the end of July, we are moving out of Orlando. If you haven't guessed by now, we already know where we are going and what we will do:

That's right; GarageGames has decided to hire me on full time as a Documentation Engineer. Due to the encouragement and support of Deborah, Matt, and Brett Seyler, I was convinced that I should not work remotely. That means GOODBYE FLORIDA:

(taken in the Florida Keys)

-and-

HELLO EUGENE, OREGON!!

(taken from Skinner's Butte)

We have hired movers, and at the end of the month we are piling ourselves, some luggage, and our dogs into the car for a cross-country road trip. I'm happy I'm not making this trip alone. I could not and would not do this without the love and support of Heather

Heather and I(taken in the Celtic Ray)

Though I will not miss Florida, particularly the hurricanes:

Aftermath of Hurricane Charlie(taken in Orlando by me, 1 day after)

I will miss my friends:

Me, Heather, and Tina(taken in Tampa, Red Sox vs Rays)

Me, Heather, Nikki, Kris, and Justin(taken on the island I rented, Dog Island)

And I will most definitely miss my family:

Heather and our sister Nikki(taken in our boat on the way to Dog Island)

My New Family(taken in the Florida Keys)

So that's the big announcement folks. Thanks for taking the time to read through all of it =). I'm very excited to move to a new state, and to start working full time producing documentation for the GarageGames community. My co-workers are some of the most awesome people I've ever had the chance to work with. This is the definition of an adventure.

There's no turning back:

A big chapter in my life is closing, but the one I'm starting is the greatest of all. To all my friends and family in Florida...

Goodbye...

- Michael "Mich" Perry

Part 2 coming soon...

What do you think about Documentation?

Michael Perry — 2008-05-15T14:10:25+00:00

***Greetings all!***

Let me get it out of the way right now:

This is a NO frills .plan. I wish I had some pretty pictures or wicked exciting news, but this blog exists purely for informative reasons. I'm tired, I just got back from an hour long dentist appointment, and I can't have my morning coffee because it keeps spilling out of my completely numb mouth. So, please forgive me if I can't scour the internet for LOLCat pics to post here =)

DOCUMENTATION
A dreaded word....Everyone WANTS it, a lot of people hate writing it, and the writing process will NEVER be finished since new versions of the engines are being released all the time. Thankfully, there is a group of people who still want to do the work, and even one insane person who actually LOVES writing documentation...ahem...

TGEA Started It All
During the TGEA 1.7 beta, I created a thread in the private forums: TGE 1.7 Documentation Feedback. The purpose of the thread was to provide a central location for TGEA users to post their feedback, criticisms, and suggestions for the new docs. The response was overwhelmingly positive, constructive, and key to getting new docs and fixes to the user for the release.

So, it's time to show the same attention to the users of the other awesome Torque engines. Stephen Zepp has created a thread in the TGB area, and every other engine has its own as well. Going a step further, the new threads are posted in the PUBLIC area, just to show some love to the people who have yet to purchase a SDK. Every opinion counts, and your feedback will help out in more ways than one. =)

TGEA Documentation Feedback
TGE Documentation Feedback
TGB Documentation Feedback
TorqueX (TX) Documentation Feedback
TorqueX Builder (TXB) Documentation Feedback

In each thread, there is an explanation, purpose, and suggestions on what we are looking for. Each thread will be monitored carefully, so let's get this rock rollin'

Edits: OK, I had to sneak in images. The plan was just too boring =)

What is Ars Moriendi? (images)

Michael Perry — 2008-03-21T17:06:32+00:00

*Notice* - This blog contains images that may take a while to load. Also, this is a MASSIVE blog, so only those who are not feint of heart and interested in learning about the COOLEST SURVIVAL HORROR EVER, should stick around =)

I have about 4 .plans I've saved to post on slow, rainy days. All of them have to do with the game being developed by my Indie team, Zombie Shortbus. Since I cannot foresee any such slow days happening for me....ever again =)....here we go.

Up until GDC I was wearing many hats for this project: Project Lead, programmer, recruiter, website developer assistant, designer. We pretty much have a person in each of these roles, but I was trying to lend a hand in each area until I could build up the team. Because of the events that occurred at GDC, I've come to realize that I cannot write documentation for GarageGames, work my day time job, and perform multiple positions for Zombie Shortbus. One would most certainly feel OVERWHELMED

First and foremost I am a game developer, and want to get a project out the door and into the world. So, one by one, I painfully took off my hats and shredded them. All that remains is Project Lead. This only requires me to run 1 meeting a WEEK and send out e-mails, which gives me all the time I need left over for documentation, day time job, and the family.

So, that leaves only one conclusion: find people to replace my vacant positions. I've found a person who help out with the website, set a deadline for the game doc to be completed, informed my team of the changes, and will now be looking for programmers and artists to jump on board the project.

So, what is Ars Moriendi?

The Idea
In 2004, a team of students was finishing their last few months of Full Sail's Game Design and Development degree. The last class that every Gamer student must take is "Final Project." For the Associate's Degree, a team was required to make a game in 3 months. The games usually amounted to polished demos, but the task was extremely daunting. During the Associate's Degree, students were allowed to use 3rd party engines if they desired (a rule against using existing engines has been put into place for the Bachelor's Degree).

One of the more popular engines for students to use was Torque Game Engine. The team I belonged to, Malignant Entertainment, was one such team. Thanks to Heather Pettigrew's (my fiancee) brilliant concept, we began to work on a multi-player survival horror similar to Resident Evil: Outbreak. We called our game Ars Moriendi: The Art of Dieing. While Malignant Entertainment could not get in every feature we desired, we were deemed to have the most game play and honored with the final showing of games at the live demonstration event in front of hundreds of people.

The team dispersed after graduating, but the idea of Ars Moriendi stuck with me. I continued my research and development with Torque Technology for several years following graduation. After forming Zombie Shortbus with several friends from Full Sail and work, we spent a year attempting experimenting with game project designs. Finally, we decided to resurrect Ars Moriendi. With all the advancements and upgrades made to Torque, particularly Torque Game Engine Advanced, we know we can finally get in all the features and game play that did not make it during the Full Sail days.

The Inspirations
Heather's Sunnyland game concept
Resident Evil: Outbreak
Phantasm II - IV
Poltergeist
World War Z
Zombies Ate My Neighbors
Dawn of the Dead
Dead Rising

The Game
Ars Moriendi: The Art of Dieing is a multi-player survival horror. Players must survive in a world that has been turned upside down by catastrophic events: the dead rising, invasion of poltergeists, collapse of governments, mass hysteria and insanity, global infection and mutation, and more. There appears to be no source to attack, no way of saving the world. Those that remain untouched by possession, infection, and insanity have only one option. They must constantly move and survive the horrors they encounter. Humans are again reduced to a life of scavenging and nomadic ways.

The game itself will consist of multiple scenarios representing a new location the survivors must pass through. A total of 4 players can join together to attempt to survive each scenario and move across ruined America. The primary goal is to survive, which means you can work together as a team, or take advantage of each other's abilities with the end goal of surviving on your own.

The Survivors
As a player in Ars Moriendi, you can choose one of 4 characters to play. Each character class has its own strengths, weaknesses, unique abilities, and personality.

Security Guard - An ex-cop, whose age and past injuries have reduced his career to that of a security officer for a mega retail store. While he is the slowest and least agile of the survivors, his training with fire arms and raw strength make him an invaluable source of offense. He will start each scenario with equipment consisting mostly of weapons, which leaves him the least vulnerable in dangerous situations. While his priority is surviving in a in a world of fallen society and constant terror, he knows he will encounter others who need leadership and can offset his weaknesses.

Construction Worker - The world fell apart while he was on the job. While his strength and starting equipment can make him an offensive force, his field of expertise will allows him to control his environment. He could use his nail gun to take down a few lunatics before running out of ammo. Alternatively, he can use his construction skills to build barricades that could keep out dozens of threats and allow his group to avoid conflict all together and make an escape. His utility belt allows him to carry additional small objects (ammo, healing supplies, tools), so he is better prepared to survive in desperate situations when extra supplies are needed. While the skills he has mastered in his past career make him capable of surviving alone, he is accustomed to working with a crew and will gladly join up with anyone who can bring a useful skill to the group.

College Girl - Usefulness is not always determined by strength and weaponry. While she is not an offensive force to be reckoned with, her agility and acrobatic skills are not to be taken lightly. While she can use some light weaponry, she is much more useful as a diversionary target. When it comes to escape, no one can out maneuver her. Her skills and intelligence separate her from a world of chaos and insanity. On top of accessing areas that other survivors cannot, she is able to save her team members from fatal harm by distracting threats via aggressive movements and sounds. Knowing the monsters of this fallen world will target her for her weakness, she is refuses to be a victim. She will run as long as she needs to, and seek the protection of other survivors that are better supplied and armed than she is.

The Kid - The youngest and most vulnerable of the group, The Kid knows he must find a group of survivors who can protect him. Unable to properly use weapons, he has found another way of aiding the group. Using his multiple pockets and large backpack, The Kid is able to act as a "mule" for the other survivors. Out of everyone else in the group, he can carry the most weapons, healing supplies, ammunition, etc. He is also the definition of "Johnny on the Spot." His ability to hand out supplies quickly makes him the survivor you want to keep close at all times, which meets his goals perfectly. His small stature allows him to move quickly and get into tight spaces. However, being a moving supply point and weak, he is the survivor most likely to be targeted by hostiles. While happy to be apart of a group, he will not waste his supplies on other survivors who provide no useful way of protect him.

That's the synopsis of the game. Below, you will see concept art created for some characters and one of our levels. I'll post progress on the game, as well as entries from our design and tech docs to document our development process.

Character Concept Art

College Girl

Needs more weight and muscle, different outfit

Construction Worker

Needs completely different outfit, utility belt. Keep the mullet and weight

The Kid

Needs a backpack

Condemned Children's Hospital Map Concept

Scenario layout

Big News, and New Documentation

Michael Perry — 2008-03-14T17:20:11+00:00

*Disclaimer* - I am running on about 8 hours of sleep for the past three days, so forgive any incoherent babble that comes out during this .plan. Also, no pictures...sorry. I've created about 70 pictures in the past week, and am too tired to do anymore.

New Documentation
I'll start with this subject since this is why you probably clicked this .plan to begin with.

Some readers may remember the 3 part documentation series I started a while back:

The past month or so I've been having a real itch to go back and expand on those, add a few more entries since the demand has risen. Despite having a day time job, running an Indie company on the side, and hanging out with my girlfriend(sort of) and dogs, I always found time to relax. There were lulls of craziness, but there was always some chill time.... That's when I usually wrote the docs.

That was BEFORE GDC 2008. (My experience of GDC is at the bottom of this blog)

So, while hanging around the GG booth waiting to introduce myself to Matt Fairfax, I had a chance to talk to Deborah Marshall. When I introduced myself, she knew my name from my postings here on GG (very flattering btw). She said I should talk to Matt, but some random programmer was chatting his ear off about shaders. Smoothly interrupting the conversation, she wedged me in so I could say "Hi."

For some weird reason, Matt knew who I was too (wtf?). He mentioned seeing my tutorials, and asked if I would be interested in working on official Torque documentation...

Official Torque Documentation!

Sure, some people have found my small resources useful, but what's the best way to help every single Torque License holder? Well, my answer was quick and obvious: Hell yes!

So, all that extra free time I used to have: POOF! Gone! I started working as soon as I was given my assignments. I even bought a $1,500 rig with dual monitors and an 8800 GTS just to help with my doc writing (yeah, that's how I'm justifying it, leave me alone).

So, that's the reason why I'm running on practically no sleep right now.

I'm wicked excited to be working with the GG developers, and ecstatic that I get to help out the rest of the community on this large of a scale.

And that's not even the big news...

THE BIG NEWS!!!1!1!one
I finally gathered the courage (and funds) to propose to my girlfriend. After four years, we have finally taken the next big step.

Few know how happy this makes me. If it weren't for Heather, I would not have finished school, probably wouldn't have made it to my current level as a game developer, and more than likely wouldn't even be a member of the GarageGames community. So, if you like any of my future resources or work, she deserves as much credit as I would receive =)

GDC 2008
Ever since I learned of its existence, I've always wanted to attend GDC, but ever had the funds. This was my year: my day time job sprung for the All Access Pass, flight, hotel, and food. I mostly attended the Indie Games Summit, which was awesome beyond all awesomeness.

I also got to see live game play for Prototype and Smash Brother Brawl (pre-USA release). On top of everything else, I finally got to meet some GG employees and get involved in some of their GDC shenanigans:

Attended the "The Web Game Renaissance" where Josh Williams talked about Instant Action.

Attended the IGDA Party where I finally got to introduce myself to Ben Garney

Attended Ben Garney's Tamarin session (very cool stuff)

Hung around the GG Exhibition Booth:

-Got hands on time with Fallen Empires: Legions
-Hung out with Deborah Marshall
-Got introduced to Matt Fairfax
-Had a comical discussion with Davey Jackson
-Got really cool swag, including my favorite new t-shirt (Instant Action short sleeve)
-Attended the GarageGames suite night where I met Talana Fairfax and other GG people

It is no exaggeration when I say GDC has changed my life. I've learned so much, was offered an amazing opportunity, and had a frikkin' blast in the process of it all.

Well, wish me luck everyone! For both the documentation and the wedding plans.

Next blog: Pictures, Ars Moriendi game information, and hopefully a new AFX Creator update.

Closing thought: zzzzZZZzzzz

*Forgot To Mention* - Also had a meeting with Brett Seyler in regards to my day time job working on a new project. Sounds, boring, I know...but meeting with Brett was critical to helping us out. Also, got to say "Hi" to him afterwards in less formal conditions. Cool guy =)

New Resources and AFX Creator Demo

Michael Perry — 2008-01-24T18:24:31+00:00

Greetings all...

A SAD DAY
Before I get to the good stuff, I wanted to go ahead and put out a memorial statement:

On Jan. 16, 2008, Scott Pettigrew passed away. He left behind two daughters: Nikki, who is like my sister, and Heather, who is my soon to be fiance. To me, he will forever be the greatest man who ever lived, and I will always consider him "Dad."

A RESOLUTION

I completely skipped writing a "1 year Later" blog on my birthday due to the amount of stress and work I had to get through. The whole purpose of this .plan is to show off the results of my New Year's Resolution. For 2008, I have resolved to complete projects I promised during 2007 and "make good" on commitments I started. I am only working on 2 projects at a time to ensure focused and productive results.

FREE RESOURCES

At Zombie Shortbus, we have designated Steve "Asian Steve" Ngu as our lead level developer/designer. Over the past few months, he has been teaching himself Torque World Editor with a little guidance from me. He has recently been asking about features that would be handy to have, but are not in stock Torque. In an effort to make his life easier, and provide more eye-candy for mission creation, I added some environmental enhancements and a packaging system.

So, why be selfish? What's mine is your's:

Environment Package Save/Load System

Super Environment Resource

AFX CREATOR TOOL DEMO

Last year, I started a project that would allow AFX developers to create selectrons and effects using a Graphical User Interface (GUI). The purpose of the tool is to rapidly create the datablocks and objects without writing the scripts by hand.

So, after finishing the above resources, I now had some pretty kickin' code that I knew I could use in other projects. AFX Creator has been a mess for a while now. I was using Torque Script FileObject to write out every single datablock line, and as most AFX users know, the number of datablocks created for FX quickly adds up.

I replaced the FileObject disaster with the code I used to create the Environment Package System. With that approach in place, I was able to writer cleaner code more quickly. So, if you are an AFX license holder you can head over to the OFFICIAL THREAD. The demo currently supports the creation of selectrons.

ARS MORIENDI

Information on the first game project by Zombie Shortbus will be released soon.

There is still so much to do, but there is no need to remind me. Right now, programming and finishing my projects is what is keeping me sane: unless you are posting feedback about what is available, don't bug me. I don't need the distraction =)

Environment Package System

Selectron Creator

Zodiac Creator

Component Gluer

Torque School Instructor

Michael Perry — 2007-07-18T17:58:08+00:00

Greetings all!

In no way am I under the delusion that I have some kind of following for my recent tutorials and documentation, but I felt it necessary to explain why there have been no follow-ups. I was approached by Dave Young of Dream Games, Inc. to be an instructor for Torque School. This is an amazing opportunity that I could not pass up. TS will be the vehicle I've desired for reaching a larger portion of the community. As much as I love programming, I enjoy helping others a lot more. I will still make every effort to support the community and supply resources and documentation, but I will now use Torque School as my main median of instruction.

For details on Torque School, head to the website and be sure to read Dave's .plan. As for my participation, I am teaching the Introduction to Torque Game Engine (TGE101) and Comprehensive GUI Certification (GUI101). Two other classes I have planned are Custom Tool Creation Using Torque Tech and Special FX systems.

The TGE101 and GUI101 classes are very informative and helpful for both veterans and newcomers to Torque Tech. I came up with the Tool Creation class while working on my afxWeapon Creator Tool and AFX Effect Creator. This class will show you how to strip down and optimize Torque, and build a game content creation tool from scratch. The Special FX class will probably be the most fun to take (and teach). In great detail, I'll be covering the FX systems for TGE (precipitation, particles, lighting, AFX) and how to effectively use them in a mission.

As for the other courses not taught by me, I'll be sending my Zombie Shortbus team mates through a few, and probably take one or two myself =)

Hmm...time for the obligatory .plan image...

I went on a gambling cruise on 7/7/07. I went on the ship with $200. After playing about 15 quarters in a slot machine, I won around $240 dollars. Having doubled my money, I decided to tuck away the cash and just dump the remaining $40 into another slot machine. After all, no one wants to walk around with $40 in quarters. . .well, apparently I am very lucky when it comes to gambling, because I managed to hit the jackpot on a different machine, winning about $2500. I finally got my XB360, HD TV, and let my girlfriend go on a shopping spree. Don't believe me? =)

It's been a good past few weeks =)

afxWeapon Design Blog #2: Fire Sword

Michael Perry — 2007-06-20T14:02:18+00:00

[Oh GG web-deities, please do not smite me for double blogging]

Greetings, again, all! I really wanted to separate the announcement and tech behind afxWeapon from the actual design and implementation of a specific effect: Fire Sword. To see the full code of this effect, head over to the afxWeapon Resource, download the files, and open up afxWeapons.cs.

Once the afxWeapon resource is integrated into your code, it's safe to say you have 4 major steps to go through to reach a final result:

Step One: Design:
I love the concept of a fire or flame sword. In an RPG, or life, it's hard to beat the damage done by the blunt trauma of a swung weapon, the slice damage of the edge, and the after effect of flaming goodness =).

Designing a sword that appears to be on fire was not difficult. To give my Fire Sword a little quirk, I decided on 5 fire orbs that swirl around the tip of the sword, as opposed to the whole sword being on fire. Also, since this was the first afxWeapon test, I wanted to develop using assets and effects already available to me. Great Ball of Fire to the rescue! GBoF is a very impressive spell found in the Arcane.FX Demo. I was able to follow the spell's pattern to create my Fire Sword.

Figure 1: Great Ball of Fire Spell

Step Two: Modeling the weapon
With the very powerful AFX constraint system being a key component in afxWeapon, some model adjustments for the sword needed to be made.

I used the broadsword from Tridinaut's Medieval Weapon Pack. Using Maya, I opened up the broadsword.obj, and lucky for me, it was completely raw (no Torque hierarchy or nodes or nothin'). This gave me the freedom to set it up specifically for my system.

After the usual set up of Torque hierarchy and proper scaling, I had the sword visually where I wanted it. Based on some hints for AFX Spell Design Blog #2: Fire Tower, I set up three major components on the weapon.

First, I moved the bounding box up so that the bottom of the box was in the middle of the sword handle. This basically tells Torque that the origin of the sword is in the center of the handle, which in the end determines where the sword gets mounted on the player. Next, I placed two mountpoints on the sword. One was placed in the middle of the blade, and the other placed at the tip of the sword. I named these nodes bladeMiddle and swordtip, respectively. With the help of maya2dts, I exported the model and tested it in Show Tool and Weapon Crafter to make sure everything was fine:

Figure 2: Maya Representation of Sword

*Note* - Notice where the bounding box is located, and the green point on the sword tip is the "swordpoint" node.

Step Three: Effects List and Creation:
Based on the design, I had 3 major effects to implement: the actual sword representation, swirling fire orbs, and an equip effect. Any AFX effect can be added to an afxWeapon. If you wanted a permanent zodiac under the player while he's wielding a particular weapon, you are free to do so. For my effect, I wanted something simple to happen when the player equipped the sword. I also wanted a permanent effect while he held on to it.

Before we get into the pretty effects, I'll cover the core aspects of the actual weapon, and how I got it in using AFX. Keep in mind, that when making an AFX effect, you first create a component or modifier, then you WRAP it up.

Normally, when you want a weapon in the world, you have to make an Item datablock. To equip the item to the Player properly, you then have to make a ShapeBaseImage datablock. In AFX, it's so much simpler and cleaner.

The component effect is the afxModelData, in which I specified two fields: the shape file and a flag specifying the sequence of the model to animate with whatever it mounts to. Every field in the wrapper (BroadSword_EW) is crucial. The specified effect is the modelData. To get the mounting effect, I specified the constraint as "wielder.Mount0", which is an existing mount point on Kork.

The string, "wielder", is very, VERY, important to the afxWeapon system. The class internally notes (in C++) that the wielder is the person who calls the method, equipWeapon(). If you use "caster" or "player", the weapon will not mount properly, and the effects won't display.

Two important fields I learned about while first scripting this weapon allow you to specify an effect as a constraint:

...
effectName = "BroadSword";        // Give the effect an internal name
  
isConstraintSrc = true;           // Turn this effect into a contraint source
                                               // to allow mounting of other effects
...

Without this code, the weapon you see mounted to the Kork is the equivalent of a hologram. The fire orbs will not know where to swirl without these fields being specified.

Figure 3: Broadsword Effect

I decided on a shock wave effect to appear when the fire orbs combusted. An afxZodiac works perfectly for showing effects on terrains, so I followed the GBoF example and created a zodiac that grows over time, using the weapon wielder as the starting point.

The component effect was the actual afxZodiacData, which contained the texture, radius, rate of growth, and rotation rate.

The effect wrapper needed to know what effect to display and where to start, so I specified the new zodiac and for the constraint I chose "wielder."

datablock afxEffectWrapperData(FireSword_EquipShockwave_EW)
{
  effect = FireSword_EquipShockwave_CE;
  posConstraint = "wielder";
   ....
};

For the rest of the shockwave, specifying a fade time and lifetime gives it a smooth transition out of the scene, plus it looks darn realistic =)

Figure 4: Shockwave

The last effect is the swirling ring of fire made of 5 flame orbs. This effect is more or less ripped straight from GBoF. I made three major changes to get the desired path and appearance of the fire:

The spinData used to modify the fire orbs had an increased spinRate
I changed the axis on which the orbs are offset and rotate
I changed the constraint of each fire orb wrapper

// In each FireSword_FireOrb effectWrapper
...
posConstraint = "#effect.BroadSword.swordtip";
orientConstraint = "#effect.BroadSword.swordtip";
...

Finally, we see the reason for giving the BroadSword effect a name, specifying it as a constraint source, and putting a "swordtip" node in the actual model before exporting.

posConstraint specifies the effect (or object) the fireOrb should constrain ("mount") to. #effect specifies that we are looking for an effect, BroadSword is the effect, and swordtip is a specific point on the effect we constrain to.

I discovered orientConstraint as a result of a graphical "bug" in my ring of fire. Without orientConstraint, my effect looked like this:

Figure 5: Ring of Fire facing wrong direction

After specifying the orientConstraint, the ring of fire always faced the direction of the swordtip node.

Figure 6: Correct Ring of Fire orientation

The last part was building the afxWeaponData. The model, shockwave, and fire orbs were dropped in using the addEffect field.

The rest of the fields in the afxFireSword datablock were the actual RPG elments, such as damage, range, skill, and so on.

Step 4: Implementation and Testing

To display an afxWeapon effect, a Player object must call the ConsoleMethod equipWeapon(afxWeaponData).

I really hate typing in the console, especially when I have to repeat a process often during debugging and experimentation. So, I created an ItemData datablock and set it's pickUpName to the name of my afxWeaponData datablock: "afxFireSword".

The onCollision function for the new ItemData calls the equipWeapon function for me, using its pickUpName to let the Player know which datablock to use. All done!

Well, I hope my first effect design blog was helpful for those planning on using afxWeapon, or any AFX module. You can now see why I made the blogs separate. Have a look through the resource, and let me know if you have any questions.

I am also going on the record and saying that Arcane FX is the most awesome Torque Tech to be released since the actual game engine itself! Developing for it is just as fun as playing with the final results.

More to come....next up, Thor's Hammer as an actual afxWeapon. =)

afxWeapon Effect Design Blog #1

Michael Perry — 2007-06-20T12:26:41+00:00

[not to be confused with the AFX Spell-Design Blog series by Matthew Durante, though they are the inspiration for this blog]

Greetings all! With all the recent AFX related blogs popping up (great work Gareth Fouche and Gavin Bunney), I thought I'd announce some AFX tech I've been working on.

While working on Zombie Shortbus's in house tools, Weapon Crafter and AFX Creator, I realized I was missing quite a bit of tech to make these tools usable and effective. The first major piece of tech required grabbing a list of datablocks by their type and storing it in a script variable. With a little help, I came up with a solution, which was so useful, and capable of many other applications, I released it as a resource: Code: List Datablocks by type.

The next glaring absence in the code was a base weapon class and melee system. There are resources available, but none provide an actual base weapon class. I decided to make a simple weapon class that had your basic RPG functionality (min damage, max damage, stat modification, speed, type, etc). Well, what good is a stat modifier without player stats? So, I implemented a simple stat system for the Player class.

At this point, there was nothing that distinguished my weapon class from every other starter melee system out there. This is where AFX came to the rescue. I wanted weapon decorators, equip effects, un-equip effects, on-hit effects, and a simple way of mounting the weapon to the player without all the usual mounting procedures.

Formula: WeaponClass + afxEffectron = afxWeapon

afxEffectrons are amazing modules. Anyone who has ever had problems with mounting weapons and equipment on a player, this effect is your salvation!

So, in this blog I'll show you the final script result (plus screenshot), and in my next blog I'll break down the design and creation of The Fire Sword afxWeapon to get everyone started on their own afxWeapon creations.

Create the Fire Sword datablock:

datablock afxWeaponData(afxFireSword)
{
   duration = $AFX::INFINITE_TIME;     // Effect lasts until unequipped
   execOnNewClients = true;            // New clients must know about it
   
   // Add the broadsword effect
   addEffect = BroadSword_EW;          
   
   // Shockwave effect that animates on equip
   addEffect = FireSword_EquipShockwave_EW;  
   
   // Add 5 fire orbs that swirl around the sword tip
   // Lasts as long as the weapon is equipped
   addEffect = FireSword_FireOrb1_EW;           
   addEffect = FireSword_FireOrb2_EW;
   addEffect = FireSword_FireOrb3_EW;
   addEffect = FireSword_FireOrb4_EW;
   addEffect = FireSword_FireOrb5_EW;
   
   /////////////////////////////////////////
   // WEAPON DATA AND STATS 
   weaponName = "FireSword";           // Give it a name to reference
   
   minimumDamage = 5;                  // Does a minimum of 5 damage
   maximumDamage = 10;                 // Does a maximum of 5 damage
   weaponSpeed = 3;                    // Standard weapon speed
   weaponRange = 1;                    // Player must be within 1 unit of target
   weaponSkill = 5;                    // Player must have at least a "5" in edged weapons
   weaponType = 0;                     // WeaponType is 0 (1 handed edge)
   statMod1 = "Might 3";               // Add 3 to strength on equip
   statMod2 = "Wisdom -2";             // Subtract 2 from wisdom on equip
   // WEAPON DATA AND STATS 
   /////////////////////////////////////////
};

One method of equipping the Fire Sword, colliding with an item in the world:

datablock ItemData(broadSwordData)
{
   // Mission editor category
   category = "Weapon";

   // Add the Ammo namespace as a parent.  The ammo namespace provides
   // common ammo related functions and hooks into the inventory system.
   className = "Weapon";

   // Basic Item properties
   shapeFile = "~/data/shapes/weapons/broadsword_maya.dts";
   mass = 1;
   elasticity = 0.2;
   friction = 0.6;

   // Dynamic properties defined by the scripts
   pickUpName = "afxFireSword";     // IMPORTANT!!!!!!
   maxInventory = 1;
};

function broadSwordData::onCollision(%this, %obj, %col)
{
   // NEW CONSOLE METHOD: EQUIP THE FIRE SWORD TO THE PLAYER
   %col.equipWeapon(%this.pickUpName);
   echo("Fire Sword Equipped");
   %obj.respawn();
}

How about that? If you don't count the special effects (shockwave and fire orbs), it takes 2 datablocks to make the weapon, 1 function call (Player.equipWeapon(afxWeaponData) to use it, and you are ready to start scripting your combat and inventory system.

The next blog (or two), will show you how I set up the weapon in Maya, designed the weapon effect, and scripted the datablocks to make it all work.

Screenshot Section