That''s an idea I''ve considered before now. You could certainly do it with just html, but the problems would arise with keeping inventory items for the next page...
This could be solved by using Serverside scripting (I''d suggest PHP, its syntax is much nicer than asp, its free, and much easier to learn than perl) by simply passing variables through the GET method (when you see a long url with blah.php?hmm=ho&teehaw=432g432gh4g3232&yuhuh=wheeee etc etc, then those are variables being passed via the URL (GET) to the parser) You would then just set cookies in the script to keep those values, perhaps reference a database (if you wanted to start making things more complex).... This would come with its own problems, if you didn''t use cryptic variable names and values, as people would be able to tamper with things in the url.

Anyway, so that would be easy enough. As for the HTML side, you could just use one big image, and use Layers with item images in, allowing you to create rollovers, image animations, even DHTML animation etc without having to animate the main image, resulting in huge filesizes, as you''d have to if you were to use image maps.

Heh, anyway, that''s a bit more complex than just using HTML, but it''s probably the most efficient method you''ll find. And php really isn''t very hard to learn at all...if you''re already familiar with c-style syntax, you could pick it up in a day. If, however, you''re used to basic-style syntax, perhaps ASP would be more up your street. And if you like confusing-style syntax, go for perl

Andru™ a registered trademark of the Globex® corporation.

Reconsider the implications of the term "game" and you suddenly see that HTML is quite viable for making a "game". Just don''t expact a highly dynamic graphical experience (ie, think "Play-by-Mail").

HTML is not a programming language.