Thursday, December 24, 2009

Nearing completion: Load GUI Screen 1

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.

Tuesday, December 15, 2009

three

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.

Tuesday, December 8, 2009

The level editor, take two

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.

Sunday, December 6, 2009

The level editor

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.

Friday, December 4, 2009

The game

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

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.