BrentOwen.com

Posted By BOwen on December 2, 2011

I’ve skimmed over the tutorials and information that came with Torque3D. There’s a lot to learn. It’s times like this when I remember why I’m not a big reader. It’s just as well, if you try to cram too much into your brain at once I have it on good authority that it will melt. I’ll just have to eat this elephant one byte at a time. (yeah I know, you don’t have to say it). Well in any case, the meal has started and I’ve sat down for a feast.

Now usually it’s a good idea to write your design docs BEFORE you start development. For whatever reason it doesn’t look like that’s going to happen this time. I’ll be sure to mention how much I’ll regret it later. It should also make for a more interesting post-mortem. I suppose we’ll see if I’m as talented as I know I am or just an idiot who has to learn by screwing up first.

So in my last post I dubbed my project SpaceCraft. So what is it? Apart from the painfully obvious “it’s a game”, it’s a game that takes place.. here it comes.. get ready for it.. in space! Here’s the High Concept:

A completely open ended, sandbox style SciFi where the player is free to do and build whatever they like within the game.

Hmm.. that sounds pretty good considering it’s the first time I put the idea into one sentence. So what sets SpaceCraft apart from so many other sci-fi games? I’m glad you asked. For starters the game will have a certain level of scientific accuracy, something which is notably absent in science fiction. The explorable universe will be substantial and players will be able to design their own spacecraft (among other things).

Yes. I know. SPORE allows you to design your own ships. This isn’t what I mean by designing your own. I mean you get to design the INSIDE of the ship as well. You can customize the components of the ship from engines to weapons. You can customize the textures. Just about anything you can want within reasonable limits.

The game will also be designed right from the beginning with custom content in mind. Importing textures into the game for example, will be as simple as placing image files in the proper folder. Custom meshes however will require a little more work but that can’t be helped. I will try to write tutorials for how to mod the game as I build it so everything should be well documented.

Starting to sound interesting? I can’t make too many promises yet. I have a bad happen of thinking big. In fact, I don’t know if it’s even possible for me to think small. There are so many other things I want to squeeze into this game and I’m looking forward to seeing the mods people make for it as well.

First thing’s first though. My first major challenge still lies before me, creating the universe! My first GUI and the basis for random universe generation should be simple enough. I already have a fairly solid idea of how to generate the data. Turning that data into a viewable in-game map is another story entirely.

Category: Commentary | No Comments »
Tags:

Posted By BOwen on November 24, 2011

For a very long time now I’ve always known what I wanted to do. In a way this has been both a blessing and a curse. I know where I am and I know where I need to be. What I have not known is the path I should take to get there and that has been a source of much frustration.

The gaming industry is not easy to break into for one such as myself. I’m something of a jack of all trades but my primary talents (I believe) are in the realm of ideas. Unfortunately, ideas are a dime a dozen as they say. So while I might have a portfolio and a resume that says I actually know things, without actually knowing someone who works in the industry well, let’s just say competition is pretty stiff.

In a way I’m thankful for this as honestly I’m not sure I working for an established developer is the right path for me to take. Indeed it is also a path that seems blocked as I’ve applied to many with no success.

The alternatives seem even more daunting. The idea of developing a game to my liking on my own is a task that seemed to me for a long time of being insurmountable. I don’t have small or simple ideas. As far getting a team together, that’s not always easy either. People who want to be serious about a project they join want to see proof that you can deliver. That’s assuming first you’re looking in the right places for people with a similar vision as yours.

I have my own issues which add to the various difficulties which I see no reason to get into. I’m not going to make them into excuses but I need to acknowledge they exist and work with what I’ve got. The bottom line is really just not knowing the right path for me to take to get from point A to point B. Sometimes we have to know the route is possible before we can see it.

Then came a little game called Minecraft. Honestly it looks like something that came out of the early 90s and yet over 3 million people have purchased a copy for 20 euro’s each and it isn’t even finished! Proof positive, among other things, that even today people will pay for good game play which is not defined by epic stories or fancy graphics. Well I’ll tell you something I know. If Notch can do it, I sure as heck can!

