Pages

Summarize Your Life.

2007/09/02

I'm finding subsequent posts hard to start. . . .

It's true, I'm no blog-head. I can't just start writing about anything and everything like a lot of other people manage to do daily (or for some, hourly). Perhaps it's because I'm not sure I have much to say that is constructive to add to the universe; or just maybe any time I've tried to start another post, I've gotten a temporary form of writer's block.

Well, this time, at least, I won't let me get me. . . .

And so, I'm going to force myself to write something, anything, that is not directly connected to my story series. I still can't say how frequently, but I'm sure it'll be in the three to four times in a month range.

Someone suggested breaking up long posts into a series of shorter ones, but it doesn't work for me. As a writer, I'm trying to go for content, and once I get the urge to write, I've gotta take that hill, charge up its slope, and plant my flag at the top with whatever thought processes survived the insurgence against writer's block, as a contiguous post.

Post 1, Part 2.

As an addenda to the first post here, on developing writer's software, I will say I've also been using OpenOffice.org since, oh, around version 1.1.2 -- and I will always continue to find a use for it. However, it still doesn't have all the features I need to write stories (those features I mentioned as targeted for development). Only for the briefest of moments did I consider writing an OpenOffice extension for some of these details, but the reality of the idea would have been more than I could've managed at the time.

I had been using a developer's IDE for a while before that, and looked into the feasibility of developing a writer's software suite to mitigate all the writing details I had planned to keep track of. The IDE that I mentioned went by the name of Borland C++ Builder, version 3, which I picked up in a bargain bin for only about four dollars and tax. I liked the WYSIWYG-style of developing program forms and stuff, but got sidetracked with all the additional third-party pieces I would have had to add just to develop the thing. Not really a big problem, if developing just for my own self, but 1) I was also learning about the benefits of open source and what it had to offer the programming community, and 2) some of those third-party extensions were under particular licensing modes that might not translate into open sourcing components and code. Further, 3) the few available writer's software that I could find in my Internet searches (circa 2000 to present) either a) were costing more money than I had at the time or would consider necessary for a writer's software type of thing to cost; b) were specialized to one particular task of story writing or were otherwise "locked in" to some details or sub-set of what I envision software-assisted writing to be; c) did not do their features well, had a "clunky" interface, or otherwise confused the user; d) were on a different operating system than I had, with no indications that a port of the program would be made; or e) if the project was open source or code made available, wasn't licensed clearly with something like the GPL.

If you go the route of 3.b. above, you often have many programs installed just to handle the different aspects of one story. Which means, in the end, you end up with files all over the hard drive for the same story; further, many authors like to save versions of their stories, inherently increasing the size of data exponentially. Now, current computers can handle this, and even in older computers the data can often be compressed to an archive or burned to a CD as backup. But it feels like a waste of efficiency and energy to have multiple programs for different aspects. At one point in cleaning up files on my system, I accidentally deleted several files that much later I realized I needed, but couldn't retrieve because the space was overwritten. This was but one more straw on the camel's back that led to the process I'm in today.

I thought about what I wanted to do about it all, and finally came to the decision: a) I wanted to develop something that would be able to handle whatever aspect of writing that might come to mind or be required for the genre I write; b) it should be easy to navigate, to write and design the fictional world or universe that is the milieu of the story, to the point that writing with this application is perceived as smart design; c) the whole entirety should be available as an open source project, and designed to be cross-platform, which meant it could be run on any operating system or platform with little to zero additional configurations; and d) should have a common-sense approach to matters, or allow for such to be made.

At the turn of the century, I hadn't really been too concerned over what programming language(s) to learn, beyond having a distaste of my community college's attempts to teach me COBOL, FORTRAN, and other languages that were becoming obsolete. But for the last half of my decision, I needed to find something that could work on multiple platforms and be easily licensed. My search would eventually lead to Sun Microsystems' Java runtime environment as a platform, and a consideration of the GPL as a license.

Another good thing about the openness of software -- as differs from but relates to the concept of open source software -- is that developers are more open to the idea of creating and implementing an open format for their program's data. I believe in this, and will be creating my writer's software suite's data in files of plain text and XML, which makes it easier to find problems if one might arise.

More modules I've forgotten to mention.

