In blender I created a human body using the mirror modifier, so that i had only to model half of the body and the other half would mirror automatically.
However, when I export that model and show in with libgdx, I see only that half. The mirror is missing. And I want to add animations like walking running. So probably, I have to replace the mirror modifier by actual mesh? How?
You should apply your modifieres during the export.
This is the cleanest way cause you don't have to apply all modifieres on every development step of your mesh.
Blender's modifiers are programmed to modify objects in certain ways, don't expect any of them to be available outside of blender. You should always apply any modifiers before trying to share data with other programs.
Every modifier in blender has an apply button that will permanently alter the object to match what the modifier generates.
If you are using several modifiers you may want to use "Convert to Mesh" (press AltC). While this sounds odd when you already have a mesh object, it will apply all modifiers on the object.
Related
I am trying to come up with an efficient way to organize clickable menus for the objects in my game. I made a Menu class, from which all possible menus inherit:
class_name Menu extends Control
#contains functions (for buttons) that all menus have in common
func open_menu():
pass
func close_menu():
pass
To make a menu specific to buildings, I inherit all functionalities from the Menu class:
class_name BuildingMenu extends Menu
# contains functions specific to all buildings
func upgrade_building():
pass
func delete_building():
pass
# ... many more ...
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
class_name HQMenu extends BuildingMenu
func delete_building():
# overwriting inherited function like this does not work...
# ... some HQ specific stuff here ...
I could just inherit from Menu and then copy paste everything from BuildingMenu except the delete_building() method, but this seems somewhat clumsy because now I have to edit two files if I want to change/add any building functions.
What is the correct way to do this?
SOLUTION:
Thanks to the suggestion by Thearot I've decided to move the delete_building() function into a new class from which all the regular (non HQ) buildings inherit:
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
This sounds like a violation of Liskov Substitution Principle. From a purely object oriented point of view, it would be preferible to make another class for a subset of buildings with what they have in common, than to have one building inherit from another if it has to disable some methods.
If your base class for all buildings implies that some buildings have to disable some methods, then it does not really have the methods common for all building, it has some extra ones.
To be clear, here I'm suggesting to add another extra intermediary class, and that way you don't have to delete nor duplicate methods.
If that is not an option for you… Congratulations! you have made a mess system complex enough that some kind of component based system begins to make sense. But don't jump the line, don't fret, it is OK.
If I understand correctly you have some contextual menus that show different options depending on what is selected or what you click on, right?
That means that the options are variable. Thus, use a variable. Add an Array field that has the names of the methods that should be linked to the menu. Then have the menu system discover the options by reading that Array, and connecting to functions with the names specified there.
And how you do add or remove options? You add them or remove them form the Array. Simple. You can populate the Array in _init.
To be clear, you can check if an object has a method with has_method. You call a method by name with call, or - of course - you could connect signals to them with connect (if prefer to populate an static menu for the object instead of having a dynamic one). Yes, I'm suggesting late binding.
I really want to know, is it possible to create a fixture for a body that could be broken by some other body?
There is the example:
a body with its fixture divided into small figures:
and what happens after it is hit by another body:
P.s. Are there any programs that could help the process of creating such fixture?
yes you can do this using Breakable spotted at :
net.dermetfan.gdx.physics.box2d.Breakable
The Breakable allows to easily make whole bodies or single fixtures breakable, which means they will be destroyed if a certain force or friction is applied to them.
How to use
A Breakable is meant to be put in a body's, fixture's or joint's user
data. A single Breakable instance can be put in the user data of
multiple bodies, fixtures and joints. Since this may collide with the
Box2DSprite or other classes using the user data, the
Breakable$Manager uses a Function to access the Breakable in the
user data of a body, fixture or joint.Do not forget to set a Manager
instance as ContactListener to the world and to call destroy() after
every timestep. If the field is already in use, check out the
ContactMultiplexer. The Manager does the actual work, the Breakables
are just passive data holders.
A Breakable consists of a normal resistance, tangent resistance, an
option to destroy its body in case its last fixture was destroyed and
an option setting if the body should be destroyed no matter the amount
of remaining fixtures.
The normalResistance is the force that can be applied to the
Breakable before it breaks (inclusive). The tangentResistance is the
friction the Breakable can bear (also inclusive). The
reactionForceRestiance specifies the reaction force a joint can bear
on each axis. The reactionForceLength2Resistance is the max squared
length of the joint's reaction force the Breakable can bear.
referred to libgdx-utils
some other good references with good examples here and here
for the question (Are there any programs that could help the process
of creating such fixture)
yes you can easily use box2d-editor which allows you to create complex polygons and you can also create your bodies and shapes from your images or sprites check the official documentation in the same page there are several video who explain the way box2d-editor works :
Features:
Automatically decomposes concave shapes into convex polygons,
Automatically traces your images if needed,
Supports multiple outlines for a single body,
Supports polygon and circle shapes,
Reference point location can be changed,
Visual configurable grid with snap-to-grid option,
Built-in collision tester! Throw balls at your body to test it,
Loader provided for LibGDX game framework (written in Java),
Simple export format (JSON), to let you easily create your own loader for any framework in any language.
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.