At version 9b1158a, saving and loading is implemented by java serialisation API.
So newly created savegame size is around of 3Mb while the size of /res directory is about 300 Kb.
At this moment savegame contains classes, which doesn't need to be stored there.
For example:

• AwtSprite
• AwtEventsHandler

I suspect that png images are stored in savegame too.
Something must be done with this.

I think of following ways:

• design world serialisation format. It will take a lot of time.
• use common serialisation format like JSON. It is less time consuming, But I'm not sure if this format will fullfill our needs.
• Pick out classes, responsible for state of the world and remove all references to any other classes from them. We'll probably do this anyway.

At revision be761e9, class StockMethods.onScreen is public and static. It has hidden dependency to method StockMethods.computeDrawLocationInPlace, which should be called directly before using field StockMethods.onScreen.
This dependency should be clear. I expect that method StockMethods.computeDrawLocationInPlace shoud return onScreen value alongside with x and y.
Maybe Int2 class will be changed here. Maybe new class DrawLocation will be added, to reduce impact to other usages of Int2.

At version 42639a5 class Inventory is responsible for management content of inventory and for drawing its content to screen in two modes: inventory management mode and hotbar.
All these responsibilities should be split to several classes.
Hotbar is one of them.
I think it should contain:

• tracking of "current" item
• pixel math, used to display it on main screen

I'm going to implement hotbar by myself in recent future.

There are a lof ot pixel math involved with operations on inventory items.

• Inventory should compute their bounds on each redraw.
• To check if mouse is pointing to specific inventory item, Inventory should compute its bounds again.
  And there are a lot of methods, which operate only on one slot.
  Probably whole handling of clicks on inventory slots should be moved to InventorySlot.

At version 42639a5 class Sprite contains method draw, which takes GraphicHandler as argument and some drawing parameters.
This approach led to passing GraphicsHandler to every drawing function. In the end, GraphicsHandler will do drawing, not the Sprite.
I think that method 'draw' should be moved to GraphicsHandler class. It should take Sprite as argument.

There are some special cases with Inventory class. It should not change at this moment.

AKryukov92 Has corrected and improved the code structure for the game main menu. He did a great job. Now it is also possible to cross the trees without the player's block, making map exploration easier.

Find the link to the executable .jar in the project repository (README.md).

Would it be possible to make it so after a week or so an alpha build is built and ready to play so the people that can't build it themselves can test it?

Is networked multiplayer support planned?

At version 0f22fe3, I can't run the project because of missing dependencies in gradle.

At its current state, the cursor controls are very confusing and difficult to use. It seems like it points in the opposite direction I want it to, all the time.

Follow this link to see layout
https://files.gitter.im/LordStephen77/Lobby/iGfL/Screenshot-_33_.png
Right now there are no armor slots, so they should not be drawn.

@tobyplowy please tell how do you made title "INVENTORY". Which font is used? If it is just a picture, could you add it to this thread?

At version 9b1158a, speed modifier of tool type (Axe, Shovel, Pick) is hardcoded in java in file World.java
This property should be converted to map with key as "breakType" of tiles and value is speed modifier of tool.
It should be possible to describe multiple different breakType's for any tool type.

At version 9b1158a, tiles are grouped by break type in java code in file World.java
When this property will be moved to TileType, it will be possible to implement method "getBreakTicks(String toolQuality, Tool.ToolType toolType)"
It should be possible for any tile to be in multiple break type groups.
This approach will make tiles more configurable.

If we are going to implement achievements, then we should discuss why would we want to add them?
Think of at least 10 examples of achievements.
Will there be repeatable achievements?
Will achievements give player any rewards like items, special blocks?

I'd recommend to draw layouts only after we discuss those questions.

On the picture you can see crafting grid with three planks.

Game identified this recipe as recipe of sticks.
I think we'll get all kinds of troubles when we add more 2x2 recipes.
Assuming that template comparison process is very complicated, at this moment I file a report for future fix.

Better mapgen more biomes.

At version 3c582dc class Inventory is responsible for management content of inventory and for drawing its content to screen.
In addition, inventory screen has different modes:

• player inventory
• crafting table
  There will be another modes. Probably chest, furnace and so on.
  I'm thinking about making multiple classes without any connections. Probably they will implement single interface or inherit single class, but I don't know it yet. There is no need to do so at this moment.

I'm going to implement player inventory screen and crafting table screen by myself in recent future.

16x16 material-ey textures do not work ok in 2D like they do in 3D, because there is nothing to give them depth.

Some suggestions:

• Shape nodes to look like what they are, not just flat squares of texture. For example, tree leaves could be made solid (touching the edges) only where they connect to other tree leaves, and otherwise should have some transparent margin where they have a bushy outline (because at the edges the shape of the leaves will affect the outline).
• Switch to a higher resolution. It may be difficult to give the details needed to give the sprites more depth at 16x16 (but feel free to ignore this if you can do it)
• Make nodes smaller. Nodes might be a quarter of their current size, or even less, allowing some detail and shape to come from the placement of nodes so that less (but still something) needs to be done in the textures. Player digging and placement would need to be modified to work with a smaller node size, maybe with digging targeting all the nodes in a radius around the cursor, and placement placing multiple nodes at a time (configurable by user?)

