Siege

hiatus

2010-02-14T18:22:00.000-08:00

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.

Small update, screen 3 finished

2010-01-07T13:57:00.000-08:00

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.:)

Happy New Year! Load object screens 2 and 3

2010-01-01T06:54:00.000-08:00

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!

Nearing completion: Load GUI Screen 1

2009-12-24T15:00:00.000-08:00

Not much left to do now.

-Multi-selecting works well now.

-Copying objects and groups.

-Sorting preview list.

-Removing from preview list.

-Holding shift now makes movement and rotation slower for more precision.

I have made some progress on the new load-object GUI.

This is the first of three to four screens that will be shown to the user. The left set of arrows select the desired object from a list. If "confirm" is clicked, the small view and other set of arrow appear, and the user can rotate and zoom around the loaded object, and scale it by clicking these arrows. The only other thing I plan to put on this screen is a way to select the category, and then a button to continue on to the next screen. Currently the only object format supported is .x, and I may add support for .3ds or .bsp maps.

three

2009-12-15T16:48:00.000-08:00

A bit of an update, for the sake of figuring out exactly what remains to be done. Using the previous post as a checklist, I have now

-rewritten the script, level, and object loading functions to allow for more than 256 items, as well as searching subfolders for files.

-switched the skybox out for a skydome.

-added a category flag to all objects and implemented a tab system for the "new object" dialogue.

-added a quick-save option.

-revamped the save/load/clear level interface.

-switched to global rotation for editing objects.

-allowed multiple objects to be selected and modified.

-laid a framework for grouping objects

I've now got to clear up a few more bugs with the multiple-objects, and then I will probably move on to adding a copy-object and -group function, to make it easier to build castle walls or other repeating-monomer type structures. And, of course, to add the remaining functions listed in the previous post.

The level editor, take two

2009-12-08T13:58:00.000-08:00

The level editor is now somewhat functional as far as level-building, and I will be adding more features to make it easier and more intuitive to use, as well as incorporating different types of objects and options.

What it can do now:

Load objects from a script into a preview list on the right-hand side, and scroll through this list.

Save the configuration of all user-added objects to a user-named map file.

Load this configuration from the list of maps.

Add any object placed in the Models folder dynamically to the preview list.

Position and rotate any object on the map using the keyboard for movement and the mouse to rotate.

Reset the rotation of an object to 0, 0, 0.

What I plan to implement next:

Sorting objects in the preview list.

A scale adjustment for dynamically loaded objects, so they will not be too big or small in the preview list.

Rewrite the script loader, level loader, and object loader to use more than 256 items.

Switch the skybox for a skydome to make user customizations easier.

Add a "category" flag for all objects, such as static, character/enemy, terrain, skydome, light, item, trigger.

Add tabs for the preview list to sort through objects according to category.

Remove objects from the preview list.

Quick-save option for the current level, rather than typing in a name each time.

Loading textured objects.

Assign physics attributes to objects : will have to learn how to use Newton for this.

Once all those functions are added, and any others that I come across, the level editor will be complete and I will switch gears to modelling and animation, and from there the game engine itself.

The level editor

2009-12-06T11:09:00.000-08:00

I got some groundwork done on the level editor. You can now position and rotate objects, and my next task will be to add functionality for loading objects as well as saving their positions. I would have had this done yesterday but I was redoing the camera controls and trying to make it a lot more complicated than it needed to be. So that will be my goal for today/this week, aside from studying for finals.

The game

2009-12-04T15:30:00.000-08:00

And so, the fun stuff.

I am planning to create an RPG, tentatively titled Primanon, which has absolutely no meaning. So far I have planned no plot, created no models or other media, and thought up few gameplay mechanics. It will likely be very generic, until my storytelling/artistic college courses bring me some inspiration.

You are a guy. You have a sword. Kill stuff.

Gameplay. Imagine a cross between Fable and Black & White. Throughout the game, you will raise a dragon companion who can be taught certain tasks and behaviors. Both you and your dragon's actions determine your alignment, good or evil, which affects your quest and item choices, as well as the abilities of your dragon. I will be explaining all of this in more specific detail as I develop it: at the moment the game is a rather blank slate:

The first gameplay feature that I have (almost) fully thought out is a physics 'minigame,' which I plan to call Siege. What began as something very similar to the flash games Crush the Castle or Siege Master (in which you use a trebuchet or other siege weapons to knock over or destroy a castle full of people) has been flushed out to include RTS and RPG elements.

