KUOP Development

Story Rewrite

2010-07-14T18:46:00.002-05:00

Well, if there is anyone who is reading this blog, I am still working on it. Life intervened. I have a new job, and am making changes to my life. I don't think I will give this game up until I am finished. I am just too passionate about it, about game development, and about video games in general.

I decided to rewrite the story. I will call it a major rewrite. The characters will change, and the settings will also change slightly. The underlying story will be much the same. The main character will be a man instead of a woman, and the game will start at L4, not the Moon. I want to make the main character someone I can relate to. So, I am letting you guys know that I am still making this game.

Updates...

2009-12-02T22:00:00.004-06:00

Yeah, it's been a while as I was busy with life. But I am still working on the game. Here is one screenshot.

Battle Animations

2009-06-11T14:05:00.004-05:00

My game development talents do not lie in composing music or in drawing graphics, but in programming. As such, I am pretty much using publically available RPG Maker 2000/2003 tiles for my game. Sphere can import such tilesets with ease, and that makes game development that much easier. A few of them may be doctored up by me, but they are all imported tiles.

The RM2K/2K3 spritesets can also be easily imported to Sphere. A popular tool exists in the RM2K3 community that helps you easily make character sprites. The Charas Project is a series of third party tools designed to allow you to design RPG Maker compatible sprites.

So that allowed me to make the map sprites for the game. But now, I need battle sprites. I decided to use the map sprites, and then edit them to create battle animations. Sometime ago, I posted the first battle animation of Desiree. That is the technique that I used. Being that I am a terrible artist, I believed that doing battle sprites for the characters would be difficult and tedious. But simply editing the sprites to create animations is far easier than I thought it would be. One reason why it is easy is that I am using the Final Fantasy 4/5/6 technique rather than the Chrono Trigger technique to animate my game. Chrono Trigger, if you remember, was intense with the animations. Each character has several frames for each move, and each enemy was also heavily animated. The SNES Final Fantasy games didn't have much animation by comparison. The enemies were not animated at all in the FF games. There was just one frame of animation, plus some palette/blend effects. The party members themselves were not heavily animated. Just a couple of frames for most battle moves.

The FF approach is the one that I am taking. So I pretty much only have to do the animations for the five characters. As far as techs and effects, public resources, especially related to the RPG Maker series, can easily be found.

Add: And when I have the frames for animation, I use the program PNG/MNG Construction Set to create my animated sprites.

The Battle Test

2009-06-08T17:53:00.005-05:00

In order to develop the battle system, I've created a test map for it. This map will not be accessible in the final game. Here is what it looks like. And you likely guess right that the two NPCs are enemies.

When you bump into one of those NPCs, you will enter battle.

The enemies are test enemies and will not appear in the game, but all of the party characters will. This is a bare-bones ATB battle system. The timers update, but not much else happens. Most things (including basic commands such as "Fight") have not yet been implemented. Even the main battle windows themselves are not yet complete.

Battle Musings #1

2009-05-17T00:12:00.003-05:00

I haven't totally finished the Menu system. I have many of the major parts working though. I will work on the Techniques Menu concurrently with the Battle Engine.

I want to make some changes to the design of the battle engine. Instead of loading the values for each enemy from a file, I think that I will just implement it into a script. The info for all of the enemies in a dungeon will be loaded into one Sphere script (*.js). For each dungeon, the names of the functions and variables will be the same so that I can use the battle engine for it. This should work out because each Map has its own script that you can program, as does each trigger and character sprite. So, at the entrance to a dungeon in the "On Enter Map" portion of the internal script, I will have this code:

DungeonNo = xx; //where xx is the actual number
RequireScript("DungeonXX.js");

Within the DungeonXX.js file, an initialization function will give values to a global dynamic array for all of the unique enemies in a dungeon. If there are 5 types of enemies in a dungeon, then the global dynamic array will consist of 5 objects defining the enemies. In the same DungeonXX script file, there will be an AI function (which will have the same name in all dungeon script files) which determines the behavior of the enemies. The enemies should be easy to program compared to the player party in battle. The enemies will have absolutely no animation.

