possible future projects.txt

This is similar to ideas for new additions, but here are things that are more than a single idea; they are a bunch of ideas, kind of.
========

*LAZORS*

  • laser bridges
  • laser rails
  • laser "Redstone" (and receivers, emitters, etc)
  • laser barriers (poss. selectively permiable)

maybe lasers can be made using the "cloud cactus"?

Glass! But, like, triangle glass, so the laser can bounce off things. And, if you concentrate 3+ lasers, it will do damage... What about coloring? I think a prism glass block should be added to difract it into 3 colors (prob rgb), one going in each of the three other directions.

======

*Easter Eggs*

Add some Easter eggs into the game, like Christmas graphics or something.

Add the snake game I made in processing to minicraft as an Easter egg, accessible by typing the Konami code at the about page. Even better, maybe I could have it run a variety of my old games, picking one at random each time the code is entered... :D

======

*Inventory Sorting*

add key controls to move items around in inventory menu, one up/down, or to the top/bottom of the inventory.

Inventory categories also sound like a cool thing. Using the new menu system, I can add tabs to the PlayerInvMenu, and each tab will be a menu that contains the items of the corresponding type.

======

*Decoration Blocks and Variety*

Add more decorations that have no actual function...? Like furniture: chairs, tables, etc.

Or, even just having more types of the same thing sounds good.
Basically, add more stuff to make the game look pretty.

This includes new animals as well, such as wolves, chickens, etc.

======

*Localization*
(Be sure to credit whoever makes any given localization.)

...Yeah.

======

*Save/Load*

It would be really good if I could seperate all the stuff in the Save and Load classes into their respective classes -- I'm not saying remove them altogether, just take the stuff that turns a list of strings into a specific full entity object, and the stuff that brings all the class's important variables and states into a String, and put those parts into the matching class. Then, Load and Save will be there to go through all of them, and get them in a nice list or bigger string, and then write them to a file. Or vice versa for Load, it will read the file and turn it sequentially into entities. Of course, not to mention all the other things besides entities that Load and Save deal with!

So, what will be added to each class is:

  -TO SAVE: a method (getData(), I think), that compiles all the data, necessary to remake the entity, into a string. Maybe have a boolean fullSave or something that determines how much is enough to remake it; some things I may deem unnecessary.

  -TO LOAD: a constructor, I think, with parameters being all the stuff in the save. Oh, actually, no, better idea! It just literally takes the String! Hopefully thing won't be a problem... with Chest.java maybe, but if we make it a string and a boolean, then it should be good.


= Other related idea:

LegacyLoad class is becoming annoying to handle; it should be reimplemented so that it won't have to be changed at all to reflect future updates. This could be done by making it only return values, and not actually reference any current variables. This may prove overcomplicated, though.

IDEA: Let's make an "Update.java" file, maybe multiple, that handle different versions. However, instead of setting values in the rest of the game files, it will be set up as a "getter" sort of thing, where it doesn't reference all the game vars in full detail; but, it fetches them in the way that needs to be, for the main Load class. Basically, I want to have Load.java run everytime, but all the things that would otherwise be copied to LegacyLoad just stay in Load.java, and Load.java will "call" certain methods of LegacyLoad, to setup something the way it used to be.
Yeah, it's fishy, but.... there we go.

======