Ok I have an object and a big square as well as other stuff in a room. I need the object which is obj_dot to randomly spawn but only within the big square (which is obj_paper) every time the room restarts.
Your question lacks detailed information on the setup of your sprites/objects, therefore this answer might not suit you 100% but hopefully it will provide you with a general idea of how to go about resolving this issue.
You probably want to put something like this within the create event for an object that is created on the room creation. I'm going to assume obj_paper is created on room creation (hence is recreated on room restart).
In the create event for obj_paper, type the following using GML.
//Assuming the sprite for obj_paper has it's x & y positioned in the center of the sprite
instance_create(irandom_range(x-sprite_width/2,x+sprite_width/2),irandom_range(y-sprite_height/2,y+sprite_width/2),obj_dot);
That should do the trick nicely.
Related
I'm a bit new to GMS2 and am having a bit of a problem.
In the current state of my game, you start in a useless room that only exists to initialize global variables and a persistent object. This room then switches to an actual level. All of this occurs in the creation code of the first room:
globalVars();
instance_create_depth(-2*global.tile_size, -2*global.tile_size, 0, OBJ_UTIL_manager);
room_goto(2);
Upon switching rooms, only some of the instances appear. In particular, only objects without a parent or with one certain parent appear. Objects with another type of parent do not appear. They are present in the room builder. They DO exist, but are invisible.
The same room, if moved to the top of the room queue and therefore being the first room created, works just fine as long as I add the above global variable initialization and manager object creation. Is there anything special that must be done when switching rooms to make things visible?
This is how the room appears in the editor: http://prntscr.com/lg2x3w
Compared to how it appears upon being switched to: http://prntscr.com/lg2wdg
I do not know the full detail of the problem, but I did have a similar issue, so I can tell you a solution without actually knowing what went wrong, but anyways hope it helps.
Firstly, use the instance_create_layer instead of instance_create_depth and make sure that these layers where you create your objects exist in both the first "fake" room and the actual room.
secondly, make sure you do not have any code that change the depth/layer in the create event. [again I do not know why this could cause an issue, but it did cause an issue to me, so maybe you have the same issue/solution]
I have the following problem:
I have a list of Components, that contain Rectangles with a width of either 200 or 800. I'd like to filter this list, and only create objects of the Rectangles with a width of 200 as I work on a small screen.
Preferably I do not want to create all objects, check their width, and destroy those with the wrong width again. For obvious reasons I really only want to create those with a width of 200.
To do this I would need to aquire knowledge of the width, before I instantiate them.
As far as I have seen, there is no publicly available and documented way of introspecting/reflecting the Component prior to it's instantiation.
My question is: Is there a non-public way to gain knowledge about what is packaged inside of my Component? Might it be possible with C++?
Or would it at least be possible to find out what kind of Object is encapsulated? Whether it will be a CustomComponent1, a Button, a RedRectangle...
Unfortunately not. You can't even predict it, since the Component could even point to a qml file that hasn't even been downloaded yet, if it was fetched from the network.
There are a couple of things you can try though, if you have room to approach the problem from another angle:
What you can do is pass properties from outside the component into it as it gets created. Assuming you control the code within the Component, you can then adjust how the internal elements get created based on the value of the property(ies) that was(were) set from outside.
If that's not good enough, say your Component provides multiple elements and you only want to create the ones that match your criteria (possibly a combination of many), then you can introduce a second Component layer within the first Component, and have that second Component either create the actual element if it matches your criteria, or an empty Item{} if it doesn't, which is as close as it gets to not creating anything.
I hope that helps!
Im learning about using NSOperation, NSOperationQueue for my networking calls to deliver a more responsive UI in my apps' table view.
The result of the networking operation get stored into the realm and displayed in the table view.
This is an infinite scroll table view and as the user gets the end, more data is pulled into the app.
I am wondering what is the best design paradigm to use here, and where is the best spot to clear the realm. I don't want to inflate the app with useless data. I just want them to have data if they log back in with no network (airplane mode).
I also would like to know where the best spot to trigger these networking operations is? cellForRowAtIndexPath perhaps? I am not to sure since I usually just use Alamofire and trigger a network request in viewDidLoad. But these are not cancellable calls.
I've gone through the great tutorials on ray wenderlich but other then the playground examples, I am still not getting a real world application tutorial. If anyone knows of a good one on this subject let me know
thanks
This might be tricky to answer since it all depends on your app, the size/type of data it's displaying and how often you want to perform network fetches. In the end, it will be most likely be a compromise between what 'feels good' and how many system resources need to be consumed to make it happen.
In this particular scenario, Realm is being used as a caching mechanism and nothing more, so when to clear it should probably depend on how aggressively you wish to clear it.
If I was building a system like this, I would decide on a set number of the latest items I would always want to have available and save them in Realm. If the user then decided to start scrolling down beyond that limit, more data would be downloaded and appended to the Realm database as they went. Eventually the user will get tired and scroll back to the top (Or they might even just quit the app and restart from the top). At that point, it would be appropriate to trigger an operation to review the size of the Realm cache and remove as many items as necessary to bring it back to the desired size. If they start scrolling down again, then it's appropriate to just re-download that data.
Unlike SQLite, where items are copied into memory, Realm is very good at lazy-loading resources mapped from disk, so it's not necessary to worry about the number of Realm items in memory, more just the size of the Realm file on disk, which again depends on how big the data you're downloading is.
As for when to trigger another network operation to request more data, it's probably best to do it in tableView(_:willDisplay:forRowAt:). Depending on how large the data to download is (and the size of your table cells are), you should play with it until it feels natural when scrolling at a pretty normal speed. As a starting point, I'd recommend starting at maybe a whole screen-worth of table cells before hitting the bottom of the scroll view.
Good luck!
I just got back into XNA and i started creating a map editor. The game will be a 2D editor that will contain both a Animation, Map, Level, entity, and crafting editor. So far it's going pretty swell right now; but, I think i am missing some key things within the editor
Here let me explain the game I'm trying to make:
I really want to figure out how to craft a particle editor
I also want to know how to use farseer phsyics engine (tried getting started on XNATutorial.com, but it's not working correctly).
Thank you in advance for any help you can give me, I'm just trying to see what would be the best things to enter into the game for a 2D action platformer.
To craft a particle editor decide on what you want to be able to do first, then come back with more specific problems, or questions.
Maybe you want to be able to design a particle template. This could define a particle's appearence and behavour.
Then you'd edit a particle emitter template. This would define what particle template to spawn, and what initial properties a particle instance would have.
Then you'd create a particle emitter object in your editor. You could maybe override specific properties in the particle emitter templates.
You could event have a particle emitter template that was a list of particle emitters to spawn, so you could emit different particles from a single editor object.
This would allow you to create lets say a fire-outside particle template, which was a yellow circle, a fire-inside particle template which was a red partcile, with a shorter life than for former. You'd then define 2 particle emitters, one for each one. Giving spawned particles upwards, but slightly random directions. Then create a multi-emitter called Fire or something. Then in the level editor you'd just have to place your Fire emitter and in-game you'd get a nice fire effect.
Posting a specific problem you have with setting up the physics engine would help.
The overall idea is that you have your game object representation, and you need to create and link them to the physics objects so you can simulate those objects and then update your game objects (for rendering and game logic).
So, when you load your level you'd loop through every physical object and create an equivalent in your physics engine, being sure you can link your game object to the physical one later. Obviously you'd need to keep both systems in sync by adding/removing physical objects as the game progressed and game objects where created/destroyed.
Then in your game loop you'd run your game logic, which might update their positions directly. Then update the physics objects so their position was the equivalent to the game object's. Then run a physics update. Then update your game object's positions according to the physical object's positions.
I have several graphs. The breadth and depth of each graph can vary and will undergo changes and alterations during runtime. See example graph.
There is a root node to get a hold on the whole graph (i.e. tree). A node can have several children and each child serves a special purpose. Furthermore a node can access all its direct children in order to retrieve certain informations. On the other hand a child node may not be aware of its own parent node, nor other siblings. Nothing spectacular so far.
Storing each graph and updating it with an object database (in this case DB4O) looks pretty straightforward. I could have used a relational database to accomplish data persistence (including database triggers, etc.) but I wanted to realize it with an object database instead.
There is one peculiar thing with my graphs. See another example graph.
To properly perform calculations some nodes require informations from other nodes. These other nodes may be siblings, children/grandchildren or related in some other kind. In this case a specific node knows the other relevant nodes as well (and thus can get the required informations directly from them). For the sake of simplicity the first image didn't show all potential connections.
If one node has a change of state (e.g. triggered by an internal timer or triggered by some other node) it will inform other nodes (interested obsevers, see also observer pattern) about the change. Each informed node will then take appropriate actions to update its own state (and in turn inform other observers as needed). A root node will not know about every change that occurs, since only the involved nodes will know that something has changed. If such a chain of events is triggered by the root node then of course it's not much of an issue.
The aim is to assure data persistence with an object database. Data in memory should be in sync with data stored within the database. What adds to the complexity is the fact that the graphs don't consist of simple (and stupid) data nodes, but that lots of functionality is integrated in each node (i.e. events that trigger state changes throughout a graph).
I have several rough ideas on how to cope with the presented issue (e.g. (1) stronger separation of data and functionality or (2) stronger integration of the database or (3) set an arbitrary time interval to update data and accept that data may be out of synch for a period of time). I'm looking for some more input and options concerning such a key issue (which will definitely leave significant footprints on a concrete implementation).
(edited)
There is another aspect I forgot to mention. A graph should not reside all the time in memory. Graphs that are not needed will be only present in the database and thus put in a state of suspension. This is another issue which needs consideration. While in suspension the update mechanisms will probably be put to sleep as well and this is not intended.
In the case of db4o check out "transparent activation" to automatically load objects on demand as you traverse the graph (this way the graph doesn't have to be all in memory) and check out "transparent persistence" to allow each node to persist itself after a state change.
http://www.gamlor.info/wordpress/2009/12/db4o-transparent-persistence/
Moreover you can use db4o "callbacks" to trigger custom behavior during db4o operations.
HTH
German
What's the exact question? Here a few comments:
As #German already mentioned: For complex object graphs you probably want to use transparent persistence.
Also as #German mentione: Callback can help you to do additional stuff when objects are read/written etc on the database.
To the Observer-Pattern. Are you on .NET or Java? Usually you don't want to store the observers in the database, since the observers are usually some parts of your business-logic, GUI etc. On .NET events are automatically not stored. On Java make sure that you mark the field holding the observer-references as transient.
In case you actually want to store observers, for example because they are just other elements in your object-graph. On .NET, you cannot store delegates / closures. So you need to introduce a interface for calling the observer. On Java: Often we use anonymous inner classes as listener: While db4o can store those, I would NOT recommend that. Because a anonymous inner class gets generated name which can change. Then db4o will not find that class later if you've changed your code.
Thats it. Ask more detailed questions if you want to know more.