Sunday, February 14, 2010

hiatus

I haven't been working on the game too much lately, on account of returning to school and playing games with friends (particularly Dungeons & Dragons Online). Will be phasing that out to a more reasonable level as it has begun to interfere with my coursework somewhat, and that will also give me more time to begin working on the game again. At this point, I don't quite remember what I was working on anymore. Something with physics still, but I'll have to look into it.

Thursday, January 7, 2010

Small update, screen 3 finished

Finished the third (lights) and fourth(triggers) iterations of screen 3 for now.


Spot and point lights can be created, and a color and range can be specified. Also, the inner and outer cones for the spot lights can be set. I am curious why there is no "power" or "intensity" setting for lights in DBPro, but I will have to rely on shaders later for this.


The trigger screen is for setting up invisible collision boxes that will trigger a script in-game, shown as ghosted red objects in the editor. The size along each dimension can be set, and the name of the script run by colliding with this box can be entered. The only other thing I wish to do here is supply a list of common scripts to choose from in addition to entering a custom script name.

This leaves only three screens left to do.
-Screen 4 for Static, Character, and Terrain objects - setting up Newton
-Screen 4 for Light objects - setting up light zones. DirectX only supports 8 lights to be rendered at any one time, and since light 0 is the default ambient and light 1 will be the directional sun light, this leaves only 6 user-created lights to be drawn. Since most levels will have more than 6 torches, for example, the user will set up zones, similar to trigger boxes, in which the light will be drawn if the player steps into the zone. This way, up to 6 light zones can be intersecting at any point, but a much higher number (currently 40) can be saved to the level data.
-Screen 5 for Character objects - setting up a character's level, AI type(soldier, archer, royalty, etc), which item is dropped by the character upon its death, and combat traits such as attack strength, defense, or ranged accuracy.


I have also been thinking quite a bit about the plot and setting of Primanon, and have decided to make it a space RPG rather than medieval. I had originally planned, among other plot twists, to end "chapter one" with a mysterious crystal crashing into the player's castle, and the screen fading to black. In the sequel, it would turn out this crystal had transported the player, his dragon, and other characters to the distant future, and the player would set off on an interplanetary adventure. However, as science fiction is a more interesting subject than the dark ages, it seems much easier to come up with ideas for futuristic things, rather than being restricted with an obligation for historical accuracy in a medieval setting. So I have decided to just begin in the future, with a few minor plot changes. Most of the changes would be in setting, and allowing the player to visit different worlds and meet alien races, rather than exploring the world on foot or horseback and meeting overdone dwarf-orc-elf-genericmonster races. This will also require much more 3D media and animations, allowing me to develop my abilities more fully and perhaps showcase a cutscene or two in a future demo reel.:)

Friday, January 1, 2010

Happy New Year! Load object screens 2 and 3

Having entered my editor in the NaGaCreMo 2010, I have only 30 days to:

-finish the load-object GUI.
-add an edit-attributes button, basically opening the load-object GUI for existing objects, to edit their attributes later.
-implement Newton physics.
-make a small number of models for testing purposes.
-make a "physics mode" in the level editor, in which Newton is active and projectiles can be test-fired at structures to make sure everything works.
-extra feature allowing the user to delete all objects of a certain category.

If I have time: (these items will be part of the final editor, but I may not get to them before the competition is over)
-Level settings, to adjust the position of the directional sun-light to match the skydome texture, and change its color and power. This will allow for night scenes, or apocalyptic red-sky doomsday whatnot. I don't plan on making such a map, but I am designing the editor and game engine to be flexible enough for the players to if they desire. After all, Siege is just my practice/learning game, and several elements of the level editor and game engine will be used in the full RPG, so I want to make it as reusable as possible.
-Newton constraints. There are a number of very useful constraints, or joints, in Newton that I hope to implement, though I can't remember all of them (finds documentation). They are ball-and-socket, hinge(limits rotation to one axis, no movement), slider(limits movement to one axis, no rotation), corkscrew(hinge+slider, one axis of movement and rotation), and upvector(object will never fall over, useful for characters and things that walk around). These will be very useful for adding complexity to a level. For an obvious example, using a hinge joint for doors, or restricting a joint's rotation to 0 to effectively nail two objects together. As I glance through the documentation, there also appear to be settings for detecting the amount of force acting on a given joint, allowing for, say, a door to be broken down if enough force hits it. I am very excited now.:)

