Saturday, 28 March 2009
Important bug
I've found a bug that sometimes, on a restore, leaves a sprite lying on every scene, a sprite that cannot be picked up. I can't reliably reproduce it. I thought at first that if you started a new game and restored a situation in which you were carrying a sprite, then it happened, but it doesn't seem to be that. Ho-hum... The position it occupies on the restored scene and all other scenes is the same as its original (i.e. game start) position. Later (much later, days later) I stumbled upon the bug again and can now reproduce it. It happens if I put the key in the inventory, then exit the inventory and save. Then I enter the inventory and pick up the key and restore. Now I can reproduce it, it should be simple to fix!
Friday, 27 March 2009
Development problem solved
I was finding that new versions of the code were not being acknowledged in Firefox, so that even if I made a change, it kept the old code.
Discovered that you have to bring up the Java console and type x to clear the classloader cache. At first, IE didn't seem to have the same problem, but that was probably because I restarted IE every time I tested it.
Anyway, to be on the safe side, I clear the classloader cache every time now.
And using mousePressed() instead of mouseClicked() works a treat. The mouse response is very much better now.
Discovered that you have to bring up the Java console and type x to clear the classloader cache. At first, IE didn't seem to have the same problem, but that was probably because I restarted IE every time I tested it.
Anyway, to be on the safe side, I clear the classloader cache every time now.
And using mousePressed() instead of mouseClicked() works a treat. The mouse response is very much better now.
Development system
Over the last few days, I've set up a simple development system using command line calls to javac etc. I've installed EZ Document Safe to keep the sources and versions in order.
The good news is that the original code still compiles and runs.
I have found out why the mouse click doesn't work so well. If you drag the mouse a little when you press, you don't get a Clicked event; you may or may not get a Dragged event; you may get both; and it all depends on the JRE platform, the timing and how far it was dragged. There's a certain amount of discussion on SunWeb about the matter, and I used a test application to see what was going on.
I've devised a new system which ought to work on all platforms. I'll try it soon.
I have also downloaded JLayer, an mp3 player. It works in free-standing mode, but I don't know how it'll fare when I try to incorporate it into my code. I may just run it in a separate applet like the current midi ones.
The good news is that the original code still compiles and runs.
I have found out why the mouse click doesn't work so well. If you drag the mouse a little when you press, you don't get a Clicked event; you may or may not get a Dragged event; you may get both; and it all depends on the JRE platform, the timing and how far it was dragged. There's a certain amount of discussion on SunWeb about the matter, and I used a test application to see what was going on.
I've devised a new system which ought to work on all platforms. I'll try it soon.
I have also downloaded JLayer, an mp3 player. It works in free-standing mode, but I don't know how it'll fare when I try to incorporate it into my code. I may just run it in a separate applet like the current midi ones.
Thursday, 26 March 2009
Some Story and Setting Outlines
Chinese Myst - Ideas
Major features :
o 3 mountains, each with a different character
o Bridges which need to be deployed
o Stairways and paths
o Pagodas, elevators, secret compartments and passages
o Monastery
o Nothing that's inappropriate technology, so use water power, clockwork, rope and pulley, steam etc.
o Locks, Puzzle locks, trapdoors
o Parts to fit in a matrix or jig-saw
o Logical puzzles
Despite appropriateness of technology, allow a little magic - tiny dragons, animated statues, self-igniting candles, ghost, fireworks, distant events in a crystal ball or animated picture or model. Also the fan is the equivalent of the Myst book (teleport mechanism).
Temple dogs, vases, chest of many drawers, lamps, screens, nested objects, musical instruments, cabinets, boxes, gong, water clock, teapot.
? Boat travel ? Aerial Runway
No language or writing, but perhaps some simple symbols.
Tiny model of the game world.
The Objective
(i) Must be revealed without verbal description so it could be demonstrated in a picture or a fan.
(ii) NOT the following hackneyed objectives:
a) Lord of Evil - destroy him... NO!
b) Imprisoned Princess - free her... NO! NO!
c) Save the Planet... NO! NO! NO!
d) Find the Ultimate Treasure... NOT AGAIN!
(iii) Well, perhaps a treasure hunt with trophy case. Collect seven treasures. The empty trophy case at the beginning, the filled one ends the game. A picture shows how the trophy case should look.
Saturday, 14 March 2009
Parallel Development
I've now described the original game, and delivered the sources for public consumption. Next, I shall embark on a new generation of the game.
Writing this game all by myself is going to be a bit of a challenge and a trifle lonely. Three threads have to be handled:
First, I'll set up a new code development and test environment. I don't even know if my 2003 code will still compile and work if I recompile it with an up-to-date Java. Most of my early development took place on J++, which, despite its shortcomings, was a pretty friendly development environment. Latterly, I was using the Sun bare bones development system. I flirted with Borland JBuilder for a while, but it was more trouble than benefit.
Writing this game all by myself is going to be a bit of a challenge and a trifle lonely. Three threads have to be handled:
- Engine code development
- POVRay images development
- Story development
First, I'll set up a new code development and test environment. I don't even know if my 2003 code will still compile and work if I recompile it with an up-to-date Java. Most of my early development took place on J++, which, despite its shortcomings, was a pretty friendly development environment. Latterly, I was using the Sun bare bones development system. I flirted with Borland JBuilder for a while, but it was more trouble than benefit.
Tuesday, 10 March 2009
Returning to POVRay
I no longer have the POVRay source I used for the example game, but the current (2008) version is not so very dissimilar, so I have stored that at http://amazonsystems.phpzilla.net too.
The whole of the game world is contained within the single source file China3.pov. Quite near the beginning of the file, you can choose a scene number. The approximate aspect covered by the scene number is described in a comment.
The islands are described by the height file Output.tga.
What you get is a terrain marked out in triangles. I have given it a jade texture, which seems to suit the angular effect. Some of the textures I have specified are rather simple and will be altered for final rendering, as they take too long for testing if complex.
The world is not very rich in variety as yet. I intend to add details such as trees and other plants, stones, and various "natural" features. Other scenery will include tunnels, stairways and buildings. I have included a bamboo object to use as building materials, with the bamboo.gif file for texture.
The game itself will require buttons, levers, doors, bridges, mechanisms and no end of cunning stuff, but often, though they may be designed in POVRay so that they match the surrounding illumination and background, they will be delivered in the game as sprites rather than as scenery, so that they can move.
Saturday, 7 March 2009
Public access to Bridge files.
I eventually settled on phpzilla.net, which provides 5 Gigs free storage (at the expense of a little banner advertising on web pages and a few splash pages which inconvenience me, but not the user). You can see the address in my links listing in the sidebar.
Wednesday, 4 March 2009
Public File Access
Although, by the time you read this, the problem will be solved, I felt it worthwhile to air the alternatives I am considering.
Since we may finish up with quite a lot of data, especially images and mp3s, I am reluctant to host them at my base website - amazonsystems.co.uk.
At first, I thought humyo.com the ideal situation for the public airing and sharing of files. I set up a Bridge account and uploaded some data files to it. However, it developed that files stored there were not freely available to web users who did not have their own humyo account. A possible solution is to set up a "guest" account at humyo, an account with read permission for the Bridge account, and publish the username and password on the blog, so anyone could have access. The downside of this is that the huge filestore (10 Gigs) on the guest account would be tempting to spammers, pornographers and other time-wasters. You can be sure they would not fail to exploit the space in some horrid fashion, and I would get the blame.
A "public" Gmail account could be used. Ideally, the data could be held as attachments to bogus emails (this usage of Gmail is quite common). Again, unfortunately, such an account would be open to abuse.
In either of the above instances, I could deliver the keys of the accounts only to those who requested them, but this would discourage casual surfers and people of a suspicious disposition, without protecting me from those who pretended an interest only to gain access to the online storage for their own ends.
The ideal medium for public data is webspace, and I am confident of finding some free webspace somewhere. I am already using a few such sites for various fringe projects, but all have rather small webspace quotas for free users. I may finish up paying for extra webspace on my own site. Sigh.
Since we may finish up with quite a lot of data, especially images and mp3s, I am reluctant to host them at my base website - amazonsystems.co.uk.
At first, I thought humyo.com the ideal situation for the public airing and sharing of files. I set up a Bridge account and uploaded some data files to it. However, it developed that files stored there were not freely available to web users who did not have their own humyo account. A possible solution is to set up a "guest" account at humyo, an account with read permission for the Bridge account, and publish the username and password on the blog, so anyone could have access. The downside of this is that the huge filestore (10 Gigs) on the guest account would be tempting to spammers, pornographers and other time-wasters. You can be sure they would not fail to exploit the space in some horrid fashion, and I would get the blame.
A "public" Gmail account could be used. Ideally, the data could be held as attachments to bogus emails (this usage of Gmail is quite common). Again, unfortunately, such an account would be open to abuse.
In either of the above instances, I could deliver the keys of the accounts only to those who requested them, but this would discourage casual surfers and people of a suspicious disposition, without protecting me from those who pretended an interest only to gain access to the online storage for their own ends.
The ideal medium for public data is webspace, and I am confident of finding some free webspace somewhere. I am already using a few such sites for various fringe projects, but all have rather small webspace quotas for free users. I may finish up paying for extra webspace on my own site. Sigh.
Tuesday, 3 March 2009
Panic over
The stricken site - Carfilhiot - has now been repaired. I had a MySQL backup of the site which was in Nucleus, and foolishly decided to convert it to WordPress manually, rather than use a conversion utility. This had the advantage of enabling me to check links and make small corrections, but it was time-consuming in the extreme, and I have only just finished. Work got in the way, too.
Tomorrow, I'll get started on a few more ideas I'm contemplating for the game system.
Tomorrow, I'll get started on a few more ideas I'm contemplating for the game system.
Subscribe to:
Posts (Atom)