You are the general in charge of an army of soldiers, tasked with defending your king and castle from your opponent's army. Each game will begin with you standing on the battlements of your castle, overlooking the soon-to-be battlefield between your castle and theirs. In the beginning, you will be armed with a single catapult and a handful of soldiers. You will also be accompanied by one of three captains, either a warrior, archer, or mage, each which lend unique attributes and a special projectile to the battle(more on this later).

From the battlements, you can overlook the battle and give commands to your troops. You can also upgrade the soldiers' armor and weaponry, or recruit new soldiers. The gold for earning these upgrades may be from defeating enemy soldiers, winning battles, destroying enemy castles, etc.

You can also choose to leave your command post and take to the battlefield yourself. This is where your progress and training in the actual game can pay off, or earn yourself some extra experience. On that note, I plan to release Siege beforehand as a separate game, so the RPG elements will be present but limited: you can only use weapons found or earned in the mini-game, as opposed to the full game in which you can use any weapon from the game. Also, I will probably not include the dragon companion in Siege; obviously it would not be able to learn too much in such a limited environment, and it would certainly unbalance gameplay.

You cannot command your troops as easily from the field, though you will then have the ability to use the catapult and other siege equipment manually to aim at castle structures, rather than directing them a general area to attack. The enemy castle, as well as your own, will be destructable to an extent. I'm not sure how complex I can get with the physics engine before it becomes unbearably slow, but preferably I would have each (fairly large) stone in the walls be a separate physics block, allowing for complete leveling of the enemy castle. This could also be used to break a hole in a wall to allow entrance, rather than fighting your way through the main gate. Probably, your fellow soldiers will attempt to use the gate rather than finding such alternate ways in, since I do not have quite that much confidence in my AI programming abilities.

Once inside the enemy castle, your main objective is to find and kill/capture the king and other royalty. The gold earned on each round will be determined by the number of enemies captured; if you manage to capture a king with enemy soldiers remaining, they will become yours to use in the next round, with a difficulty curve added to make sure you cannot simply overwhelm the next round's forces by numbers. You can also find gold and valuables as you work your way through the castle, adding to your stockpile.

The captains will probably remain on the battlements at all times, either notifying you of the battle status or commanding the troops in your absence. Choosing the warrior captain will strengthen your troops' attack strength, by training or somesuch. His special projectile is a large bomb, which can be flung by siege weapon or carried by a particularly strong(high-level) main character into the enemy castle, causing great damage to the castle structure. The archer captain will earn you a battalion of archers, which can be placed on your battlements for defense or sent into battle to assist your soldiers offensively. His special projectile is a sort of frag explosive, causing little damage to the castle structure but devastating human tissue. The mage captain will magically strengthen your soldiers' armor so that they are harder to kill. His special projectile is a bomb that permanently disables the magical ability of enemy mages. Forgot to mention them, gah. They won't come into play much until later, but basically they can cast defensive wards on the castle to block it from projectiles (aside from the magic one obviously) and can also attack invading soldiers.

As you may notice if you haven't fallen asleep yet, I have only touched on the RTS elements. This is mostly because I am not entirely sure what to incorporate or how, having played only a select few RTS games. I think I'll figure it out, or else have to take suggestions(which I will anyway, of course. Whoever heard of someone designing an entire game by themselves?).

So that's the plan, and I am well on my way to coming close to beginning the design of the initial steps of the prepara.....

Well, I'm getting there. So far I have developed a script system to load and place of objects, and am about to code the other half of that equation - a level editor. Being able to dynamically place the enemy castles and soldiers will really streamline the development, beyond these initial steps of designing the engine. The script system I've haphazardly constructed may be too slow, though, to use for things like AI. In the full game, I had only planned to use it for placing objects, dialogue, quest information, etc. Also, having a level editor in the game will allow for players to build their own enemy castles -- the player's castle will most likely remain unchanged, or at least change only after a set number of rounds.

So, that's how things are so far. I'll be updating this fairly regularly, especially after finals next week. Six weeks for Christmas break is awesome.:)

The premise

2009-12-04T15:23:00.000-08:00

This is a blog of my game programming and animation progress. I am a freshman majoring in Animation at Ashford University, and with any luck the piece of paper they give me will help me get a job at a film animation firm (hopefully Pixar). I am also a beginning programmer/hobbyist in DarkBasic, and lately have been making some headway on the game that will be the main focus of this blog, at least for the first year or so. After that, I will be taking animation courses instead of general ed snorefest, so my attention will be more focused on them than my hobby.