Enemy Maker

2009-05-13T20:28:00.002-05:00

I have created an enemy maker program using Sphere. All it does is take in input about all of the enemies for a dungeon and then prints it to file. This way, whenever you enter a dungeon, or any place where normal battles might reside, the data will simply be loaded from a file.

Still Working on This Game

2009-05-08T16:26:00.001-05:00

There haven't been updates lately, but don't think that the game is canceled. I've been a little busy with life, and just needed to find some free time. I will post some real updates soon, so stay tuned over the next week.

Battle #1

2009-03-20T16:06:00.006-05:00

I have begun to work on the battle system for my game. I have found a good way to create MNG animations out of PNG images. All it takes is a nice Google search to find a nice program for it. I'm not using a properly licensed program, so I won't tell you what I am using. I did "hire" someone to create animations for me, but I'm not sure how that will turn out, or even if he will pull through.

But I have finished my first battle animation. It is a two frame animation of Desiree doing a slash animation. Since Blogger doesn't support MNG animations, I will just show you the two frames.

Yes, this is only two frames of animation, but it works surprisingly well. If you actually dissect the battle animations in FFVI, you will see that the same animation uses only two frames. So, if Desiree is equipped with a heavy metal pipe (which will be one of the initial weapons in this RPG), this is the animation that will be used. Just paste another animation of the swinging pipe over this, and add a third animation playing at the same time that has the "motion lines" (for lack of a better word), and this will be a pretty nice animation of Desiree swinging that pipe at an enemy. Add in a good sound effect and a quick white color mask flash on the enemy to show that it has been hit, and this will be perfect. I've studied FFVI sprites for this. The map sprites in that game are very similar to the battle sprites. In FFIV, the battle sprites are bigger than the map sprites. But in FFVI, they are the same size. The battle frames that are in display above are modified map sprite frames. This should make it much easier to make decent battle animations.

With this, I've created a wrapper class for the animations. Since the enemies won't have any real animation, I will merely use Sphere surfaces to display their graphics. But the player sprites, the weapons they are holding, and the tech and item effects will all be animated sprites. In Sphere, at least, there is no way to find out how many frames are in an MNG animation. There is, however, a way using FLIC animations. But FLIC is so "legacy" that it is not worth my time. At least I know for certain that my MNG files will support more than 256 colors with alpha-blending. As a result of not being able to find the number of frames from within the MNG file, I will have to do it from without. Thus, the constructor function for the sprite object has two parameters: filename and number of frames. Luckily, I don't have to account for the length of each frame since the only way to advance a frame is to call a function named "readNextFrame()". And since the battle engine will run at a constant frame rate, everything will be done on a frame by frame basis. This requires two properties: current frame and total frames. A function to determine if the animation is "finished" is also helpful. It returns true if current frame equals total frames. A wrapper function for "readNextFrame()" is also useful, as it also updates the frame number. So, if the animation is finished, then call the wrapper function and the animation will be reset, ready to use again at any moment's notice.

So now, development is starting to get more exciting. I have most of the Menu engine out of the way, and can now devote more time to the battle engine. And, of course, after the battle system is finished, then most of the game development afterwards will be more focused on game content. Awesome!!!!!!

Menu - Equip #2

2009-03-14T22:02:00.003-05:00

Now, it is almost done. Once this is done, I am over the hump WRT the menu system for the entire game.

Menu - Equip #1

2009-03-13T21:17:00.004-05:00

After a three week "break", I've resumed development of the game. Right now, I am working on the hardest part of the menu system, which is the equipment menu. The screen below is the easy part, which is picking your character.

The image below is an unfinished version of the equipment menu. Making the equipment menu is not hard, per se, although this is the hardest portion of the menu engine. In fact, the experience that I have in programming makes this rather easy. A more accurate word for this is tedious.

