I want to use Ashley but I also want to use actions and listeners with Scene2d. I read that it is not a good idea, but why? Can I create a system with stage.act(); and stage.draw(); in the update method or is it a bad idea? Thanks.
I don't think you can say it's always a bad idea to mix Scene2D and an ECS like Ashley. It may make a lot of sense to use Scene2D.UI for your user interface, and then Ashley for everything else. As you point out, there isn't a technical reason why you couldn't tie these two together. It's a judgment call based on your particular use case.
That being said, one reason why you typically wouldn't use Scene2D and Ashley together is that they have a lot of overlap. One of the basic principles of computer science is "Don't Repeat Yourself"- don't build the same thing twice, and when you do build something, make sure you use as few parts as possible. This includes avoiding libraries you don't need.
If you use Scene2D's actions to move your actors/entities, and you use Stage#draw() to draw everything, what's left for Ashley to add? Likely not enough to justify the complexity it adds.
Related
I would like to know if using Scene2d is the best approach for creating a tetris like game using libgdx ?
If yes, what's the approach ? each block is an actor ?
How can I achieve this easily ?
Well that's a bit of a broad question for this kind of format isn't it? :-) I'll try and answer anyway - to get your tetris game going (without much knowledge of libgdx), just take apart & understand an existing example! Download https://github.com/jmillikan/gdx-tetris and have a play around with it, you'll figure out the best fitting approach to execute your specific idea soon enough. Happy coding :-).
For simple games, like Tetris, you don't need to use something as complicated as Scene2d. Instead, just use a 2 dimensional array that represents the board.
board[x][y]=0 //Empty
board[x2][y2]=1 //Filled (or give each block an id)
The draw your screen with a spritebatch.
I have got one sily question. I write a game in libgdx. But my friend always use actors and sprites. But i dont use this class. In all parts or elements of game i extends Sprite. Then i use a array list for using to save elements.
I write game like that: reading input, update, check collision and render. Its ok or not ?
There is no fixed way to go from A to B in programming. I have made a couple of good functioning games without the use of the stage and sprite class. These classes just help you get things done quicker. So yes you can write good games without the use of actors/sprites. It is even possible to write good games without the use of OpenGL or DirectX and create your own graphics library, but why should we? If you know what Scene2D and the sprite class can do for you it is kinda ignorant to leave them aside if they can help you.
It often takes little time to learn a certain library/extension. Once we know how to use it there will be profit for life.
I need a bit of counseling. I´m trying to reproduce one of M.C. Escher´s models in Actionscript, but I´m not entirely sure about where to begin. Ideally, I´d want to make something from his Circle Limit series look somewhat like this: http://vimeo.com/4154382
Could anyone provide any pointers as in what approach should I take? I am not an expert coder, so anything would help.
Thanks in advance,
Garfeel M.D.
The different copies of a hyperbolic transformation are related to one another via Möbius transformations which leave the circle fixed. You can represent them as transformations
(a+bi)z + (c+di)
z |-> ----------------
(c-di)z + (a-bi)
You might want to represent the switch from circle to half plane as a Möbius transformation as well, to avoid numeric issues with simple zooming.
I have tools available to make hyperbolic ornaments from Escher ornaments, and zoom into them in real time. But Escher isn't public domain yet, and in my experience the Escher foundation is less than enthusiastic in granting permission for derived works. So if you get ther OK, or decide on some other artist (possibly starting from a Euclidean ornament), feel free to contact me by e-mail to discuss this further.
I recently was a jury member foir an ornament competition where some submissions were hyperbolized from Euclidean drawings. Gaining permissions for those would likely be easier than from the Escher foundation.
I'm a beginner in programming world, never touch any programming language before. But last 3 days I decide to try make a flash game, I looked some tutorial about AS3, try it, yes I understand a little bit. But I'm still confused about this:
How do I know or to decide what codes I write first, what next? example: I want to add a hero, then a enemy, then a tiles, then a background, event listener.
Is it okay if I write code randomly, example: first I add enemy, then add tiles, add background, then add hero, etc?
What is the best way to completely learn all AS3 codes, especially about flash game dev?
I'm now in frustration mode, so I decide to learn from you all who have mastered AS3.
Check out this guide by Michael James Williams. I was in the same situation as you, and that guide helped me a lot. It goes through a lot of the basics and does a good job of explaining each step.
To answer some of your questions, the order in which you code stuff doesn't matter too much. You can always go back and adjust your old code, and you'll definitely end up doing that at some point.
For learning AS3 syntax, just look through some examples and tutorials, and don't be afraid to read the official AS3 docs. They might be intimidating at first, but once you start learning some of the terminology, they're very helpful.
you can try some video tutorials like these
http://www.lynda.com/ActionScript-tutorials/AS3-language-fundamentals/123492/129625-4.html
http://www.lynda.com/Flash-tutorials/Building-Flash-Games-Starling/98951-2.html?srchtrk=index:1%0Alinktypeid:2%0Aq:flash%2Bgames%0Apage:1%0As:relevance%0Asa:true%0Aproducttypeid:2
If you're frustrated NOW, are you sure that you're ready to invest a couple of YEARS in becoming half-good with Actionscript? You'll have to like learning from your mistakes (an excellent way to learn, actually), because you will make thousands of them and they will cost you thousands of hours!
Do NOT write 'randomly' unless you want to greatly lengthen your time to mastery. Everything you do should have a purpose. I would start (if I were starting again) by giving myself a series of the smallest challenges: make an object appear; make it disappear; make it appear in one second from now; make it appear when I tap a key or click my mouse; make it move across the screen; make it move back; make it follow my mouse... etc.
There are many hundreds of basic programmatic elements like these that will add to your growing grasp of logic, data-structures and language. There are usually many ways to accomplish the same task -- learn and practice all of them.
Luckily, the Internet is full of good tutorials and references to Actionscript, and some decent forums like this one where you can get help.
I know this is king of old but someone might still find this useful.
I think that if you are serious about game development and also want to learn some techniques that are independent of the platform (Flash/AS3 in this case) you should use a framework.
For Flash the best game framework is the Starling along with Feather for UI.
They run on Stage3D which means that run on the GPU not the CPU which make them very fast.
With Starling you can also create mobile games that run in AIR so I think it really is something to consider.
On hsharma.com you can find a free video tutorial that goes through everything you need to know to get starting with game development so it should answer the question on how to create enemies, backgrounds, etc.
Hope this helps someone.
I have a simple question regarding the Minimax algorithm: for example for the tic-tac-toe game, how do I determine the utility function's for each player plays? It doesn't do that automatically, does it? I must hard-code the values in the game, it can't learn them by itself, does it?
No, a MiniMax does not learn. It is a smarter version of a brute-force tree search.
Typically you would implement the utility function directly. In this case the algorithm would not learn how to play the game, it would use the information that you had explicitly hard-coded in the implementation.
However, it would be possible to use genetic programming (GP) or some equivalent technique to automatically derive a utility function. In this case you would not have to encode any explicit strategy. Instead the evolution would discover its own way of playing the game well.
You could either combine your minimax code and the GP code into a single (probably very slow) adaptive program, or you could run the GP first, find a good utility function and then add this function to your minimax code just as you would any hand-coded function.
Tic-Tac-Toe is small enough to run the game to the end and assign 1 for win, 0 for draw and -1 for lose.
Otherwise you have to provide a function which determines the value of a position heuristically. In chess for example a big factor is the value of the material, but also who controls the center or how easily the pieces can move.
As for learning, you can add weight factors to different aspects of the position and try to optimize those by repeatedly playing games.
How do determine the utility function for each play?
Carefully ;-) This article shows how a slightly flawed evaluation function (one for ex. which either doesn't go "deep" enough in looking ahead in the tree of possible plys, or one which fails to capture the relative strengh of some board positions) results in an overall weak algorithm (one that looses more often).
it can't learn them by itself, does it?
No, it doesn't. There are ways, however, to make the computer learn the relative strength of board positions. For example by looking into Donald Mitchie and his MENACE program you'll see how a stochastic process can be used to learn the board without any a priori knowledge but the rules of the game. The funny part is that while this can be implemented in computers, a few hundred colored beads and match boxes are all that is required, thanks to the relatively small size of the game space, and also thanks to various symmetries.
After learning such a cool way of teaching the computer how to play, we may not be so interested in going back to MinMax as applied to Tic-Tac-Toe. After all MinMax is a relatively simple way of pruning a decision tree, which is hardly needed with tic-tac-toe's small game space. But, if we must ;-) [go back to MinMax]...
We can look into the "matchbox" associated with the next play (i.e. not going deep at all), and use the percentage of beads associated with each square, as an additional factor. We can then evaluate a traditional tree, but only going, say 2 or 3 moves deep (a shallow look-ahead depth which would typically end in usually in losses or draws) and rate each next move on the basis of the simple -1 (loss), 0 (draw/unknown), +1 (win) rating. By then combining the beads percentage and the simple rating (by say addition, certainly not by multiplication), we are able to effectively use MinMax in a fashion that is more akin to the way it is used in cases when it is not possible to evaluate the game tree to its end.
Bottom line: In the case of Tic-Tac-Toe, MinMax only becomes more interesting (for example in helping us explore the effectiveness of a particular utility function) when we remove the deterministic nature of the game, associated with the easy evaluation the full tree. Another way of making the game [mathematically] interesting is to play with a opponent which makes mistakes...