I have multiplatform 2d game made in kotlin, which has its own game-loop, fires evens which then can be used to construct GUI/modify it. The project is very modular and quite flexible.
The game loop has multiple implementations using coroutines, java threads, javascript requestAnimationFrame, setInterval, etc.
I have multiple implementations of GUI, including text interface and HTML/javascript.
Now I decide to give it a try and make GUI using libGDX. I am playing around with it a bit trying to integrate it with each other (first using "desktop" platform).
My game loop goes through all necessary components like "unit spawner", "unit container", "projectile container", etc. passing "delta" to all of these. These components are firing different events like "unit moved", "projectile fired", etc.
If I understand correctly, so far I see 2 options on how to integrate:
Keep my gameloop, collect relevant events related to UI update and then update all of them in render function of my ApplicationAdapter (because I cannot render outside of render methods, right?).
Use Actor class and for every component (or group of components) and use it's render and basically let libGDX handle gameloop for me.
How would you proceed? Are there any other options to go?
I want to keep my design flexible and modular, not to be tightly bound to libGDX, and rather make it another GUI implementation if possible.
Related
I have been writing a game in timeline code. I want the different frames (rooms) in the game to be able to share information between each other. Of course, timeline code is limited to the frame it is written in.
After doing quite a bit of reading ("Foundation Game Design with Flash" and a number of articles, tutorials, forums etc) I decided to employ a document class. This did not work either. It seems it only works for frame one but not the rest of the frames (I have four).
How can I have frame four respond to something that happpened in frame one? For example, if the player achieves something in frame one, I want a movie clip in frame four to be visible.
If You are writing your code on the timeline, My suggestion would be to create two layers in the timeline, one for 'frame-actions' - in this layer you insert the code specific to a single frame (will work when the movieclip is stopped on that particular frame).. And also create one more layer called global-actions (for the entire timeline). Only the first frame will be a key frame and there should be empty frames till the end of the timeline.
In this layer actions write the code that you want to access from any keyframe in the same timeline.
If you define a variable in the actions which are written for the whole timeline (global-actions) then that will be available on all the frames.
Now if you want to go to a different frame based on some action, just write some functions in the layer which contains global actions and call that particular function through the frame actions. To go to a different frame use the 'gotoAndStop(frameNumber)' function of flash.
I want to tell you that while it will work, I would not recommend using it in this way.
HTH.
You can use static variables - these are variables which are linked to a class, rather than an instance of it.
Suppose your document class was called Document.as, and you wanted a variable, playerLives, to be visible from any part of the program.
Declare it inside Document.as:
public static var playerLives:int = 3;
You can then reference this directly from anywhere else in your code with:
Document.playerLives
(note that the variable is a member of the class itself, not an instance of it).
You could use a dedicated Statics class to hold these variables if you want to keep your document neat, or attach them to the relevant classes (eg Player.lives)
I've not used timeline/frames for some years but I believe this is how I used to do it!
NB Statics will be fine for your purposes but they are, in some ways, an equivalent to the _global variable in AS2 (at least, they can be used in the same manner) - many would not approve of their use, or over-use, as they are freely accessible from anywhere in your program (thus anathema to the OO concept of encapsulation), but personally I try not to worry about it in small cases - the most important thing to know about the rules of any design pattern is when they can be broken!
They are also slightly slower to access than instance members, but you won't notice this unless you are constantly accessing/changing them (making things like player velocity, which will need to be referenced/changed every frame, static, is not a good idea).
Hope this helps.
You may find the simplest way to link everything with the document class is to move your four frames into a movieclip together and have that on the first frame, then interact with that movieclip.
E.g. in the document class, where the movieclip instance on the timeline is called 'game'.
game.gotoAndStop(4);
game.objectToDisplay.visible = true;
If you encounter reference errors in the IDE then you can avoid these by using [] notation to refer to the properties of game, e.g. game["objectToDisplay"].visible = true;
Note that it's not really best practice to do this, but it will at least help you to finish that first game which is really more important at this stage in your learning. Afterwards, if you want to learn more then I'd recommend "The Essential Guide to Flash Games" by Jeff Fulton from 8bitrocket.com - it will teach you how to use the document class effectively.
I am currently working on a rather large, UI-heavy Flash game. Our team has been working on this for about 9 months now. None of us had any previous experience with Flash, so we have continually improved our workflows during this time. However, we still feel that what we are doing now is not optimal, especially the interface between coders and artists, so I am wondering how other teams are working.
The ideal workflow should satisfy the following requirements:
1. Reused UI elements are defined only once
This means, if we want to change a font or a button style, we do not want to go trough all of our menus and change them manually. We want them defined in one central place and only referenced from there. Bonus points if the assets are shared not only at edit time but also at runtime, i.e. they are downloaded only once.
2. Everything is loaded on demand
Currently, we have two different loading steps: First, we load the menu libraries. When this is done, the players can already interact with all the menus. Then, we start loading the actual gameplay data. The initial loading time is still too long, though, and causes us to lose many potential players. What we really want to do is to load only the bare minimum required for the main menu and then load everything else only when the player tries to actually open the respective menus. Zuma Blitz does this really well.
3. Artists can perform minor changes without help from coders
If a menu should be re-designed without changing the actual functionality, it should be possible for artists to do that on their own in Flash CS6. This requires a clear interface between art and code, and it should also be possible for artists to test and debug their changes before sending them to the coders.
-
Our current workflow looks like this: The artist build the screens as MovieClips in Flash CS6 and export them as SWFs. On the code side, load the MovieClips from the screen SWFs and use them as the View classes in our PureMVC-based system. The Mediators access the elements like text fields in the Views by their instance names.
This is error-prone because there is no central place to define the interface (i.e. the instance names). A lot of communication overhead between coder and artist is required. Also, it creates a dependency between the code and the internal structure of the movieclip. The artists cannot attach the text field to a different sub-movieclip when they want to apply some effects to it.
We are experimenting with an event-based interface that requires the artist to add a few lines of code to the movieclip. This is less error-prone and interdependent than before, but it still does not completely satisfy (3) unless we write additional tools for testing and debugging. This must be a common problem and I can hardly imagine that there is no easier way.
For (2), we also started building a home-brewed solution but again, this is such a common task, there has to be something out there already that we can use.
So, how do experienced Flash developers manage such large projects?
I have some thoughts, but they are based on my coding style, which is unique to me.
1. Reused UI elements are defined only once
Depending on what you're reusing, this can be as simple as defining a library symbol and just using it. Fonts can be replaced without digging with a search and replace, and you can also simply swap out the font in the Font Embedding menu.
For sharing across xfl's, you can use a Flash Pro Project. Keep in mind that there's a certain amount of time overhead involved in this (files will want to update when you open them or save them, Flash crashes more with Projects, and it can be a bad idea to try to work on two files from the same project at once).
Some people use swcs, but doing so requires that you instantiate things in it in code, which might not work for your workflow. I use them for audio only, and I find that the objects in it have to be compiled on or before the frame you designate as the AS compile frame, or the sound can't be properly instantiated. I suspect this is going to be the case for anything instantiated from a swc.
2. Everything is loaded on demand
One of the best-kept secrets of Flash is that this is trivially easy to accomplish using the timeline and educated use of the complier. Here's how it works:
If your ActionScript compile frame is a frame greater than 1, then here is how things will compile:
Before Frame 1:
Any visual assets and embedded sounds used on frame 1
Your main Document Class, plus any Classes directly referenced from the Document Class (which is a good reason to code to Interfaces)
Before your AS compile frame (N):
Your AS Classes (the code, not necessarily the visual/audio assets)
The visual and audio assets for any library symbols set to Export for AS in frame N (even if they are not used in the swf)
Before the frame where the asset is first used on the timeline:
The visual/audio assets in all library symbols where Export for AS in frame N is not checked.
If you put a spinner loading graphic on frame 1 and you have selected frame 10 as your export frame, then if you just let the movie play until it hits frame 10, here is how it will load:
If you have any heavy assets in your spinner or directly referenced in your main Document Class, users will see a blank screen while this stuff downloads
The spinner will become visible and spin
Once your AS Classes have loaded, along with the Library Symbols set to Export in Frame 10 and the assets that are actually on Frame 10, you'll see those assets, and everything you need to use them will be ready.
The rest of the swf will continue to load in the background, updating framesLoaded.
I actually use a combination of a setter for the object that's on frame 10, plus an ENTER_FRAME handler to check to see if we're on frame 10 yet. There are certain things that I have to do that are easier based on one and others that work better to do the other way.
3. Artists can perform minor changes without help from coders
If the code is all in the Base Class for the library symbol, artists don't need to understand it, as long as they don't remove or change a needed instance name. I try to minimize dependence on instance names by watching ADDED_TO_STAGE (capture phase) and watching for Display Objects by type. Once I have a reference to an object of the appropriate type, it's easy enough to watch for REMOVED_FROM_STAGE on that object to dereference it. This is similar to how frameworks such as RobotLegs and Swiz work.
Further, I use a concept I call "Semantic Flash," where I do a lot based on labels. I have a base Class, FrameLabelCip, which has built-in nextLabel() and previousLabel() functionality, as well as dispatching FRAME_LABEL_CONSTRUCTED events. It's really easy to go from storyboard event name to Flash label name and just build out the graphics bang-bang-bang.
I make heavy use of Graphic Symbols for synchronizing graphics across multiple labels (for example, bulleted lists), instead of relying on code. This animator's trick makes these things both robust and approachable to less-technical teammates.
How would someone go about coding a 'window'? I'm starting to make a GUI, and I want to learn how to code one. One that can be skinnable, and one that actually loops and creates itself at runtime. I understand that this might be a bit vague, so I'll add details.
One that actually 'creates' itself. Most GUI tutorials I've looked on depends on an 'image' that just gets added on the screen. I want to be able to use skins in my windows. One where my 'skin' is just a collection of 'borders'. Then when I insert window.create(50,50) where 50,50 is my height, width, It would just create that window, following the skin.
I understand that it probably follows just like when a language draws a rectangle, it just follows a different set of rules (maybe?). However, for all my Google-fu skills I cannot find a tutorial that teaches me this.
Please Help. I didn't include the language I used as you can see, because I believe I just need to know how to create one. Anyway though, I am using Actionscript 3. A tutorial would be just fine, or even A SINGLE CLASS THAT HAS THIS FUNCTIONALITY, I'll just study the code. Or if you know one, maybe a whole book about GUI and programming it :D
Pure As3.0 GUI coding is quite troublesome. I try to Googling, but not come out well. anyway for my case, i generate using a SWC, and Class Mapping and Customizing. but i'm not sure best way. in other way i use a bit101 library. this is gives me want Window, Charts, Componets easily of high abstraction. see the below image.
It can be pretty hard and complicated to do, or very easy, it just depends on how flexible your solution should be. You need firstly to design a structure of your program and approach to the problem.
I like to go from the image of how it should look like from API point of view. I think I would create a GUI element like this:
var wholeGui:MyGUI = new MyGUI();
var window:IGuiElement = new GuiWindow(dataObject, skinObject);
wholeGui.addElement(window);
So what would you need?
1) Object that would manage all GUI elements. Why? Simply because your GUI elements shouldn't be destroyed by themselves if user will click "X" on your little window. The wholeGui object would manage them and listen for any events including those that would destroy them. You may consider creating custom events for interaction between the wholeGui object and your window object if this interaction is going to be complicated.
2) Interface for your GUI objects. Some problem here is that AS3 actually doesn't have interface for Sprite, and you would like to interact with it like with extended Sprite. The workaround here is to have in this interface a declaration like this:
function asSprite():Sprite;
And your implementation in GuiWindow would look like this:
public function asSprite():Sprite {
return this;
}
And your GuiWindow class should extend Sprite of course. Then you would have access to it's Sprite properties and methods by writing for example: window.asSprite.startDrag();
This interface should give you abilities that you need to operate on your GUI element.
3) Class for your GUI element, in this example GuiWindow.
4) Class for your data that would be injected into your element. If you would load data dynamically, and from some location, you would need to deal with the situation when no data can be provided - but that logic would be inside your window.
5) Class for your skin - so you would be able to dynamically create a skin object and use it to create your window in a way you want.
That's just few thoughts to consider.
PS. It may be good idea to fill GuiWindow object with data AFTER creating it, and not in constructor, as you would be able to visualize loading process then.
I just started to study the Model View Controller pattern. I now understand the basic usage of MVC, but when i tried to implement MVC in a simple test, i ran into a problem. Ofcoarse I could easily adjust the code so it works, but I wish to learn how to correctly implement the MVC pattern.
The test:
I used actionscript 3 to make a simple program. It consist of a turret, and a mouseclick. The turret is in the middle of the screen. When I click anywhere the turret rotates towards the point where I clicked. Both the mouse and the turret have their own model,view and controller. When I click, the MouseModel changes correctly. But for the actual TurretView to respond, the TurretModel must change its rotation variable and send out an event.
The question is who responds to the MouseModel event?
/------->MouseControl------\
/ \
MouseView ?<---MouseModel
TurretView <------------------TurretModel
TurretControl
I figured its best not to have MouseModel directly influence TurretModel or TurretControl, because this would require them to be an eventListener. Making TurretView listen to the MouseModel, and then tell TurretControl to adjust TurretModel, after wich TurretView can update trough a TurretModel event looks like a lot of extra code for a simple task. Also I'd rather not have MouseControl affect TurretModel, this would break the flexibility of the mouse as input for future classes.
Ow, also in which class do I put the code for the angle calculation?
Thanks in advance
Remember that the goal with MVC is primarily the separation of Model and View, and the Controller can serve as the communicator between the two.
Unless you are planning on storing each action that occurs (clicking, rotating, etc.), there is no real need for an action (in this situation) to send data to the Model. Everything you'd like to do should be easily handled with the Controller. So the flow would be:
Mouse click
Event is fired to trigger a command (in the Controller), passing along the mouse location
The command calculates the turret's rotation
The command tells the View to rotate the turret
This is, of course, my suggestion based off of your example. In truth, depending on the project, the above flow could easily change (for instance, in this situation it seems good to do rotation calculation in the command, but in other situations that may not make as much sense). Look at MVC as a goal - you're trying to separate these elements as much as possible, but there is no 100% "works-every-time" way to do it.
Robotlegs, a popular MVC framework, has a great diagram on their site showing how they tackled MVC:
http://www.robotlegs.org/diagram/
I'm not advertising that you NEED to use Robotlegs (it's good, but there's plenty of other alternatives), but they definitely made a pretty diagram :)
You should have one model, which then has pieces in it that you are currently calling MouseModel and TurretModel. You can either keep those names and breakdowns, or do something else once you have a better "handle" on what needs to be done.
The View that is tracking the mouse clicks should dispatch an event that your Controller component catches to update the TurretModel (at this point, there's probably no need for a MouseModel). Your TurretView can then update itself based on the TurretModel, or the Controller can update the TurretView based on the new value. This will depend on how you have it wired.
Usin a Framework such as Robotlegs can help you figure out all the ins and outs of this process, and I've heard that this book http://shop.oreilly.com/product/0636920021216.do provides a great explanation of MVC, even if you don't choose to use Robotlegs after you read it.
hi i am developing a game using libgdx. I want to make the texture object available to entire application. I have a requirement like, initialize the texture in one application listener and i want to use it in another application listener. Can anyone help me on this.
There are two ways I think you can do this. First, you could read the data into a static variable. For an example of this, take a look at the Art class in metagun demo: Art.java. The second way, which I have not tried yet, is to use the new AssetManager class. There is example use in the AssetManager test. These should help you access your textures more easily.
You don't need to have 2 or more Application listeners. Actually that only makes things harder.
Use Screens instead (extending Game in your core class instead of directly implementing ApplicationListener).
Either way, you should be able to just send the textures as arguments. For example I have a class Assets that contains all the textures and I sent it to each screen. You can make them static as Doran suggested too.