How to implement a board game like interface in LibGDX using Scene2D - java

I'm just starting with game development and decided to make a 2048 clone using LibGDX to learn the basics.
I started to implement it using a simple 2D array and it works, but the problem is that there aren't any animations. So, for example if there's a tile that is at position [0][0] and after the user swipes the screen it has to move to [0][3], that transition occurs instantly (since I'm basically just updating my 2D array and re-rendering the tiles).
I was told this kind of board game-like UI is the perfect scenario to use Scene2D. I can very easily implement the basic 4x4 grid using Actors, but my question is, how do I correctly manage what is essentially a 2D structure using a Scene2D?
I already have the algorithms to handle where to move the tiles if the user swipes the board (left, right, top, down) and update a 2D array, but it feels like if I'm using a Scene2D, using this secondary 2D array data structure is overkill.
Right now my approach is:
Create a 2D array and Scene2D with my tiles
When user swipes, update the 2D array with the new position of the tiles
Iterate over the actors in the Scene2D and compare it with the tiles I have in my updated 2D array. If there have been changes, animate them (basic transition from the tile's original position to it's final position)
I just felslike I have unnecessary steps and also and unnecessary data structure here.
What would be the correct way to handle this sort of scenario?
Appreciate helpful advices, thanks!

Are you putting your tiles in a TableLayout? Just drawing it over won't work, as you have discovered.
To animate it you will need to define a MoveAction.
MoveToAction moveAction = new MoveToAction();
moveAction.setPosition(300f, 0f);
moveAction.setDuration(10f);
myActor.addAction(moveAction);
Example copied from:
http://www.gamefromscratch.com/post/2013/12/09/LibGDX-Tutorial-9-Scene2D-Part-2-Actions.aspx
I am not sure how this can be implemented if you are using TableLayout though.

Related

Proper way to do map generation in java

I was thinking about making a game with a map larger than the screen like most open world games. The question I run in to is when a player wants to move on the map how do I move the screen or how would I go about properly rendering new spots on the map. This is like any game such as Mario, awesome tanks 2, basically all tile map 2d games.
So formally my question is "How would I go about rendering new parts of a tile map".
Here is my exact situation:
I have a text file that contains a grid of numbers. Each number represents a texture and have their own properties. Now when I generate this I can create a panel and add all the tiles on to it and only show a 7x7 grid. Now as the player hits the keys the map should move as the player stays in the middle of the screen. Now the only way I can think to do this is to render all the tiles at once bigger than the frame itself that way only a 7x7 grid is showing at any given time and than change the x and y of the panel containing all the tiles. This seems really inefficient beings that it's rendering the entire map at the same time. So in conclusion when a player moves they should stay in the center of the screen and move the map in the background. And since the background is bigger what is the best way to do this.

Stage is bigger than the screen in LibGDX, how to fit it in the screen?

I'm developing a game in libGDX, and the levels in my grid contains a grid actor which contains mirrors inside (see my game). The problem is that the grid is too big and I want to be able to see all the stage.
I'm using an OrthographicCamera and an ExtendViewport.
I tried using frustrum (I don't really know what it is): I create four BoundingBox (left, right, top and down) which are placed out of the grid. I set the camera position to the middle of the grid actor and i make a loop zooming the camera until the boxes are in the frustrum, but I don't know if it is the best solution...
I think you want to use a FitViewport, which will make sure you don't 'spill' off the screen.
FYI, the frustum is used to determine depth of your camera- how far it can see. I agree that that won't help you in this situation.

Rendering very big 2D Map

I want to create a 2D Game with Java and LWJGL. It is a retro styled RPG game. So there is a really big map(about 1000x1000 or bigger). I want to do it with tiles but I don't know how to save it/how to render it.
I thought at something like a 2D-Array with numbers in it and the render just sets the right tile at the right place.
But i think the bigger the map gets the more it will slow down.
I hope you can help me. :)
My second suggestion was to make a big image and just pick a part of it(the part where the player is) but than its hard to know where I have to do a collision detection, so this ist just an absurd idea.
Thank you for your suggestions!
As one of the comments mentioned, this subject is far too large to be easily covered with a single answer. But I will give you some advice from personal experience.
As far as saving the map in a 2D array, as long as the map is fairly simple in nature there is no problem. I have created similar style maps (tiled) using 2D integer arrays to represent the map. Then have a drawing method to render the map to an image which I can display. I use multiple layers so I just render each layer of the map separately. Mind you most of my maps are 100x100 or smaller.
I would recommend for such large maps to use some sort of buffer. For example, render only the playable screen plus a slight offset area outside of the map. E.g. if your screen if effectively 30x20 tiles, render 35x25, and just change what is rendered based on current location. One way that you could do this would be to load the map in "chunks". Basically have your map automatically break the map into 50x50 chunks, and only render a chunk if you get close enough that it might be used.
I also recommend having the drawing methods run in their own thread outside of the main game methods. This way you constantly draw the map, without having random blinking or delays.
I'm maintaining my 400*400 tiles map in the Tiled map editor and render it with the Slick2D framework. It provides support for rendering only visible subsections of the map. (TiledMap class).
I've tried both approaches - Image based and tiled based map creation and ended up with the latter. With tiles you can not only create the view of your map but also invisible meta data layers, like collision, spawn spots, item locations etc.

Efficient algorithm for collisions in 2D game?

I'm programming a Bomberman in Java following a tutorial (this is my first game).
The tutorial suggests the following code for detecting collisions.
for (int p=0; p<entities.size(); p++) {
for (int s=p+1; s<entities.size(); s++) {
Entity me = (Entity) entities.get(p);
Entity him = (Entity) entities.get(s);
if (me.collidesWith(him)) {
me.collidedWith(him);
him.collidedWith(me);
}
}
By now, entities is an array list containing the enemies and the player.
As I want to also detect the player collides with walls, should I put every single wall or bricks tile in the level into the entities arraylist? If so, isn't this algorithm very inefficient? These tiles aren't going to collide with other tiles, so I was thinking to manage game entities in different lists. What do you suggest? Is there a more efficient algorithm to do it?
Note: I already read other questions related to collisions in 2D games.
Thanks a lot.
I suggest reading this excellent article about how ghost movement and collision detection works in PacMan.
Then I would suggest logically modeling your Bomberman levels as a collection of tiles. Each tile represents a discrete position in your level, and it is not logically possible to ever be "between" tiles or occupying two tiles at the same time. Each tile can track what sort of terrain feature is currently on it, and whether or not it is a valid destination tile for the player (and the enemies, potentially with different rules for each if the enemies are allowed to traverse terrain that is normally impassable for the player).
Then you don't need a collision detection algorithm for every object in the world. When it comes time for an enemy to move, or when the user tries to move their character, all you have to do is check all the tiles that are adjacent to their current tile (4, or 8 max if you allow diagonal movement), see if each tile represents a valid movement direction, and block the movement if it is not in a valid direction.
And to answer your question, yes, iterating every object in the world on every position update will be very inefficient.
There is another way to use grids for collision system. I'm using more complex version of the Aroth's suggestion and using this to fix collision bugs.
Theoretically this system is the fastest(assuming you are doing this check if(Grid[x][y] ==true)) because it only uses a single Boolean check for each entity(the things that can move).
Note: In the above grid check example, I've used a 2 dimensional array of booleans that sets the coordinates of impassable grids to false.`
If you are not worried about physics like bouncing from a wall you can use this:
1- Divide the map into grids.
2- Making every entity only fill a tile would be better but not necessary.
3- Store the previous position or the grid of the entities.
4- Whenever an entity moves, before visually updating their location (also before
doing other calculations) check the grids they are in. If they are in grid
that is not empty or simply in a grid that they are not supposed to
be, return their position back to the previous position (which you have stored).
If you want to allow entities to move freely inside the grids(the grids are bigger than the minimum distance they can move) then you need to put them adjacent to the grids they've entered and they weren't supposed to. Otherwise just return them back to the previous grid.
If you want them to bounce from the wall you can still use this but I'm not sure how many features can be added to a collision system like this.
May I recommend my own project. But it's still wip.
https://github.com/YagaoDirac/Dirac-2d-collision-detection-for-games
It's based on quad-tree which handles sparse pretty well.
It supplies collision group. This conception is also used in both UE and Unity.
It support only circle vs circle and overlapping only for now(2022 feb 22).
I plan to make at least AABB, and collision which at least stop your pawn from leaving the map.
I may also provide another system based on fixed grid.

Android: What is the best way to go about implementing a board for a game?

I'm starting work on a game, with the majority of all actions taking place on the 4x3 board in the middle of the screen.
As far as Android is concerned, what would be the best way to go about implementing said board? I was considering GridView, but that seems to be more focused on being a list of items than an actual board. I need to know the coordinates of pieces on the board, and not every space will always be filled. Can anyone point me in the right direction?
Try TableLayout.
Tutorial: http://developer.android.com/resources/tutorials/views/hello-tablelayout.html

Categories

Resources