SpaceCraft: StarGen 0.1a

Posted By BOwen on April 26, 2012

It doesn’t look like much but finally I have something to show. I suppose a more experienced programmer would have a good chuckle at this relatively simple device but we all have to start somewhere don’t we? Everyone starts off as a “newbie” so let us bask in the glow of our “minor” accomplishments.

So what this is, is the beginning of SpaceCrafts universe generation. The main window right now is just a console display to give me feedback but later it will display detailed information on the major star types or well, that’s the plan currently.

Star Type data and generation odds are read in from an XML file so it will be player modable as I think I mentioned before. Most of the rest of the display is pretty self explanatory. I’m hoping a friend of mine will help me pretty this up a bit.

What the script is actually doing right now is randomly generating stars by mass rather than class. It then fudges the mass a bit and then calculates the star’s subtype. I decided to do it this way because the star’s mass can be used extensively in calculations and have the game look everything by star type turns out to be more combersome the more I think about what I want to do. So star type and subtype and by extention other features I haven’t worked on yet are all calculated by the star’s mass.

After that is figured out each star has a 1 in 10 chance of being randomly aged. (Approximately 90% of all stars are main sequence stars which is where I came up with 1/10 odds). As you can see from the screenshot the random aging produces a variety of results which are also based on the star type. A Class O star for example will eventually become a black hole while your typical G class will even up as a black dwarf etc.

The coordinate system right now is pretty basic. It finds a spot within a 100×100x10 space which I plan to also make configurable. Although personally I think a universe of 100,000 locations to fly around in is plenty big enough for most purposes. Well, ok technically it’s closer however many stars your have but that’s still not to be sneezed at.

It doesn’t save the data yet. I will hopefully get around to that in the next week or so. I’m becoming amazed at just how fast time flies when I’m doing something that seems so simple. Of course, thinking up a better way to do something you’ve already done doesn’t speed things along in the short term either. (It is worth the time investment though).

SpaceCraft: Oh Be A Fine Girl *SMOOCH*

Posted By BOwen on April 20, 2012

Apart from feeling like my head is going to explode if I cram any more information into it I suppose all is well. Several distractions are out of my way and I can spend more time working and less time, well, being distracted.

What I’m working on right now is the universe generation GUI and scripts. The game will support the 7 major star classes, O, B, A, F, G, K, M as well as user defined custom “rare” classes. Of course, the 7 major classes will also be customizable. I’m a firm believer in moddable games and am striving to make mine as configurable and flexible as possibe right from the beginning.

I’m planning on using XML for as much as possible including being able to define anything within the game that doesn’t require custom scripting. Naturally this includes being able to define new star types like brown dwarves, Wolf-Rayet or anything else players want to add, fictional or otherwise. At this time, any custom stars need to be defined prior to universe creation.

Another feature of universe generation is the random aging of stars for some interesting phenomion. Rather than simply saying ‘ok I want x % chance of a black hole’ in order to spawn a black hole somewhere, the game will take a look at the largest stars capable of becoming a black hole. Then if that star is old enough it will become a black hole in the game. This isn’t just limited to black holes. Young stars, planetary nebula, super nova etc will all be randomly determined by the star’s initial size and age. I have a good lead on how to generate three dimensional nebula which I’m looking forward to exploring so hopefully I’ll be able to put in a variety of nebula as well.

I’ve been thinking about randomly generated planets and have come to the conclusion that the best course of action for me is to use one simple algorithm but to have those routines available for modders. I’d rather spend months working on the gameplay than perfecting random terrain generation. I’ll go more into planets another time.

SpaceCraft: Learning not to wait..

Posted By BOwen on April 6, 2012

There are often times in our lives when certain things are out of our control and we need to learn to wait patiently for situations to change before we charge blindly ahead. On the other hand, the lesson I need learn is to fill those times with the things I can still do. This isn’t always to see. We can’t always think of something until we see the immediate need to do so but that shouldn’t mean we can’t be productive.

So now I get to kick myself a bit here. For several months I had to wait for personal matters to settle down, wait for new software, wait for money to become available in order to make sure this or that happened. Now don’t get wrong. Filling up that time with Skyrim or an old game from my collection isn’t necessarily a bad thing. However, I could have spent some of that time working on concept art or researching things I would want to know before I set about a task like designing my random star generation routines.

I suppose this is a bad habit of mine. If a certain aspect of a project is forced to be on hold I tend to want to wait until it’s resolved. So I need to learn not to do that. It’s not just research. Concept art would have been helpful to have done before I gained the ability to work on models and animations without worry of having the process interrupted (as was the case until recently).

Looks aren’t everything but when it comes to game design they have a huge impact on development. Millions are spent on a game so teams can focus on just one aspect of game development over the course of years to get one game done. Now I don’t want to copy that blocky look of Minecraft but I can’t afford to spend dozens of hours on just one model or texture either. That means I need to keep it simple-stupid or else I won’t ever get anything done. So that remains another significant challenge for me, deciding on the overall look of the game. Something that is simple and not very time consuming but also something that players can change easily with mods.

Another difficulty for me is simply to think small. I do believe it’s better to think big and then scale down as needed but my ideas simply keep coming and getting more and more complicated as I go. It’s an urge I need to resist up to a point or I’ll spend more time trying to figure out the best way to put it into the game and not enough time actually making the game. It may be a good quality for a designer but I have to code, model, animate and everything else as well so I need to find a good balance between the idea and implimentation.

SpaceCraft Dev. Begins

Posted By BOwen on March 31, 2012

Well it’s been a few months and life happened. Without going into too much detail I ended up moving to a new place, upgraded my OS to Win7, reinstalled everything, met the neighbors, fed the cats and the usual assortment of other things that somehow managed to take up several months of my time. Then again, playing Skyrim and Pharoah didn’t help with the delays but trust me, there were legitimate life reasons.. like getting my new OS taking longer than expected, the afore mentioned move etc.

I’m finally squared away and life is stablizing somewhat so I am now (finally) ready to begin development in earnest. I expect the first steps will take awhile as I’ve a lot to learn. Thankfully I’m a fast learner and most of it is just familiarizing myself with the C++ and Torque environments as well as the project files. I am already somewhat familiar with code, textures, 3D modeling & animation etc so I’m not too worried.

My main concerns for SpaceCraft lately are travel times and proper scale for planetary exploration as that will largely determine my approach for randomly generating a planet’s surface. Just how much should be explorable? How large should that explorable space be? Can you land your ship anywhere or only in predesignated locations and so on.

The immediate tasks at hand however (aside from learning new things), is building the initial environment for the tutorial level and random generation of the playable universe. I don’t expect much difficulting in simply generating the data but as I’m not yet very familiar with my game engine it will be an interesting task converting that data into a viable in-game map.

So on the coding side I need to review the main game loop and begin adding tools and options for universe detection and creation. I also need to consider detection and loading for game content. This specifically to allow for ease of modding. Having a highly moddable game is important for me. I really want players to be able customize the game any way they want.

For 3D models I need to begin building the tutorial level. Textures and PC model can use Torque defaults for now until I have a playable alpha of the game.

How to eat an elephant

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.

A 1,000 mile journey begins.

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.

On Writing Design Docs for Games

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.