At revision be761e9, information about tiles stored in static collection of class Constants.
We already has SpriteStore, so TileStore seems to be consistent way for storing content.
For the moment it doesnt need to be implement as children of abstract class.
Class with apropriate methods for accessing tiles information will be enough.

If class is abstract, then it is can have multiple childrens. Assuming that singletone should be instantiated only once, then this situation doesn't make sense.
In addition AwtSpriteStore has public constructor which ruins the idea of singletonius SpriteStore.
I think of several solutions of this problem:

1. Do not use Singletone pattern, instantiate SpriteStore in main(String[] args) and pass its instance to all classes that use SpriteStore. For small classes like Player it is good idea to pass Sprites to constructor.
2. Merge classes SpriteStore and AwtSpriteStore to single class. This option is suitable for using singletone pattern.

At version 9b1158a, difference in speed between wood, stone and metal tools is hardcoded in java.
Speed of tool should be moved to configuration file "tools.json". It probably should replace existing property "power".

If you press esc now it quits the game
A menu shuld popup and have a copple options
Like

Resume game (closes the esc menu)
Options (opens options for sound Graphics and so on)
quit game (go's to desktop)
quit to menu (title screen)

Class Inventory now has a lot of methods and fields, related to Crafting grid.
It seems it should be moved to separate class.

This is a place to Talk About different things like Graphics, ideas, improvements, or changes
(whatever realy) just try to keep the offtopic minimal ok :)

we all know hat a launcher does so no need to explane

The game menu is divided into two very similar classes: NewGameMenu and StartMenu. The main game menu is divided into 2 different phases:

• Home screen
• Second screen after pressing the "new" button.

I would like to unify the NewGameMenu and StartMenu class to simplify the customization of the game menu.

Or I can post comments to the code to remember all the steps.

New collaborators reading reviews will have easy life.

Comments are important! We comment on the code as I did at the beginning.

I probably realized a new package devoted to these two classes. I want to keep everything in order, and separate the menu from the rest of the project. I'm working on the new buttons, and the new header.

If you have good ideas, tips and more, I would be happy to share your thoughts. Thank you.

At version 42639a5, method Inventory.updateInventory contains a lot of conditions and loops and 141 line long. I think it should be split to several methods.
I expect all those methods will be a members of Inventory class but it is not mandatory.
All methods should be named properly in english.

At version 419d246, lots of classes contains game data and drawing methods.
If we are going to make networking implementation, then game data classes should not contain drawing classes and methods. Server don't need to draw anything anywhere.
Server should be able to receive determined commands, process them in the world and send updates to all who is interested.

I consider "game data" following classes:

• World (tile data)
• Entities (position, parameters)

This list might be updated in future.

At revision be761e9, method MainGame.startGame takes first parameter as boolean value. It is called 3 times with explicit values "true" or "false". Probably there should be two methods. One for each value of parameter.
I expect that all common content of method mainGame.startGame will be moved to new method with appropriate name.

Apple Trees
Banana Trees
Peach Trees

Crafting guide is needed to let people know what recipes exist in the game.

When making screen big screen it moves the heart to the center of the logo.

At revision be761e9, body of loop in method gameLoop() of src/main/java/com/lgs/dreamblocks/MainGame.java is 191 line long.
Code inside it should be split to several methods.
I expect all those methods will be members of MainGame class, but it is not mandatory.
All methods should be named properly in English.

To solve the old addictions of the game, I have been working on a small framework for writing 2D games written in Java for some time. This library is a collection of optimized and redefined code snippets for JDK 8. SGL2D (Simple Game Library 2D) is a very simple framework that works as a wrapper with the standard Java library. Does not use any external dependence! and not even JavaFX.

I'm going to test it shortly inside DreamBlocks. At the moment it contains everything you need to improve and simplify the project.

In the repository you find the project at the current state, which also contains the doc (javadoc) folder. If you are interested go to see. I have to work on the wiki to make some examples and first documentation to showcase the main features of the library.

The project was born as a study and research material. I've been thinking of rebuilding it to make this library the best solution for DreamBlocks. of course SGL2D allows you to develop 2D games of any kind! Only the module for the controller (Gamepad) is missing.

Features:

• Simple input / update / drawing chain
• Sprite sheet parsing
• Animations
• Sounds
• Easy camera movement
• Network classes
• 2D noise (e.g. for terrain generation)
• Read and write files and images easily

SGL2D only uses standard Java APIs, which makes it highly portable.

Official repository:

https://github.com/SGL2D

You can jump on water and you won't be able to sink.

At version 5291070, it is very easy to add subroutine, which will populate world with things like trees and water.
Just follow those steps:

• create class SomethingFiller in package com.lordstephen77.dreamblocks.fillers
• extend class WorldFiller
• implement constructor matching super
• implement method fill()
• Instantiate SomethingFiller in constructor of class World and call fill()

At version 5291070 we need:

• Mineral filler (Coal, Iron, Diamond)
• Grass filler
• Cave filler