Now I’m not going to try to duplicate Minecraft. I don’t really need to. What I am going to do is make a game. This game I will refer to for the time being as SpaceCraft. I’m a little wearing of making a Craft game. I kinda feel like I’m doing a Tycoon but what the hell, it’s catchy. I’ll get into the details later.

Part of my process will be keeping a regular blog. I should be updating this fairly frequently. As I am only just starting this project I’ve a very long road ahead with a lot to learn. I said earlier I’m a jack of all trades which is true is many respects. I know something of programming, 3D modeling & animation, music, art, texturing, level design etc.. and this before I went to get a degree in Game Art & Design. I’ve been to several GDCs, done the workshops, attended the talks. Well let’s just say I’ve done more than the average fan boy dreaming of one day making their own totally awesome idea that’ll earn millions because after all, my ideas are just that awesome right?

My first step on this journey is getting my hands on a game engine. The affordable engine of choice is Torque 3D. Now I have the engine installed as of last night (wow I have such a long way to go!) . Along with that I’ve installed the DirectX SDK and am waiting on my account at nVidia to download the PhysX SDK. For the next few days I’ll be reading docs and working on tutorials.

What’s the saying? A journey of 1,000 miles begins with a single step? But it also helps to know where you’re going. It’s usually up to us to figure that one out. It just sometimes takes awhile.

Category: Commentary | No Comments »
Tags:

Posted By BOwen on October 29, 2009

Everyone has their own way of doing things.  Writing design documentation is no exception.  It’s one of those tasks where it can be said “there is no right or wrong way to do it”.  It’s simply a matter of style.  This is somewhat of a fallacy in that there are things you should avoid and good practices to adopt to make your design docs the best they can be.  In a sense, there is a right and wrong way to write good design docs but this can indeed vary depending on who they are intended for.   That being said there is certainly room for flexibility.

While working on some of my ideas I came to the realization that different team members simply need certain information while others do not.  Programmers need to know what they need to code.  Modelers need to know what they need to build.  Neither modelers nor programmers need to be bogged down with documentation on tasks not directly related to their work.

Let’s take my work on a dynamic combat animation system as an example.  The programmer needs to code a system that analyses the situation between two actors, calculating position, distance and call the appropriate animations.  He or she only needs to know the name or number of which animations to call but does not need any further information on the animations themselves.  While the modeler needs to understand the animations in order to properly rig the models that will perform them.  The modeler does not need to know the rules that govern which animation is called.

In this case, two separate documentations can be written, one for the programmers and one for the modelers.  This way each person doesn’t need to sift through information they don’t need and they aren’t overwhelmed with unnecessary reading.

Keeping documentation down to byte sized chunks (if you’ll pardon the pun) is something I firmly believe in.  Large amounts of documentation can be daunting and team members will likely prefer to focus on one set of tasks at a time.  A good tip I’ve decided to adopt is to try to keep a design doc down to 10 pages or less with clear and concise descriptions of the tasks at hand.  There’s no need to fill design docs with excess fluff. 

In a sense writing a design doc can be very much like any other design project.  You know it’s good not when there isn’t anything left to add but there isn’t anything left to take away. 

Formatting is largely a matter of style but like any documentation it needs to be readable.  Remember who is going to read it.  Find out if they have any preferences and try to include them if possible.  A development team has a wide variety of talents from the logical to the creative and different styles may suit different groups better than others.  Programmers may prefer a simple to-do list while artists may prefer detailed descriptions and background story for character concepts when available. 

It may also be good practice to include a glossary, either as a separate document or at the end of the design doc.  In my case, since I am writing my design docs on my own I may use terminology which may or may not be easily understood.  I therefore include a definition of key words to give potential readers a clear idea of what I’m thinking when I use those words.

Finally, I also try to keep the documentation on related tasks.  I would not for example write documentation for my random events generator and then include my combat system in the same document even if I could keep them both together under 10 pages.  I would write two separate design docs.

To sum up design docs should:

• Be as short as possible (10 pages or less whenever possible).
• Limited to related tasks
• Targeted for the reader (No unnecessary information)
• Clear & concise, easy to read
• Include a definition of terms when appropriate, usually at the end.

Category: Articles | No Comments »
Tags: Articles, Design Docs

