I'm newbie on libgdx and game developing logic. So i need your advice.
Here is my problem. I'm trying to make a game and i need to know how should i collect game values. Like hp, coins, score, attack speed ect. There's two side on my game. Player and enemy. I made two classes, LeftSide(this is player) and RightSide(this is enemy). Then i notice i didn't take user name and i can not think about this. What should i do? Should one class be optimized? or Should more classes, like i said before for player and enemy and maybe user's names.
Edit:
I ask this question because i don't know whis is most good for performance.
Option 2 is cleaner, if only because it can be factored down to two instances of a player class. Option 1 will be harder to maintain and will likely have duplicated logic.
Related
I am currently working on a project where I want to build a model which can detect and track people with a unique ID. The main issue is when a person leaves the frame and comes back after some time. Currently, I am working with yolov4 and Deepsort to detect and track. But it is failing in this situation.
Please suggest some approach where we can do detection, reidentification and tracking of people or cars or any other object.
Thank you :)
Although YOLOv4 can detect people in an image/video stream, I think it might be too general in your case. When a person leaves the frame and comes back, ideally the model should remember seeing that person before.
One way to tackle this is to train on images of the people you want to detect.
E.g. in a system like yours, you could take multiple images of the people you want to track from different angles and label them using their unique identifiers. Afterwards you could train the model using this data (for your downstream task). This will ideally give more specific results for detecting and tracking people with their unique identifiers as opposed to the general people detection when using YOLOv4 as is..
That said, I understand that taking lots of images of people may not be practical in certain scenarios. In that case you may want to look at techniques that produce accurate results with minimal data such as domain adaptation (https://arxiv.org/abs/1812.11806). However in an application for tracking and detecting people, I'm assuming you want minimal misclassifications.. Hence you could say it's always a tradeoff.
You can find out more about dealing with lack of data in this article: (https://www.kdnuggets.com/2019/06/5-ways-lack-data-machine-learning.html)
However I think this is a better place to start for a re-identification model: (https://github.com/KaiyangZhou/deep-person-reid)
It has ample documentation to get you started..
I would like to run through a modelling exercise to try and understand DDD a little better, specifically in the cases where there is a many-to-many relationship
Lets take an example of Xbox users and their achievements.
If you are not familiar this is the background:
Each game on Xbox has achievements.
User will have a list of games they own/have played and they can unlock achievements for these games.
There is a many-to-many relationship here as a user can have many games, and a game can have many users.
Without going further, there is definitely two aggregate roots here. User and game.
The game aggregate root has a list of achievements.
My confusion comes in with tracking the progress of a user for a specific game.
for instance what games they have, and what achievements they have for each game.
In a typical CRUD design it might look something like this:
How would you now model this is DDD?
User Game and User Achievement will have information regarding the progress of each.
This is a solution i currently think, but is it right?
User and game are both aggregate roots.
The progress of a game and it's individual achievements also seems to be connected and I would say that this is its own aggregate root. This is because like game and it's achievements, it potentially has a transaction boundary. When you progress on a game's achievement, this could effect the game's progress (e.g. unlocking an achievement would up the total game's gamerscore achieved.)
I keep hearing that you want to resolve many-to-many relationship, which is usually fine, but here, the relationship has its own data, and I don't think this relationship belongs to either.
You might be able to argue that you would put this on the user aggregate, but my concern is that it adds weight to that user aggregate and there is no reason for it to be there.
I don't think there is any transaction boundaries and I don't like the though of having to load all the user's games when you want to load it. Even if this was lazy loaded, I am concerned it might cause concurrency issues?
This is why I think the many to many relationship here is valid, and why a new aggregate root might be appropriate.
Also is the name user game progress even correct. Knowing the domain, what might you suggest?
Thank you, any help is massively appriciated.
What you are looking for here is Domain Events. From the Microsoft documentation:
Use domain events to explicitly implement side effects of changes
within your domain. In other words, and using DDD terminology, use
domain events to explicitly implement side effects across multiple
aggregates. Optionally, for better scalability and less impact in
database locks, use eventual consistency between aggregates within the
same domain.
The "progress of game" does not look to be an aggregate root to me. To update the "progress of game" you can raise a domain event such as "User_Moved" from your User aggregate and similar event from your Game aggregate. You can then subscribe to these events to update the game progress. Also, since Domain Events are in-memory you can achieve this within a single transaction.
I don't think you are going to find an authoritative answer to your question that is more specific than "it depends".
For instance - suppose the game was chess, and we want to award an achievement when a player has one at least once with each color. That's not going to be the responsibility of a "game" aggregate; we can see that immediately from the fact that the life cycles don't line up.
One quick way to sketch this suggests that we might have games raising "domain events" to announce wins, and then a little state machine that uses wins as inputs an announces awards, and then some report that lists all awards for a specific player id.
The state machine, and the accompanying domain logic that takes in wins and emits awards is probably an aggregate all by itself - one instance for each player.
The report - which combines this award with others for the same player... well, aside from some plumbing details that seems pretty anemic, unless you need to do something clever to show only "recent" awards, or something similar.
A good talk that explores these ideas: All Our Aggregates Are Wrong, by Mauro Servienti.
If you were to come at this initially, this "player awards" aggregate could either be its own aggregate or could be a list of awards under the player.
It certainly could be a list of awards within the player aggregate. But - assuming the analysis above is correct - the list of awards doesn't influence, and isn't influenced by, any other changes to player.
There's one list (which might be empty) for every player, and you'll want to be able to retrieve a specific player's list using the player id, but these conditions alone do not constrain us to consider the list a part of the player aggregate.
I want to learn to make infinite running games like temple run.... but at a very basic level. I am good at as3 and flash... and i have created all the graphics.... the whole scenario of the game is in first person view. And the graphics is all created in Flash.
Can anyone please suggest some tutorials or any techniques that i should use to make the objects look like they are coming from a far point and how i can write the logic of hitting them or escaping them.
Thanks for ur help... :)
I am not sure this kind of question has been asked before, and been answered, by as far as my search is concerned, I haven't got any answer yet.
First let me tell you my scenario.
I want to develop a chess game in Flash AS3. I have developed the interface. I have coded the movement of the pieces and movement rules of the pieces. (Please note: Only movement rules yet, not capture rules.)
Now the problem is, I need to implement the AI in chess for one player game. I am feeling helpless, because though I know each and every rules of the chess, but applying AI is not simple at all.
And my biggest confusion is: I have been searching, and all of my searches tell me about the chess engines. But I always got confused in two types of engines. One is for front end, and second is real engines. But none specifies (or I might not get it) which one is for which.
I need a API type of some thing, where when I can get searching of right pieces, and move according to the difficulty. Is there anything like that?
Please note: I want an open source and something to be used in Flash.
Thanks.
First of all http://nanochess.110mb.com/archive/toledo_javascript_chess_3.html here is the original project which implements a relatively simple AI (I think it's only 2 steps deep) in JavaScript. Since that was a contest project for minimal code, it is "obfuscated" somewhat by hand-made reduction of the source code. Here's someone was trying to restore the same code to a more or less readable source: https://github.com/bormand/nanochess .
I think that it might be a little bit too difficult to write it, given you have no background in AI... I mean, a good engine needs to calculate more then two steps ahead, but just to give you some numbers: the number of possible moves per step, given all pieces are on the board would be approximately 140 at max, the second step thus would be all the combination of these moves with all possible moves of the opponent and again this much combinations i.e. 140 * 140 * 140. Which means you would need a very good technique to discriminate the bad moves and only try to predict good moves.
As of today, there isn't a deterministic winning strategy for chess (in other words, it wasn't solved by computers, like some other table games), which means, it is a fairly complex game, but an AI which could play at a hobbyist level isn't all that difficult to come up with.
A recommended further reading: http://aima.cs.berkeley.edu/
A Chess Program these days comes in two parts:
The User Interface, which provides the chess board, moves view, clocks, etc.
The Chess Engine, which provides the ability to play the game of chess.
These two programs use a simple text protocol (UCI or XBoard) to communicate with the UI program running the chess engine as a child process and communicating over pipes.
This has several significant advantages:
You only need one UI program which can use any compliant chess engine.
Time to develop the chess engine is reduced as only a simple interface need be provided.
It also means that the developers get to do the stuff they are good at and don't necessarily have to be part of a team in order to get the other bit finished. Note that there are many more chess engines than chess UI's available today.
You are coming to the problem with several disadvantages:
As you are using Flash, you cannot use this two program approach (AFAIK Flash cannot use fork(). exec(), posix_spawn()). You will therefore need to provide all of the solution which you should at least attempt to make multi-threaded so the engine can work while the user is interacting with the UI.
You are using a language which is very slow compared to C++, which is what engines are generally developed in.
You have access to limited system resources, especially memory. You might be able to override this with some setting of the Flash runtime.
If you want your program to actually play chess then you need to solve the following problems:
Move Generator: Generates all legal moves in a position. Some engine implementations don't worry about the "legal" part and prune illegal moves some time later. However you still need to detect check, mate, stalemate conditions at some point.
Position Evaluation: Provide a score for a given position. If you cannot determine if one position is better for one side than another then you have no way of finding winning moves.
Move Tree and pruning: You need to store the move sequences you are evaluating and a way to prune (ignore) branches that don't interest you (normally because you have determined that they are weak). A chess move tree is vast given every possible reply to every possible move and pruning the tree is the way to manage this.
Transpotion table: There are many transpositions in chess (a position reached by moving the pieces in a different order). One method of avoiding the re-evaluation of the position you have already evaluated is to store the position score in a transposition table. In order to do that you need to come up with a hash key for the position, which is normally implemented using Zobrist hash.
The best sites to get more detailed information (I am not a chess engine author) would be:
TalkChess Forum
Chess Programming Wiki
Good luck and please keep us posted of your progress!
I'm trying to design a simple game ---Pong, Arkanoid--- using strictly "Proper OO", whatever that means.
So, by designing myself to death, I'm trying to get to a point where I'll know what to do or not do next time...
Who should handle, for example, colissions? And scorekeeping?
My first idea was giving a couple jobs to the ball, but that started expanding exponentially into a god object: The ball'd know where it is, who it crashed into, and report to the scorekeeping objects.
And that's too much for the poor ball.
rule of thumb:
if an object logically owns all of the state involved, then it owns the methods that use that state
if a method requires state from more than one object:
if a container object owns all of the objects used by the method, then it owns the method, too
otherwise you need a 'bridge' object to own the utility method
unless there is a strong argument for one object to be the 'controller' for the method (can't think of an example offhand though)
in your case, the 'gameboard' or 'game environment' would probably have a 'game physics' class (or group of methods) that owned the collision-detection (utility/bridge) methods
A good or bad design reveals itself by how well it accomodates unexpected requirements, so I would suggest keeping a stock of potential "game features" handy to inform your design reflexions. Since you're doing this as a learning project you can afford to go crazy.
Arkanoid is a very good choice for this, it offers so many options. Make different bricks score different amounts of points. Make some bricks change the score of other bricks when hit. Make some bricks require multiple hits. Give superpowers to the ball, paddle, or bricks. Vary these powers: one of them makes the ball keyboard-controllable, another makes it transparent, another reverses "gravity", and so on. Make bricks drop objects.
The goal is that when you make such a change, it impacts the minimum possible number of classes and methods. Get a feel for how your design must change to fit this criterion.
Use an IDE that has a Refactoring menu, in particular the move method refactoring. (If you haven't, read the book Refactoring.) Experiment with placing your various methods here and there. Notice what becomes hard to change when the method is placed "wrong", and what becomes easier when you place it elsewhere. Methods are placed right when objects take care of their own state; you can "tell" an object to do something, rather than "ask" it questions about its state and then make decisions based on its answers.
Let's assume that in your design each sprite is an object instance. (You could choose other strategies.) Generally, motion alters the state of a sprite, so the method that describes motion for a particular kind of sprite probably belongs on that sprite's class.
Collision detection is a sensitive part of the code, as it potentially involves checking all possible pairs of sprites. You'll want to distinguish checking for collisions and informing objects of collisions. Your ball object needs to alter its motion on colliding with the paddle, for instance. But the algorithm for detecting collisions in general won't belong on the ball class, since other pairs of objects may collide with consequences that matter to the game.
And so on...
Keep in mind that objects can also exist for logical elements of a given problem (not only real elements, like balls and boards).
So for collision detection, you could have a CollidingElement class that handles the position and shape states. This object can then be embedded by composition in any object that should collide in the game and delegate any needed method call to it.
It really depends on your implementation, but I imagine you'd have a "gameboard" object to manage score keeping, or maybe a goal object on each side. As far as collisions I think you might want to pass events between the objects. I think any object should know its location though.
in most games you have statics and actors . .. actors move around and each of them independently figures out when they collide with something since they are aware of their shape and extents