Gameplay stats and roadmap

So, a small update on the actual game now: (Yay- something worth typing/reading!) I've spent the last week or 2 cleaning up my code, and putting a lot of error checking in. Most of the error checking, and it's associated output messages will not make it into a "release build" (for non-programmers, that's a version of the program that runs the fastest, with debug features disabled..), but they are SO incredibly useful for me during development, I'm surprised at how far I've gotten without them so far! Not to mention, that I was starting to get concerned with certain parts of my code becoming messy, and now, I'm actually quite happy with the state of my code. During this time, I've also moved a lot of the code around to where it belongs, etc...

Before I continue too far into coding new stuff, I'm going to take the time to document my code better so it's easier for me to quickly identify everything about my functions, down to the little details, so I can stop siphoning thru code to figure out some little thing about a specific function.

I've also recently written a video manager to wrap around the video driver provided by the LTE game engine. Yes, I'm still working on core objects for the game.

For anybody interested, here's some random statistics about the game:

Source code: 174kb in 35 files
Executable: 2,042kb (about 1900kb of this is just the core LTE game engine)
Content: 1.75mb in 25 files

Framerate during intro sequence:
With logo visible: 30 (logo covers most of the screen, and has heavy transparency)
Without logo: 60 (looks like it's capped here...)

If all goes well in the coming week or 2, I should have everything done with my current state (and bugs), and will be moving on to working on the world map. And additionally, a specialized form of the world map designed for in-game cinematic sequences. (This being merited by the Armortek trek across the snowfields into Narche at the beginning)

I've spent a tremendous amount of time optimizing code and wrapping my own stuff around LTE GE's functions. The result: A massive increase in speed/stability, not to mention slightly less memory usage.

My FPS stats from before are now officially ... not official. no more. During the beginning of the intro sequence (with the clouds...) the FPS is 30, and goes up as the clouds move off the top of the screen. I've still intentions to look into this, as it may manifest itself later in the game, so I should take care of it now. I wonder if it's something to do with displaying an image covering the whole screen, using alpha transparency?... kinda doubt it because the logo that fades in later uses even heavier transparency, and covers about 3/4 or more of the screen as well. I'll see about it later. Anyways, after the clouds have scrolled off the top of the screen, I get a constant 59/60 FPS (I typically get 59 even when it's actually 60. Likely a rounding issue..), even when my GUI is displaying, which is to blame for a good portion of my coding time recently. The FPS drops a bit (maybe to mid 40s) if I open up my debug test GUI window which uses a LOT of different GUI Elements at the same time, most of which are using transparency. I'll likely change this so it gives improvements in performance, but for now, it's fine.

I've also hit a bit of a milestone in the programming for this thing, and it's also a random stat I forgot to give you last post. This should give you some kinda idea about how much goes into this stuff (read: CRAZY!) The total lines of code I've written so far for the PSP version of my game is: 10,040. Holy crap. I can now officially say that this is the biggest programming project I've ever done. I've never broken the 10,000 lines barrier in a single project before. *champagne*

Of those 10,040 lines, 4,508 of them are JUST GUI stuff. Heh- almost half of my work so far is just in the GUI. But in a game that is based so heavily on the GUI, I feel that this is justified. ^-^v

So, stuff I've done recently:

The GUI is now completely customizable: To create a new GUI skin, all I have to do is create a new directory with the GUI skin's name, and fill it with the appropriate graphic/xml files defining that skin. The game will detect the new directory and give it as an option when the player is selecting their GUI look.

Animated 2D Textures: The LTE GE originally supports animated textures on 3D objects, but nothing for 2D (ie. GUI), so I've put in support for that. Meaning that now I have support for some very pretty looking effects on the GUI, besides just the moving cursor.

FPS based 2D movement: I've gone back and modified all my code that involves something moving on screen, to make it move a distance based on the current FPS. The end result, everything that -should- move at a constant speed, actually -does- move at virtually a constant speed no matter how high/low the FPS currently is. In reality, this wasn't much needed for what I currently have (except the GUI stuff), but it was very much so a good practice for me to know what I'm up against in the future when this will start being an issue.

Small graphical pretties: Little tidbits that give the game a more professional look. For example, when you select "load game" at the titlescreen, the load game window appears, and the cursor smoothly (albeit quickly because of how far in needs to move) moves across the screen to the appropriate spot in the load game window, instead of just instantly appearing there. Also, GUI groups fade in and out depending on what's active. Basically each "group" of GUI elements (typically, a window and all the stuff in it, is 1 group) can be in 1 of 3 states: Visible (100% brightness/visibility), Paused (35% brightness/visibility), and Invisible (0% visibility). Whenever a certain group's state changes, it smoothly fades to the appropriate values. This makes it visually very easy to tell which group is currently active, while still being able to see all the previous groups that lead up to the currently active one. Also, a "selection box" that hovers over the currently selected item in a menu (beside the cursor). It is fairly subtle, yet visible enough to easily notice. This box instantly moves to the next item selected, and is animated, while the cursor smoothly moves between items [very quickly]. It just makes it that much easier to pickup which item is currently selected. Got the idea from playing FFXII.

Stuff that is currently only partially finished because I'm waiting for the next release of LTE GE (it has some new functions I need!):

Finishing my custom skin class: The next release of LTE GE will have better support for stretching 2D textures on screen, which will make my life MUCH easier for the last little bits of my skin stuff, such as properly displaying GUI Images (so they'll be cut off when they should be!), and allowing me to finish off GUI Progress bars (currently it doesn't show the "progress" portion, only the border/background!)

Getting rid of the last crash left in the game: The next release of LTE GE will implement some functions to give me better control of which sounds are loaded into the PSP's ram or not. It will make my life MUCH easier (not to mention, make my game much more reliable) once those functions are available to me, to fix this crash. I could do it now, but it would take much work, and once those functions are available, I'd rewrite what I'd written anyways, since they'll make my code more efficient as well, so why bother until then, right?

Stuff currently on the table as my "next features to implement":

Proper method for anybody NOT using a 1.5 PSP to have sound. Right now the game assumes you are using a 1.5 PSP (or thereabouts), and just directly attempts to access the Media Engine on the PSP. On later versions of PSPs, Sony put in more protections and such, and now you need to load a special module to get access to the Media Engine. Not a big issue, except that I've been having sporatic success with loading the module, at best. I'm hoping to find something that works all the time.

Audio skins: In the same way as I have GUI skins, I'm toying with allowing the player to have audio skins as well. It should be relatively simple to implement, should I decide to do it, and all it would really do is give you custom sound effects for each GUI skin. This would be seperate of course, so the player could mix & match GUI skins with audio skins. Just a thought.

Additional Kanji support: Because of the way the LTE GE loads fonts, I have to manually add any kanji I'll need, into my font file. I'd like to go thru the Japanese script I've received from Sky Render (thanks buddy!) and add in at least all of the kanji used up until my intended "first goal" of the game, that being Figaro Castle. Perhaps farther, but I have a feeling that they kinda go all out with their kanji usage, and that would eat up more of my time than it will be worth. I'll look into it.

Script loading: Once I throw together some GUI layout files for the world map state (dialog boxes, etc..), I'll be toying with loading scripts into the game for display via these boxes. I'll likely be writing my own custom script files, instead of directly using Sky Render's, for those curious. I don't suspect this will be that hard, but I'll have to ponder exactly how I want to arrange the memory in the PSP for this. *ponders*

Alternative locations for GUI layout groups: Typically all the GUI layouts are well formed enough that they won't get in the way of the 3D action happening in behind them, but with the dynamic camera action that'll [optionally] be happening during battles and whatnot, some of my pre-decided locations for GUI elements (such as speech during a battle, etc...) may kind of get in the way. This is something I've only passively been thinking on, so it may not make it into the game, but I've thought that perhaps I should write an algorithm for detecting approximately where on the screen the action is taking place, and deciding which (of 2, likely..) place to display certain GUI stuff, when it's supposed to pop up.

Loading bar: I'm pressing for SiberianSTAR to write some functions into LTE GE to better facilitate my ability to put these in, but I honestly don't know if he ever intends to. Regardless, it IS still possible without, it'll just take a whole lot more coding on my part. Despite that the longest loading time so far on the game is roughly 5 seconds, this will very likely be making it into the game, it's just a matter of when.