In my checklist of modules and features I listed in the first post, I forgot to include some modules in the list. From an overhead perspective, modules will either be purposed for 1) the writing project itself, as well as management of any abstract data, prototypes, and other templates; 2) user's tools and utilities that don't necessarily map to features in the writing project, but often are auxiliary features that the writer can and will use anyway; and 3) certain utility modules of use for exchanging data between other formats that are already available and in use.

Of those listed in my first post, they are of the first category of modules. Those listed here are ancillary modules which equate to some small utilities you may or may not be using already. Most notable of them, I've been designing a series of modules for keeping track of the submission of manuscripts and material to publishers, as well as miscellaneous time and costs of doing so.

Additionally, a module for keeping track of writing agenda, reminders to self, and literary to-do lists might be worthwhile; but I'll hold off on this one until I know it is needed, and in what capacity to design the interface for it.

The rest, of course, would be the third type of modules, but by necessity I cannot code and implement them until I have my own codebase implemented. Once my own stuff is underway and running well, I can get started on this one. (No sense trying to design the data-exchange procedures until I know what maps to what in the data files.)

Towards current and future development.

Perhaps you're wondering exactly where my software project stands right now, and where I'm going with it. Okay, here goes an attempt to explain:

The project itself is a Java application, but more than that, it's being built on top of the NetBeans Platform, which means I don't have to write the bootstrap/startup code as well as a lot of other behind-the-scenes window handling, because the NetBeans Platform has done it for me; I only have to develop the individual modules, menu items, and toolbars that provide the features I implement. This is great because it means the entire application is inherently modular; making changes to one module doesn't mean the whole application needs to be recompiled, only those which have changed due to the new code. The concept also means that another developer can add in their own modules if I missed any features that other writers want or need.

I've got the project space for it on SourceForge, which provides the version control repository for code as well as other developer's and user's tools. I'm having a slight issue with code checking into the repository, however, but I'm continuing to work on it.

And, yes, I actually do have the code that I've started developing, and a good number of the forms and a strong understanding of where I intend to go with the code and visual design. It's not some 'pie in the sky' project that got started and will never get completed. However, along with the above concerns, I've been holding on certain aspects of the development, as well as planning future steps. One hold on the project is in doing the graphical interface well, as well as implementing the features in code and determining what will work.

More intricately, I'm facing the inherent problem of how much detail to handle for each module. How much detail does the writer keep in their writing project at minimum, average, or maximum levels? For example, other programs usually have a way to describe the character with a name, a short bio, and perhaps a bit of story-forming and typecasting (like Dramatica does). Some writers (namely, myself, but perhaps others) would like to see different text boxes and detail forms for inputting different aspects of the character's bio, and perhaps would like to apply different methods of categorizing or typecasting the character. Knowing these details will allow me to create a better interface and code.

As for my needs, I'm quite ready and willing to code for the most detail in each module that I would use. The neat thing about getting more specific about each module's data is that I'd like to implement cross-linking data to other data, with everything indexed and searchable for possible story ideas you might gain from the effort. Character A, born on Planet P, working for Organization O under the boss Character B, in a relationship with Character C, et cetera, ad infinitum. . . .

Also, I have, on occasion, roleplayed my characters in certain situations, and therefore, am trying to consider how authors could plug in statistics and other roleplay mechanics into their records.

The problem, as it were, turns up to be licensing, and the willingness of roleplaying game system development companies to treat you like a criminal for using what they consider 'too much' of their copyrighted material. Whether you would want to use AD&D, d20, or other forms of roleplay mechanics as the core, I will not willingly include data that the developers of those RPG systems do not wish to be released in the program -- I feel that their choice is self-defeating, but cannot legally do something other than whine and moan about it. Their loss, not being more open to usage.

Therefore, I propose a concept, of sorts; the most daring thought I have, which I hope to be a solution, is of creating my own abstract roleplay system, generic enough to allow translation to those other systems via import and export filters, yet allow for enough intricacy that the finer points of transport to those other systems will not be lost. I like this idea, and even the thought of the magnitude of it doesn't bother me. I've even made a start on the process, but won't release this particular aspect until I've got more of other details implemented. Optionally, if another system were already developed that could handle this for my functionality, I might possibly be persuaded to go with that -- but the core requirement would be that stats and details from other systems would have to be easily imported and exported without the end-user worrying about losing features from their roleplay system.

And I just realized how much I've typed already. Wow, what a long post.

No comments: