#lines game

[zaharya]

WIP Lines Game

Rules: Share the last/first line(s) you wrote for your current WIP.

Oh my, I’ve never been tagged in anything before, thanks so much @lou-isfake​! This is the last line I wrote for my big WIP (Mine To Protect, chapter 39):

With the whole school watching them like hawks, they hadn’t had any opportunity to talk again.

Tagging @kellerific-writing, @blue-rose-smalls, @potion-daddy, @manixzen if you feel like it.

[misuterareta]

I have been keeping an eye on this game not because of the ads of the pretty ladies lol, but because of the beautiful attack skill animation. They didn't disappoint.

🎮 playing Exos Heroes

[worxtore-blog]

Lines 98 Classical Game with Admob

Download Now

DESCRIPTION: Lines 98 is a game play on board with balls of seven different colors. The player can move one ball per turn to remove balls by forming lines (horizontal, vertical or diagonal) of at least five balls of the same color. If the player does form such lines of at least five balls of the same color, the balls in those lines disappear, and he gains one turn, i.e. he can move another ball. If not, three new balls are added, and the game continues until the board is full. FEATURES: - Similar as original game - Nice animation - Java project can be imported by Eclipse - Admob intergrated with new Google Play Game Services - Small apk size when export COMPATIBLE: Compatible with old android devices from 1.5+ SUPPORT: If you have any question, don’t hesitate to contact me. I am willing to support you.

[ragingozzy]

The End Of The Line(s Game)

Before I forget to make this post, I want to go ahead and explain the situation of the Lines game. Short version: I am through working on it.I have worked quite a bit on the new version of the game, but I have reached the point of being very frustrated with the way things are not working. Everything is set up and working except for matching diagonals and properly drawing the status panel.

I do not have a good explanation of why matching diagonals does not work properly. The method is the same for all rows, columns, and diagonals; it is called with different parameters to change which direction the cell checking moves in (from left to right in a row, from top to bottom in a column, etc.).

The status panel (it only shows the score for now) behaves very strangely when it updates to draw the score. It paints the top portion of the game area underneath the score. I have absolutely no idea why this occurs. I have tried changing a few things around, but nothing seems to have an effect on it.

Visually, the game looks presentable besides the status panel issue, and the basic functionality of the game works smoothly. Also, this is the second version of the game I have worked on. All of these factors combined with my lack of interest in the game has caused me to stop working on it. I know it is bad to leave things unfinished, but I feel the irritation from this game would be detrimental to my learning if it continues to be my main focus in programming.

Saying all of this does not mean that I will never return to it, but I have no plans to at any recent time. However, this does mean that I get to work on my current fun project: Asteroid Runner. :D I will explain everything about it in the next post.

The "final" version of the Lines game is here.

[ragingozzy]

The Usefulness Of A Partner

It's time for another status update about my Lines game. After my last post, I began rewriting the game to clean everything up. I feel much better about the way things are written now, but I have yet again run into a problem that further solidifies my belief that my biggest weakness in programming is finding the non-critical bugs, and I need someone that is good at that type of thing.

I believe I am almost finished with my new version of the game, but I am stuck trying to build an algorithm that checks for matching pieces. In my previous version of the game, I found a design online that I slightly modified and implemented into the game. Based on what I learned from that, I intended to create my own methods. Without directly looking at the previous code but remembering some of the ideas, I am creating an algorithm that is my own.

Based on what I have been seeing online, I am understanding the usefulness of creating a method once, and passing it different variables to perform different functions. I know that seems relatively obvious, but I shall explain. My friend, who has been working on the same project, wrote 4 separate methods to check for matching pieces in his code. I set out to create 1 method and, based on what I passed it, perform checks on all 4 different directions. I have the same method called 6 times (row, column, slant down moving right, slant down moving down, slant up moving right, slant up moving up) per iteration. This allows me to make changes in only 1 place; however, you end up with odd results if you do not plan accordingly.

After a bit of planning and a couple of rewrites, I believe I have an acceptable method of checking for matches, except that it doesn't work at all how it should. My code does not detect matches most of the time, and, when it does, it seems to choose every other piece in the matching row and a few other random pieces around the board. I cannot seem to find the source of my issue, but that leads me to the subject of this post: working with a partner.

While I appreciate everything my friend has been doing to help me, there is one major problem: he lives in Romania, and I live in U.S. While the wonders of modern technology allow us to easily communicate, the 8 hour time difference causes a problem. There is also a small bit of a language barrier, but it is not too much of an issue; I am good with puzzles and he understands English is not his first language. :-P He is also very busy with school, so there is barely any time for us to have conversations about what we are working on.

I have been attempting to get my cousin into Java programming, but he doesn't stick to most things very well. He and I are quite similar, and I think he would enjoy designing software once he gets into it.

Having another person provides many benefits over working by yourself:

You can bounce ideas off each other and brainstorm about projects.

You can work on the same project but work on it separately. The two versions could be compared to learn other approaches to the same tasks.

You can check each other's work. One may be strong with detail, while the other is strong at the overall structure issues.

You can play off of each other's strengths. One may be proficient at designing the general algorithm ideas, while the other may be proficient with the technical implementation of the algorithms.

The list goes on and on with the benefits of having someone else to work with. While the person you are collaborating with is important, you can usually benefit in some way even if they are not ideal.

To clear up my comments about my code, I am attaching 2 small portions of it. The first bit of code is the loop that calls the methods to check each row/column/diagonal.

//check for at least 5 pieces in a row public void checkMatch() { int cells = GUI.numCells; //only for readablity in below code matchMade = false; //reset match made for(int i = 0; i < cells; i++) { processRow(0, 1, i, 0); //check a row processRow(i, 0, 0, 1); //check a column processRow(0, 1, i, 1); //check a diagonal slant down, moving right if(i > 0) processRow(i, 1, 0, 1); //check a diagonal slant down, moving down processRow(0, 1, cells - i, -1); //check a diagonal slant up, moving right if(i > 0) processRow(0, 1, cells - i, -1); //check a diagonal slant up, moving up //the ones with if statements prevent checking diagonals twice } }

The other bit of code is the actual method that processes each row/column/diagonal.

//check an entire row/column/diagonal for matches private void processRow(int x, int xMod, int y, int yMod) { //FIXME checking rows does not work. odd results if a match is made int matchCount = 0; //number of matching cells in a row Color matchColor = null; //color to be matched for(int i = 0; i < GUI.numCells; i++) { int xi = x + xMod*i; int yi = y + yMod*i; if(xi >= 0 && xi < GUI.numCells && yi >= 0 && yi < GUI.numCells) { //ensure the indices are within the grid bounds if(piece(xi, yi) == null) { //reset if there is an empty cell matchCount = 0; matchColor = null; matchedPieces.clear(); } else { if(matchColor == null) { //the previous cell was empty, so initialize the color and list matchCount++; matchColor = piece(xi, yi).color; matchedPieces.add(piece(xi, yi)); } else if(piece(xi, yi).color.equals(matchColor)) { //the current piece matches the previous piece matchCount++; matchedPieces.add(piece(xi, yi)); } else { //the prevous cell was not empty, but the current piece does not match if(matchCount >= 5) { updateResults(matchCount, matchedPieces); matchMade = true; removePieces = true; } //reset matched piece count and the color matchCount = 1; matchColor = piece(xi, yi).color; //reset and initialize the matched pieces list matchedPieces.clear(); matchedPieces.add(piece(xi, yi)); } } } } }

[ragingozzy]

To Rewrite Or Not To Rewrite? That Is The Question...

And quite the question it is. I'll give a rundown of the situation and put the gritty details after the break.

I have an important decision to make regarding the code for my Lines game (see the previous post for the rundown up to this point): do I rewrite my code from scratch, or do I modify what I have to make it work?

There are a few game-halting problems in the game, and the code has become a bit ragged from having to make modifications in order to add elements of the game that did not fit with the game's design as it was. I want to simply start over with the entire program, but I know this is not possible with larger programs. I want to prevent poorly written code, but I do not want to start a habit of redoing unnecessary work.

First things first, I am a bit of reckless programmer. I tend to have a basic idea of what I want to accomplish and just start coding. I know this is a bit of a bad practice, but I feel like I generally have a good enough idea of what I want to do that I can make it work. Since I usually quickly figure out the basic elements of what I need, I jump straight to the working structure of my programs.

Now that you understand that, the path that led to my conundrum will be a bit clearer. Knowing the finished product of the game from examples given, I knew I needed a couple of classes to make the game: the game piece and a square on the grid (note: just a square, not the full grid, I will build that inside the game). Besides the classes for the JFrame, mouse listener, and other utility things, I was confident my 2 classes for the game elements were all I needed to make the game. I was right, to an extent.

Without much of a problem, I put the game together and had hexagons spinning around everywhere (as part of the instructions, a game piece is to spin when it is selected). I played around a bit and had the game working to the point where I needed a way to find the shortest path to a cell and not pass into blocked areas. Since I did not have a good idea of how to do this and I had never done it before, I took my usual approach and set off to Google. I found an excellently explained process to pathfinding on simple grids (http://www.cokeandcode.com/index.html?page=tutorials/tilemap2). This seemed like a well thought out approach to pathfinding, so, even though I was hesitant (because it is a pre-built library), I decided to go ahead and use it.

While partially rewriting the code to understand it, I realized that one of the objects passed to the constructor was a map object. Notice the problem? I have nothing similar to a map object. Within the setup of my game, the "map" is created by adding GridSquare objects to a 2D array. Obviously, there is a rather fine line here, but, without having the 2D array as a separate object, I cannot implement the map interface to use the pathfinding libraries as designed.

While reading through the explanation of the pathfinding algorithm, another problem was revealed, but I had messily dealt with this one before. Initially, I had written the GridSquare objects to not serve much purpose beyond being displayed and knowing if it is occupied; the GamePiece objects held a reference to the cells they occupied. This worked in the beginning, but I later realized I also needed the GridSquare objects to have a reference to the GamePiece objects that were occupying them. It seemed to be a bit of an odd, cyclic relationship between the two pieces, and I nearly created an infinite loop between the method that added the GamePiece reference to the GridSquare and the method that added the GridSquare reference to the GamePiece calling each other. Based on the structure of my game, I made a decision about which should be called first, and I removed that method call from the other one.

This little situation made me take a step back and ponder the relationship between a map and elements on a map. Should the map spaces hold references to the elements occupying it, or should the elements on a map hold references to the map spaces they are occupying? Obviously, both is an option as well, and it will depend on the situation. My question is if there is a general approach that is more standard, especially for simple things such as the Lines game.

By this point, you should be able to see some of the changes that are adding to the confusion that has developed in the code. Aside from encountering issues with adding the score panel to the GUI, I have 3 main problems with my game:

On rare occasions, one of the game pieces on the map will behave as if it is not there.

There is an endless loop that can occur if an attempt is made to move a game piece into a blocked off area.The loop occurs while the game is attempting to step through the path it "found" to get to the start location. The problem is that the game should not get to this point because there is no valid path from the start position to the target.

Frequently, when attempting to move a game piece into a blocked off area, the game will crash with a Null Pointer Exception. From my searching, the cause of this error seems to be accessing an inner class before it is initialized.

I believe the second 2 problems are related to the first, but I have no real basis for that assumption. One of my biggest issues is the randomness of these problems. Game pieces acting as if they are not there is quite uncommon, but the other 2 are nearly definite, especially if the blocked area is below and/or to the right of the start. This fact leads me to believe the target cell may be acting as a final position for a 2D array within the pathfinding methods, but this is another unfounded assumption.

These problems layered on top of partially redesigned code and combined with not wanting to implement pre-designed content makes me want to restart the entire project. This game is not large at all, and there is no time limit on completing it, it is simply for my own learning. In a real-world situation, I would not have the luxury of scrapping everything I have built so far, but I am not to real-world level.

I am currently planning to rewrite the game, unless my friend finds the cause of my problems, but I wanted to write this to give some insight into what is probably a common situation. Until next time.

-Ozzy

[ragingozzy]

Java Game - Lines

Here is my first program actually put on the internet! However, it is not a completed version, but I wanted to put this post up to get myself in the habit of posting updates to my games.

This game was not something I had planned to work on, but my friend presented it to me to ask if I wanted to work alongside him on one of his school projects. I happily agreed, as it is an excellent opportunity to work on a different Java project as well as work with someone.

The (incomplete) "game" link is here and the full story is after the break.

http://dl.dropbox.com/u/3711585/Jar%20Files/Lines_pre1.jar

I took the information he sent to me and got to work. The assignment referenced the following game: http://www.freegames.ws/games/free_online_games/lines_game/lines.htm and provided a bit of clarification and bonus objectives. I don't particularly care for the game itself but thought it would be a good design challenge, so I eagerly began coding.

I knew the basics of what I needed to create, so after building the necessary elements of the base classes (main, JFrame, JPanel, game pieces, and individual grid squares), I pieced the structure together to get a visible result. Once I had a visible grid (and a bit of headache from odd mistakes), I made the pieces able to be created as needed. Next up was rotating the pieces when one is selected; using what I used in my other game (the many write-ups for that will be done at a different time), piece selection was done. Following that, I need to be able to move the pieces. Easy.

Now we get to the interesting stuff. Up to this point, everything was pretty much straightforward (aside from goofy mistakes from my reckless programming practices). Beyond having to determine exactly how to do things, I knew what needed to be done at each step. Now we get to the first bit of real logic: finding 5 in a row.

Somewhere within the previous part and into the next part, I decided to reorganize a bit of my code. The majority of the game had been contained within the JPanel object, but it was quickly getting unwieldy with the layers of loops and conditionals and amount of decisions that had to be made. Everything was organized, but it was too much together and contained within the wrong part of the program. It required minimal effort to do all of the moving and let to an easier time finding what I needed. I moved the game loop and logic into a new "GameSkeleton" class that is created from the beginning.

The loop itself is created within the JPanel as it serves as a springboard into the heart of the program. I took the easy route and simply created 2 thread classes: LogicThread and RenderThread. The RenderThread simply calls repaint, but allows the painting to be done separate from the logic. This is not only beneficial for more involved games, but necessary here to show the moving game pieces. The LogicThread calls 2 methods: HandleInput and Update. HandleInput should be quite obvious, and the actual game logic is within the Update method. I may create a separate post on my experiences with game structures and loops in the future, but for now, if you keep your classes and methods separated and focused on a particular task, your life will be much easier.

I had messed with a small bit of this type of thing when I made a little tic-tac-toe game but nothing on this scale with this type of variation. You have to account for horizontal, vertical, and diagonal in any 5 contiguous spaces on the 9x9 board. Whew! I did not have a good idea on how to handle this, so I broke out my most valuable tool: Google. I passed up a couple of approaches that weren't my style and found one I liked. I tweaked it a bit to work for my game and implemented it. It did exactly what I needed; I also have a few ideas of how to adjust it to be able to handle up to 9 in a row, but that will come later. Next up: the shortest route.

This is where things really got interesting. As with most things in programming, the concept for the pathing is relatively simple, but the implementation is quite a bit more involved. I knew what needed to be done, but I did not really have a good idea of how to do it. As usual, I set off to Google to see what other people had done. I came across a full write-up about pathing. Eureka! What I later realized is this is a part of the Slick 2D Java game library. Since I had already retyped over half of the code and made a few modifications to update it for the change to ArrayLists, I decided to continue for now and debate (whether or not to use pre-written libraries in my games) later in an effort to reach my friend's project deadline. To make my code mesh with the path finding code, I had to restructure a bit of my code and add another class. If I had known the setup of the added code in the beginning, portions of my code would be 10x cleaner than they are now.

The basis of the game works as it should except for an odd problem with attempting to move a piece to a blocked area that is below and/or to the right of the current piece. The game typically throws a Null Pointer Exception but occasionally simply freezes. The problem is related to accessing an inner class before it is created, but I have no idea how this is happening since it only occurs in these situations. Normally, the piece can move freely in any direction on the board.

At this point, I am still working to find the cause of the problem, and hopefully, I can find it soon... Once I get this straightened out, I will add the other features to the game: score, game modes, 6+ in a row, etc.

I would like to change this blog to have code examples and helpful instructions in it, but, until I get caught up on what I have done so far, that will have to wait a bit. Either way, I hope this leads me to more (and shorter) posts as I work through things. Until next time.

-Ozzy