Posted By BOwen on October 13, 2009

I’ve just added some new pages for some ideas I’ve been working on.  Unfortunately, most of my written work is on my desktop which is currently unusable.  So the pages I’ve put up have only a brief overview of the things I have in mind.

I decided to go ahead and start posting to keep an online record of my ideas.  Since I do not work for anyone who’ll pay me to think this stuff up I’d like to at least be able to share.  Who knows, maybe someone will like it enough to do more than say ‘wow I really like that’. 

I’ve two primary game ideas with a 3rd on the backburner.  The first is “E6″ for lack of a working title.  It is a real time strategy with an interesting twist.  The other is Armor of God, a fantasy adventure title.  While both have heavily Biblical themes they are intended for a secular audience.

The other page I’ve put up “Systems” is a very brief description of two ideas I’d love to see in games but never have.  An on-the-fly combat animation system and an events generator which actually means something. 

As I develop these ideas more (and hopefully retrieve previous work from my desktop) I’ll update these pages with more detailed information as subpages.  Hopefully by the time I’m done I’ll have fully fledged design docs.

Category: Site Log | No Comments »
Tags:

Posted By BOwen on October 9, 2009

It’s been far too long since I’ve posted anything here.  The last thing I was working on for the Twilight Legacy server was a complete redesign of all mobs.  Since then I’ve been plagued by technology issues. 

My primary computer is offline due to a complicated string of events resulting in what appears to be some sort of hardware failure.  It had been difficult to diagnose.  I had thought it was the video card.  Now that I’ve finally gotten a replacement it would seem that assessment was wrong.  So it’s probably the motherboard.

To top it off, Twilight Legacy is presently offline as it has been moved to a new location.  Players are waiting for a new address to propogate so we can all log in again.  So as I write, I am unable to access the latest version of the game module on my machine as well as unable to access the game server.

All of that aside.  I did manage to learn something, or rather come to a realization.  As a designer and content creater It’s very easy to take different aspects of content for granted.  Balancing a mob is more than just getting the stats just right.  Mob AI and placement are also important.

To give an example: I had completely rebuilt several low level mobs.  Namely tribes of kobolds and barbarians.  This included replacing the default AI with an improved AI package we had been using for awhile now but not consistantly.  Little did I realize at the time that I was using a version of the ‘new’ AI that was intended for boss mobs.

The AI in this case didn’t make the mobs stronger but it did summon all the mobs within a 6 tile radius down upon the players.  It’s easy enough to acknowledge that AI is part of game balance as much as anything else.  However, like many things in life sometimes we have to experience it first hand in order for it to really sink in.

Category: Twilight Legacy Developer Blog | No Comments »
Tags:

Posted By BOwen on May 13, 2009

A few months ago I went through the module and revamped how how the majority of craft ingredients were collected.  Rather than every mining and fishing spot providing all resources for their respective types, I overrode the settings for each point to give a specific ingredient.   I tried to make the locations of each ingredient either logical, or predictable.

The idea was to lessen the burden on players engaging in ingredient collection by them to collect only the specific ingredients they wanted.  Under the old settings you could collect 25 gems where only 2 or 3 were desired.  The new settings allow all 25 said gems to be exactly what you wanted, no more and no less.

There were other benefits as well, but also a particular drawback.  2 of the mining ingredients had no logical or very predictable locations available.  These being pearl and coral.  So these two ingredients have been set aside for a long time now.  I could get away with this because I also added all mining and fishing ingredients to NPC merchants for players who would rather buy then collect.

The planned inclusion of underwater zones tackles this and another problem, the need for more well balanced XP areas, something which is desparately needed in order to deal with a few overused areas.  As I’ve mentioned before, in order to resolve abused XP areas I first need to provide alternatives.

At the moment I have the first underwater zone in production.  What it needs now is scripting.  I’ve found a script system to suit my purposes but now it needs to be adapted to fit the Twilight Legacy server.  OnEnter and Exit scripts need to be customized for underwater areas.  Mechanisms need to be in place both to prevent horses from entering the water and to prevent sea life from being brought unto land. (Let’s face it, there’s always going to be at least one player who wants a pet land shark)