So anyway, I have finished the first screen of the load-object GUI.

In addition to my previous post, the user can now choose a category for the object by clicking the category button, and a description of each is shown next to it. Also, I adjusted the loading routine slightly so that any object format that DBPro supports can be loaded, not just .x files.

The second screen:

On this screen, the user can choose a texture from the list on the left, then click confirm to apply it to the object. There are fields for entering the object's name and description, and a window for adjusting the object's preview size, which is how large it appears in the "New Object" dialogue.

These two screens are always shown to the user. After this, the flow branches depending on which category was selected on the first screen (the user can go back and change any attribute from any screen). First, a rundown of the categories, though I've probably gone over it once already.

-Category 1: Static. This is any non-animated object, controlled by Newton physics. Projectiles, building materials, etc.
-Category 2: Animated. This is any character object controlled by animations and AI. I had hoped to implement ragdoll physics for dead characters, but it seems to be very difficult to set up, not to mention processor-intensive.
-Category 3: Items. These are objects that can be collected and used by characters. Armor, weapons, money, and healing objects are the four sub-categories.
-Category 4: Terrains. These are any animated or non-animated objects that are not controlled by Newton - Ground, trees, or non-destructable structures like dungeons and really really heavy doors or something.
-Category 5: Skydomes. These are just textures for the skydome, no object mesh data is used.
-Category 6: Lights. Any light-emitting source and its associated emitter mesh - e.g. torch's flame.
-Category 7: Triggers. Any invisible collision box that triggers a script to be run. This may be the hardest to get my head around, and I'm saving it for last before Newton. Basically, I would need to know which object can trigger it (or perhaps a group of objects, say any of the player's soldiers passes a point on the map and the tough enemies start coming) as well as which script to run. I'm not entirely sure if I can even use my scripting system for this sort of thing, since it's a bit slow. The scripts would have to be fairly small, perhaps just a set of variables to apply. I could, however, have a set of hard-coded "scripts" for various tasks, and also allow for user-made scripts to be called. Not sure yet.

And so, the third screen: category-specific attributes. I have determined that there will be four different screens shown depending on category. For example, statics will skip this step and go to screen 4(Newton), and skydomes are already done at this point(all that is needed is a texture and preview size, and perhaps a name/description).

The first third screen I made is for animated objects(categories 2 or 4, since terrain objects can be animated as well).

On this screen, the user can name an animation, set a start and end frame, and set the object's animation speed. There is also a play button to preview the selected animation between the start and end frames. This screen is nearly done. The only other thing I had planned to add, and probably won't for some time, is the option to name an animation from a list rather than "freehand". This will allow for easier scripting later - say a player designated a certain animation to be called "attack". Later, if a character's AI tells it to attack, it will simply run the animation with that name, instead of searching for a player-named animation that is meant to mean attack.

The second third screen is for items.

This one is also incomplete, and will not be completed until I have some actual media. On this screen, the user can choose from the four sub-categories for items, and assign an attribute depending on subcategory chosen: damage done by weapon, damage blocked by armor, amount of money worth, amount healed by object. The incomplete part deals with weapons and armor: I plan to have a dummy character model in the preview window, and a second attribute for specifying which limb the armor or weapon is attached to. This will make it easier for players to add their own media, somewhat. By dividing a suit of armor into separate meshes for each limb, it does not have to be animated itself, just scaled to fit the desired character(another thing missing from this screen: scaling and rotation).

The third third screen is for lights, which I am currently working on. The fourth third will be for triggers, and of course the actual fourth screen will be for Newton attributes - collision boxes, weight, etc. After all needed attributes have been specified, the object will be created and added to the preview list, ready to be instanced in the level.

So I guess that about covers it. Happy New Year!