Star Wars Galaxies develop team released new dev diary for the game, which focus on game characters movement and so on.

Hey there! Im Thomas "Hanse" Eidson and this is the fourth designer diary in the series Ive been writing over the past several weeks. The first one outlined the specifics of what my job entails from a high level perspective. The second diary reviewed a player versus environment balance approach I used. The third diary sketched out how the Jedi expertise was created. In this fourth diary, I will go over my responsibilities with the beast mastery system.

As you may already know, I am a system designer for Star Wars Galaxies. A system designer, in short, makes broad decisions for entire sections of the game. Instead of focusing on small details, such as which way a building should face, we focus on how all the buildings should function. In this way, we are responsible for large changes to the game.

When the beast mastery system was first discussed, we simply called it a new pet system. Our goal was to allow a player the ability to control one creature at a time in the game. We wanted the pet to grow, eat, fight, learn, and have a personality. The range of pets available would be large and diverse. A system of discovery would need to be implemented so that the beasts would be craftable. Also, these pets would have special abilities and attributes.

Blixtev asked me to code the backbone system for the beasts. A backbone system is pretty much the heart of any system. It keeps track of what is going on and what is possible in a system. Ill go into this in detail further into this diary.

When the brainstorming for the system began, I shared an office with Tunso. I began writing what would be needed for a backbone pet system. Blixtev told me that he did not want to reuse the old pet system code. This system would need to be created from scratch. Since we could not call this system a pet system, as a pet system already exists in the game, Tunso and I brainstormed up the name "beast" to describe the system. My brainstorm sessions with Tunso all had filenames referring to the beast system written on the grease boards we used. After that, the name stuck and the system was officially called the "Beast System".

Writing a new system from scratch is not an easy task. You have to consider many issues, which we are still finding loopholes with to this day. In fact, I just fixed a logical issue for the artificial intelligence of beasts a couple hours ago, which is going out with our next bug bash. Organization of the objects that will be interacted with is key to such a complex system. Here is a chart of my original brainstorming. The chart follows how the current pet system works, but from the perspective that the object controlled is a beast.

Of course, this is a simplistic diagram, as Im omitting many technical details such as file names, directories, etc. You can see from the chart that I needed a beast library that had common information for the beast system that is constant across all other systems. I needed a control device for your datapad. I needed a beast object that you could control. Lastly, I needed a way to create your control device in your datapad.

Youll note that I do not outline the incubator or the incubation process. We had five designers working on this system. Other designers worked on different sections of the system itself. The system is too large for one designer to have finished in such a short period of time. Other areas of the beast system that designers worked on were the beasts that would actually appear in the system: expertise, special abilities, happiness, loyalty, incubation, incubation interface, enzyme collection, DNA collection, legacy pet conversion, pet bar, art requests and art revisions, and the crafting elements for the system.

The areas I worked on were artificial intelligence, datapad interaction, droid interaction, vehicle interaction, mount interaction, familiar interaction, PvP interaction, beast calling, beast storage, beast basic combat (defensive, passive), beast posture (follow, stay), egg to beast control device conversion, beast growth, combat AI, and more.

At the beginning, I needed a framework to get a beast in the world. I began on the Beast Library. This library would be the central location for all common functionality. A designer can look in this library and see how an egg is converted to a beast, how a beast is called into the world, how it is stored on a control device, how a beast can be happy or sad, how beasts grow as they gain levels, and many other common functions.

Once I had a common framework, I made bogus data tables with information that other designers would fill in. The two main data tables were the types of beasts that would use the system and the attributes they would have. After I completed a skeleton library and a skeleton control device, I tested it out by calling my first beast. The beast I used was an angler, due to its name being alphabetically at the top of my bogus beast data table.

The angler was the first beast called with the system. It just sat there emotionless. It did not wander. It could not be damaged in combat and could not damage others, as it had no combat hooked up to it. It was a regular sized angler, but level one with bogus stats. I was pretty proud to see the first beast called with the system and called the other designers over to see it, even though it was obviously far from complete. After that, I used anglers to test the beast system for the rest of the publish development (of course, they killed tons of Jabba Assassins).

As the development cycle progressed, I hooked up the ability to gain levels, experience gain (which was a huge pain ¨C it took me much longer than I expected it to take), levels affecting beast scale, beast menus, control device menus, storage, and combat. I didnt have a pet bar to test my changes with for much of the publish, so I made speech commands and radial menu options to test functionality out with.

I spent two days tweaking how the beasts would follow a person around. If youre too far from the beast, then it runs up to you (unless youre very far away, which causes it to store). When it gets close it should slow down and finally stop nearby. If you do not move too far away, it will walk up to you, instead of running. A beast should primarily stop to the left and behind of you, although it may run straight up to you. The follow code was very tricky to get right and took many hours of tweaking, restarting my server, and telling a beast to stay and follow. Once the basic follow code was completed, the combat follow code was easy .

The above screenshot shows our movement artificial intelligence debug mode.

The hardest part of the beast system was combining it with the other systems which reside in your datapad (vehicles, familiars, droids, ships, etc). The original design was to not have beasts interact with those systems. Blixtev said the second most dreaded thing a designer can hear in the middle of a development cycle¡­which was that there was going to be a major design direction change. He wanted a system to control each type of datapad system individually, which would keep a player from having a droid and a beast out at the same time. (By the way, the most dreaded thing to hear is "development cancelled" of course). I had to make a new system over all the other systems. Since all those datapad systems could "call" an object into the world, I decided to name the new system the "callable" system.

Basically, the callable system boiled down to rewriting large swathes of the droid pet system, the vehicle system, and the newly coded beast system. The callable system took me a week to write, which was a week I didnt expect to lose. Luckily, I was ahead of schedule and the loss of a week didnt impact the overall publish adversely.

During development, we pieced our systems together. The beast library grew from a meager thousand lines of my code to over five thousand lines of code between the designers working on different aspects of the beast system. The control device is pretty small at slightly under a thousand lines of code and the beast script itself is almost fifteen hundred lines long. I know I easily stared at over fifty thousand lines of code during the course of development (traced through the same lines multiple times ¨C enough to make that number much higher), between the AI scripts and callable systems in the datapad.

Thank you for reading this diary. I hope you found it interesting and fun to read¡­and ¡­ please use your pet anglers to kill as many Jabba Assassins as you can. :)