All of that is simple enough.  Where it gets interesting is the handling of summons and companions.  Do you allow a regular, air-breathing henchmen to wander the ocean floor with you?  How awkward would it be to summon a fire elemental while underwater?  Should non-silent spells even be allowed?

It is possible that most regular summons to be allowed to drown.  Undead and constructs shouldn’t have any problem.  Neither should water or earth elementals.

This basically means going through any scripts handling basic casting routines if I want to impose spell restrictions as well as going through many of the summoning scripts to both prevent inappropriate summons or forcing appropriate ones.

I’m a little worried that good aligned characters have almost no summon they’ll be able to use underwater while there is a high number of undead summons players may call upon.  Given the size of the active playerbase and the quality of the players in general this will likely be a non-issue but I would like to address it anyway.

One thought which has occured to me is an alternate underwater summon.  This would be fairly easy to impliment but extra effort would have to be put forth to ensure such summoned creatures remained in the water.

Category: Twilight Legacy Developer Blog | No Comments »
Tags: Twilight Legacy Developer Blog, Underwater, Zones

Posted By BOwen on May 8, 2009

Recently one of the newer players who has done a lot of work with NWN’s 2da files offered to help upgrade the server.  To be honest I was a little skeptical at first.  I didn’t like the idea of having a new guy suddenly do what I felt was a massive amount of work, but he seemed sincere in wanting to do it.

There was also some interesting new systems such as a new tailoring system that is apparently common on several NWN servers.  After importing and testing the tailoring system I was a little more at ease and asked the players on their thoughts about a possible massive upgrade.  After some concerns were addressed the players in the end left me with the impression they were willing to endure the large necessary downloads.

At this point I entered the role of project manager for the big upgrade from using the CEP 1.5 haks to CEP 2.2 (CEP being the Community Expansion Pack).  We also took the opportunity to include additional content including new clothing items for players as well as several new tilesets not included in the CEP.

I wanted to do this upgrade not just because of the extra content we’d gain but because it was also an opportunity to clean up our existing files that have piled up over the years.  It was getting hard to remember what files were still in use and what new players had to download in order to play on our server.

The transition went very smoothly with 3 large downloads (down from about 5) in a single format.  The first download included CEP 2.2 files only.  This was optional for players who might already have CEP 2.2 installed for play on other servers.  This download was released early along with the second download so players would have time to get them before the server itself was upgraded.

The 2nd download was the next batch of files to be confirmed.  This contained only tilesets and files related specifically to them.   These files were grouped into the 2nd download because once they were decided upon no further changes were necessary.

The final download contains the rest of TL’s existing custom content and files necessary to put everything into order and ensure there are no conflicts.  As a few of these files were subject to change at all times, they were released last once I was satisfied with their status.

There were a handful of conflicts with the upgrade, but only a handful.  Most of which I was able to catch and fix prior to release.  I’m happy to say that none of the issues which arose were unexpected and nothing serious has come up to date.

Credit and many thanks to Nightmood (the player doing all the technical stuff on this project) for not only volunteering but for also following through and doing a great job.

Despite how well it turned out I could have done a better job at scheduling the upgrade and announcing a set time once I felt everything was ready.  Even though most of the active players were on the ball and ready to go, I should have announced a specific day after I was satisfied and given a little more time for players to prepare.  As it was I let the excitement of myself and a couple of other players run away with me and I ended up upgrading around midnight on the earliest possible day.  (I had been telling players “probably Monday or Tuesday” and ended up upgrading the server Monday)

The process of updating the server had one small hiccup.  I had forgotten to include a new loadscreen hak in the downloads as well as removing an unused tileset from the module.  In the end I removed both from the module since load screens aren’t crucial to the game play and I didn’t want to force another download on the players.  The consequence of this is sometimes the load screen has a white image where a screen shot should be.  This is a fixable problem by assigning load screens for each area, something I had already been thinking about doing.

When all is said and done I’m fairly happy and the players all seem thrilled with the new content.  A couple of minor glitches which are annoying but fixable, are far outweighed by the new content and features.

Category: Twilight Legacy Developer Blog | No Comments »
Tags: Twilight Legacy Developer Blog