Wednesday, January 11, 2006
New rooms, new ideas
Just added some new rooms to the spellcasting experiment. Originally thought I'd add more spellcasting methods, but they aren't at a plug-and-play level. I might see if I can adjust that sometime to more quickly allow new commands, although it might require rewriting significant parts of the code. Ah well, it's really not that great as it stands. For the time being though, I suppose I'll continue to push it and see if it ends up with anything interesting.
Perhaps after a few more short introductory expansions to this build, I could actually see if I can devise a complex puzzle, instead of casting your newest spell at a new object.
An idea that occurred to me was to make the limit of items the player can carry much smaller - perhaps three - and force the player to go out and solve a puzzle, armed only with three items, which in this case will certainly be different books (since I haven't really added anything else). On the other hand, this makes it even more pointless to memorize things. Perhaps, should I rewrite this, I'll just let the player cast spells from any book s/he is holding, and do away with the code I've added to the Read function. Another idea I had considered adding to this style of challenge would let me easily control what manipulations the player is and isn't capable of - by requiring certain items to perform certain manipulations, the player wouldn't learn them from some process I had not yet determined, but rather, to perform some manipulation other than normal casting, they would require a specific item. This would mean a player could attempt to tackle a puzzle with either a variety of different energies, or a variety of things that could be done with a single energy, or some compromise of both. Somehow it seems like it would take away from the environment of an IF game, but it would at least create a simple environment of its own. The primary feature I see with puzzles like this would be the greatly increased replayability over a standard IF program. So long as I could create situations with multiple solutions, it would not be as limited as a standard adventure game, which once finished, is often pointless to resume.
Anyway, I'll see how far I can push this build, but I may sometime rebuild it entirely to see if I could make it any smoother for expansion, and start some additional programs to highlight parts of the code for the main project.
Perhaps after a few more short introductory expansions to this build, I could actually see if I can devise a complex puzzle, instead of casting your newest spell at a new object.
An idea that occurred to me was to make the limit of items the player can carry much smaller - perhaps three - and force the player to go out and solve a puzzle, armed only with three items, which in this case will certainly be different books (since I haven't really added anything else). On the other hand, this makes it even more pointless to memorize things. Perhaps, should I rewrite this, I'll just let the player cast spells from any book s/he is holding, and do away with the code I've added to the Read function. Another idea I had considered adding to this style of challenge would let me easily control what manipulations the player is and isn't capable of - by requiring certain items to perform certain manipulations, the player wouldn't learn them from some process I had not yet determined, but rather, to perform some manipulation other than normal casting, they would require a specific item. This would mean a player could attempt to tackle a puzzle with either a variety of different energies, or a variety of things that could be done with a single energy, or some compromise of both. Somehow it seems like it would take away from the environment of an IF game, but it would at least create a simple environment of its own. The primary feature I see with puzzles like this would be the greatly increased replayability over a standard IF program. So long as I could create situations with multiple solutions, it would not be as limited as a standard adventure game, which once finished, is often pointless to resume.
Anyway, I'll see how far I can push this build, but I may sometime rebuild it entirely to see if I could make it any smoother for expansion, and start some additional programs to highlight parts of the code for the main project.
Tuesday, January 10, 2006
Old Stuff
I made a short little world to test out a spellcasting system some while ago. I decided to try to test out the ZPlet Z-Machine for Java, and by adjusting the default html file, and renaming my .z5 file to smuggle it through the free webhosting filters, it seems to work groovily.
I'm not sure if I'll actually continue to develop this spellcasting system into anything, because it's pretty sloppily coded. I suppose it's an experience thing - if I get this to work efficiently, I will have created something efficient. But anyway, whoever ends up reading this can experience a few rooms with an extremely primitive spellcasting system. And I know vague cases, like "CAST LIGHT" instead of "CAST LIGHT ON STICK" are screwed up, so maybe I'll update that sometime.
Anyway, the prototype is at http://bbinform.50megs.com/project.html.
I'm not sure if I'll actually continue to develop this spellcasting system into anything, because it's pretty sloppily coded. I suppose it's an experience thing - if I get this to work efficiently, I will have created something efficient. But anyway, whoever ends up reading this can experience a few rooms with an extremely primitive spellcasting system. And I know vague cases, like "CAST LIGHT" instead of "CAST LIGHT ON STICK" are screwed up, so maybe I'll update that sometime.
Anyway, the prototype is at http://bbinform.50megs.com/project.html.
Monday, January 09, 2006
Introduction
I think I'm actually going to see if I can get this thing in the air and just code something in Inform. Despite the fact that RPG's are supposed to be difficult to program, I think for a simple project, such as what I've been looking at with Inform, it would be one of the simpler games that one could create.
Particularly since I don't have access through Inform to use fancy things like graphics and sound (well, those are possible, but they're certainly not a primary feature of the interface), I'd like to try to be at least somewhat innovative. Therefore, it is likely that much of this project will be random, spur-of-the-moment code, but I have, contrary to my style, decided to plan out much of the design in advance.
In an order yet undetermined, I've decided my RPG needs a few systems that can exist fairly independently. Character class can be reduced to little more than a variable set at the beginning. However, to differentiate the classes, there needs to be something along the lines of a skill/spell system in place. This shouldn't actually be much more than a multidimensional array that points to appropriate skills, perhaps with other dimensions to allow non-class-related skills/spells. With an independently developed skill system, I should be able to simply add the skills referenced by the arrays, seamlessly and painlessly.
I also believe there should be an independent combat framework. Naturally, this will allow me to just specify enemies for a certain encounter, and then not have to worry about the remainder of the combat, as it will be passed entirely to the combat module. I'm not yet certain how the combat system will actually work, since the lack of a graphical interface seems crushing to ranged weapons, and programming ranged weapons in an independent node could be a challenge, unless I can specify extra conditions for given terrain variables.
These are the primary systems that I believe I will code for the project. The non-combat environment can be easily input, since I am using the Inform language. This leads into the question of why I am using Inform. I'm not entirely certain if I have a definite reason for it - I had originally wanted to create an interactive fiction project, and despite the RPG qualities of it, it is still IF. Perhaps it could be considered a mesh of both - an IF/RPG hybrid, if such a thing can exist. A drawback that may actually be an advantage, should I cite the language I am using, is the lack of graphics, which would probably cause me to abandon the entire thing. However, even given the elementary graphics that I could implement (assuming that I don't crack open my ATI and nVidia API's), it may be more immersive to simply describe the world, Zork-style. Additionally, this should allow far greater interactivity than a typical computer RPG. The possibilities are not as great as those under a creative DM in a pen-and-paper RPG, but even if many things result in typical Z-code error handling, they are still open possibilities that the player is free to try.
With a small bit of research, I'm actually pleased with the versatility that can be given to the Inform language. While my Inform compiler creates Z-code which can normally be understood only by a compiler such as Winfrotz (which is a 16-bit application, although there is a Win32-compatible program created by Andrew Plotkin that I haven't yet tried which I believe will also interpret .z5), I've seen some applications that can allegedly create an Inform executable, which would allow me to distribute a single executable file. Yet, an alternative to this, which may be more useful for earlier tests of the game, is to use an applet, now located on an abandoned Sourceforge project, to load my Z-code as a Java applet. It's likely that I'd be able to upload the applet and my Z-code to another site and instantiate the applet on this site, or otherwise, link to an applet that will execute my code.
In all, I actually intend to occasionally update this site as progress is made.
Particularly since I don't have access through Inform to use fancy things like graphics and sound (well, those are possible, but they're certainly not a primary feature of the interface), I'd like to try to be at least somewhat innovative. Therefore, it is likely that much of this project will be random, spur-of-the-moment code, but I have, contrary to my style, decided to plan out much of the design in advance.
In an order yet undetermined, I've decided my RPG needs a few systems that can exist fairly independently. Character class can be reduced to little more than a variable set at the beginning. However, to differentiate the classes, there needs to be something along the lines of a skill/spell system in place. This shouldn't actually be much more than a multidimensional array that points to appropriate skills, perhaps with other dimensions to allow non-class-related skills/spells. With an independently developed skill system, I should be able to simply add the skills referenced by the arrays, seamlessly and painlessly.
I also believe there should be an independent combat framework. Naturally, this will allow me to just specify enemies for a certain encounter, and then not have to worry about the remainder of the combat, as it will be passed entirely to the combat module. I'm not yet certain how the combat system will actually work, since the lack of a graphical interface seems crushing to ranged weapons, and programming ranged weapons in an independent node could be a challenge, unless I can specify extra conditions for given terrain variables.
These are the primary systems that I believe I will code for the project. The non-combat environment can be easily input, since I am using the Inform language. This leads into the question of why I am using Inform. I'm not entirely certain if I have a definite reason for it - I had originally wanted to create an interactive fiction project, and despite the RPG qualities of it, it is still IF. Perhaps it could be considered a mesh of both - an IF/RPG hybrid, if such a thing can exist. A drawback that may actually be an advantage, should I cite the language I am using, is the lack of graphics, which would probably cause me to abandon the entire thing. However, even given the elementary graphics that I could implement (assuming that I don't crack open my ATI and nVidia API's), it may be more immersive to simply describe the world, Zork-style. Additionally, this should allow far greater interactivity than a typical computer RPG. The possibilities are not as great as those under a creative DM in a pen-and-paper RPG, but even if many things result in typical Z-code error handling, they are still open possibilities that the player is free to try.
With a small bit of research, I'm actually pleased with the versatility that can be given to the Inform language. While my Inform compiler creates Z-code which can normally be understood only by a compiler such as Winfrotz (which is a 16-bit application, although there is a Win32-compatible program created by Andrew Plotkin that I haven't yet tried which I believe will also interpret .z5), I've seen some applications that can allegedly create an Inform executable, which would allow me to distribute a single executable file. Yet, an alternative to this, which may be more useful for earlier tests of the game, is to use an applet, now located on an abandoned Sourceforge project, to load my Z-code as a Java applet. It's likely that I'd be able to upload the applet and my Z-code to another site and instantiate the applet on this site, or otherwise, link to an applet that will execute my code.
In all, I actually intend to occasionally update this site as progress is made.