First of all, I have to initialize all equippible items in this game. Since the equippible items in this game have so many possible attributes, and since there are so many different classes and sub-classes of equippible items, this is a chore. I have the weapons done, but I still have to do the armor, bullets, and accessories. As you can see from the screen above, I can display the name of the weapon that is equipped, but not the names for the armor, accessories, or bullets.

The window at the bottom might be divided into two. Regardless of whether it not it is divided, the left portion (or window) will contain player stats (such as Attack, Defense, Evade, etc.), while the right portion (or window) will either be empty, or (if you are actually in the process of equipping a player) will show the items that you can possibly equip in that slot.

Stay tuned, because I will probably have the equip menu done tomorrow, or by the end of this weekend at the latest.

To Do List

2009-02-18T15:34:00.004-06:00

The item menu engine is done. I just have to edit all of the information of the 38 items that will be available for the demo.

After that, I have to build the Materials, Fab, and Disassemble menus. This will be rather easy, as they will use pretty much the same code as the Use Item menus. They will pretty much look and behave the same way, so I'll be done with those in short order.

Once that is done, I will be over the hump WRT the entire menu engine (that is, the menus outside of battle and the stores). The Tech Menu, which is the science fiction version of the Spells/Magic menu will also use a rather similar engine as the Use Item menu, with a few changes, so that should be smooth sailing.

Then after that will be the Equip Menu. That will use a dramatically different engine than the Use Item menu. The Party Menu is not a priority as it will not be needed for the demo. That will become a priority once you have more than four people in a party, which will only be the case later on in the game, after the demo ends. I might just remove the save "option" on the main menu and implement this a totally different way. The Status Screen will be the easiest one of all.

And then after this, I will dwelve deeper into battle.

Final Main Menu Picture

2009-02-14T20:04:00.000-06:00

Okay, so here is the final main menu pic. Enjoy!

Item Menu #1

2009-02-13T13:50:00.000-06:00

Can you imagine a RPG without an item menu? Well neither can I. It is a staple of RPGs just like the ability to jump is a staple of platform games. I've nearly finished the item menu, save for some graphical tweaks, such as borders, and parhaps a gradient.

One great thing about my RPG is that in-game documentation of the world will be more extensive than most RPGs. You will learn not only what an item does, but also the history behind it.

Next, I will work on getting the items to actually work when you "use" them.

Main Menu 4

2009-02-08T22:15:00.000-06:00

Well, here is the main menu screen. Functionally, this is basically done. The only thing that now needs to be done is graphical tweaking.

Now, it is time for the item menu.

Main Menu 3

2009-02-08T00:08:00.000-06:00

Okay, so here is the old main menu screen. Notice how it looks just like a SNES Final Fantasy game. This was created using Flik's menu system. It is a very good system, but not the right one for this particular main menu system.

Here is a WIP screenshot of the new main menu screen. This one is totally custom. The previous post has a drawing of what the new menu is supposed to look like. It is only partially finished as you can tell from the graphic as I still need to add two more windows. Yeah, it looks ugly right now, but it gets the job done. I will work on graphical tweaking later on.

Menu Template

2009-02-07T16:18:00.001-06:00

This is basically how the new menu system will look.

There will up to four members in a party, but only one is shown in the graphic. The red box will be the face pic, if there is to be one.

New Menu System

2009-02-07T14:20:00.000-06:00

It's been months since I last touched the code of the menu system/engine. I haven't even used the menu when running the game. I don't know what happened to it, but it is not acting right; none of the items are showing up.

I really don't want to go through the tedious task of debugging (which is, of course, 90% of the time/effort/money in software development). Instead, I am going to make a new system. Besides, I wanted to change it anyway since it looked too much like Final Fantasy. The new menu will have more or less a different look. It will look better, but the format will be simpler (at least code-wise). I will have at least a drawing later on today, so stay tuned.

Battle Structures

2009-01-26T19:20:00.000-06:00

Now creating large classes like this is tedious. Here is a sampling of some of the variables to be considered during battle.

More later.

Battle Test

2009-01-20T17:07:00.000-06:00

On this blog, you will see me construct a functional battle system, among other things. To do that, I've created a specialized BattleTest map, background, and some enemies.

First, the BattleTest map.

This is a very simple map. It has only one layer. So far, there are only two NPCs. This map will not be part of the game itself. These two NPCs are enemy NPCs. In this game, there are no random battles. You will enter a battle either by touching an enemy NPC, or by stepping on an event tile. So you are looking at two potential battles. As I was testing this map, I noticed that when you create an NPC entity, the "touch" box seemingly only works when you actively touch the enemy. It doesn't work if you are still and the enemy touches you. But this problem is easily solvable by using the "on generate commands" section to test for collision between the player and the enemy sprit, and I might just get that over with today. Each NPC can have any number of enemies. One NPC has only one enemy, while the other has three (two unique enemies).

Now here is a screenshot from the "battle engine".

As you can see, there is not much to show. This is nothing more an a test of some ideas. The player HP/ATB window is fake; right now, I'm making sure I have a font that can fit on the screen. The beige background is actually a graphic. The enemies, however, are showing. These (and other) enemies will be around in the BattleTest, but very not likely in the game. Maybe the cannons, but that blue face with feet and hands definitely will not...it will be out of place. One good thing is that the enemies don't need animations. None of the SNES Final Fantasies have animated enemy battlers, and this one doesn't need it either. So this is the very start of the battle system. In the days ahead, you will gradually see it improve, and gradually see the battle system take shape.

First Post

2009-01-20T12:21:00.000-06:00

Hello. This will be a blog centered around the development of KUOP, my RPG.

So far, I am mostly done with the menu system engine. The Item menu is basically done, but I still need need to do the fab and deconstruct menues, which will be very similar to the item menu.

I need to do a menu for techs (which will pretty be this games version of a magic). Of course, you will only be able to use the healing techs outside of battle.

Then I need to do an equip menu.

Then a config menu.

Then I need to implement the load/save menues.

Basically, I will work on getting all of these functional. And once they are functional, or at least close to functional, it will be rather easy to give the menues a visual facelift to give it a more visually appealing and more original appearance.

The second major challenge is the battle engine. I have started on the engine, but as of this first post, the only thing it can do is display the background the enemies, and the HP/ATB window. The battle system is not hard, but I've been rather lazy.

I haven't even created the player test battle sprites, much less the actual sprites for the players. I will temporarily use some RM2K3 battle sprites until I can get someone to create them for me. The enemy sprites will mostly be pulled from other games, and they don't need any animation. As graphically intense as FF6 was, you will notice that the enemies are not animated; have only one frame.

I still have to create the enemy name window, which will merely tell you which enemies are on screen and how many there are.

And then I would have to create tech animations, which will be similar to item/spell animations. Some characters will have specialized animations for some of their techs.

And then there are the battle menu systems. They include the command menu (which has Attack, Item, Tech, and the other common command menu items), the battle item menu, and the battle tech menu.

Those are just the graphical requirements. Then I have to write the code to put all of this together, which shouldn't be that hard. It will be an active time battle, strictly time-based. And since the rate at which FlipScreen() can easily be set using a function, it will be easier still.

Then there will be the touch-up on the battle graphics.

Once both the menu and battle engines are complete, the rest of the development will be pretty straight forward. Find the tilesets (much of this has already been done, using mainly RM2K3 chipsets), find/create NPC sprites (I will use The Charas Project for this since Sphere imports RM2K/3 data), find enemy sprites, find game music, find effects/weapons sprites, code the items, code the weapons, code the armor, code the techs, and create game dialogue. I know I keep putting it off, but I plan to release a demo soon. That will happen only after both the battle and menu engines are complete. The reason these are not yet done is laziness.

And that's the main purpose of this blog. It is to encourage myself to speed up the process of development.