No worries!

~Sol

You can use custom movement behaviour to make sure no objects are overlapping.

Custom movement has "push out" of object which you may find helpful as a simple way to stop overlap.

A harder (but better way) to do it will be to check for overlap at offset when creating your objects. If it's too close to another object then it can try a new random position to see if it's okay or needs to be moved again.

Hopefully this helps a little bit.

~Sol

The in-built control options for physics objects will do the job (like friction, mass, etc) but if it needs to be more aggressive then you will need to measure the current vector and velocity of your object, and apply a negative force.

You should be able to get a good slow-down effect though just my messing around with the basic settings for your object

~Sol

Ultimately, you would want to create a save/load system for levels, using an array or dictionary (I personally find dictionary much easier to use for this type of data handling).

If you can do this, that means you can make your own level-editor (and maybe include that with the game itself) and just export the levels you build so that your game will simply load all data relevant to the level design. Use your different layouts as a way to control the tile-sets used if you like - but learning to use a dictionary to save and load can be super handy in the long run. It's actually easier than it seems (hey, I managed to do it, so it's gotta be easy!) to get a system working like that.

PseudoCode:

On SAVE

-> loop through objects or family type for object.count times

---> write to dictionary at line (loopindex) data.width, data.height, data.x, data.y, yoda.mmmyes

Loading is basically the same thing, but I find loading the data string into a global variable can be handy for a lot of stuff... but sometimes you will simply loop through the number of entries present to create objects from (again, using loopindex or dictionary line counts) to create the object and set it's data.

There's NOTHING WRONG with doing it the way you're doing it though... it just means that if there's any expansion to the game, you have to hand craft each and every layout. Sometimes it's faster to do it that way, but with enough levels and tile-sets... it can be worth spending the time to create a level editor and save/load feature for your levels. Ultimately it can SAVE time, depending how far you're gonna go with content.

~Sol

You can make a new event sheet, include it to your main one, and put all the GV's on that one event sheet.

That's what I do, and seems to be a pretty popular method used by many here also.

~Sol

I have made similar systems in the past.

The way I did it, was anything that I wanted to be able to burn had it's own set of instance variables, basically to control things like "IsOnFire:0/1" or "BurnRate:X" etc.

I then had a single event for each burnable item that checked if fire existed, and if it did to check what it's overlapping, and if it's overlapping anything that has the variable "IsOnFire" and that value was "0" then it would change to 1.

Once this variable was set to 1 (or whatever you want to make it be) then I had one more event that would create fire sprites, etc.

I used "Fade" behaviour on the fire to give it an automatic lifespan (if it was overlapping nothing burnable, or something that had already burnt). Essentially what you want to try and create is a blanket system that works on anything by building a "fire system" that you can add objects to by either including them in a family (called BURNABLES or something) or by creating one event per burnable item. I went with using separate events myself because my burnables had very different effects on them depedning on the thing that was burning... but if you want a nice generic burn effect that looks pretty much the same on all or most items, using a family would be a good way to do it.

Remember that you can easily add all objects to multiple families... so you can make a BURNABLE family, and add objects to it that might be part of some other family already, and that should work just fine.

Hope this helps a bit!

*EDIT*

I forgot to mention, what I created to solve my issue was basically what's referred to commonly as a "state machine" - wherein you have a sequence of steps that will happen when fire is encountered. IE: Step 1 check for fire, Step 2 initiate burn if applicable, Step 3 generate fire effects and particles/etc, Step 4 change to "Burnt" state and set animations, Step 5 destroy or invalidate. I actually use a string based instance variable that I call "STATE" and set it to whatever text word I feel is appropriate - like "fresh" and "burning" and "burnt" - then use these "state words" to jump from the initial state to the next and next, and so on.

~Sol

Hey, even I still do that sometimes... It's an easy thing to overlook, especially if you don't use multiple layouts very often.

Glad you sorted it out!

~Sol

Driving AI is often a difficult thing to approach, because there's a lot of ways it can be done - and they're often used based on the applicability to the style of racing game you're trying to make.

You can use things like bullet behaviour and set up custom "intersections" that gives the AI some orders to adjust angle, choose a direction, etc. You can use a path behaviour of exact driving, coupled with custom movement, phsyics, or almost anything else to give the AI a chance to "be less perfect". As mekonbekon has said you can try pathfinding, though the type of movement you would get wouldn't seem much like a car that's driving.

Are you doing a birdseye/overhead view racing game or maybe isometric? Are you planning on having conventional cars, or are you doing some kind of hovering racer? A little more information about your idea would maybe help find a good course of action to investigate.

~Sol

You can create a fairly convincing rotational effect with 8 directions, depending on how you've drawn your graphics.

You can have smooth rotation of your object, and change it's directional animation at the points where 16 angles would exist; IE Change from 0 to 45 degree animation at angle ~22.5 degrees.

If you're using isometric sprites then this will probably not work very well (especially for human-type characters) but you may get away with it for certain objects (things like a moving vehicle tend to work out OK using this method). I find this works best using pseudo-isometric sprites (games like Legend of Zelda).

Of course if your game is overhead/birdseye view then you can do it with simply 1 angle only, so I assume you're using isometric?

~Sol

You can do this in a few ways... I'm guessing that your enemy units are all individual sprites, and not one sprite that represents a whole group of enemies?

If they're all separate, you can set the target to the projectile when the projectile is being created (on shoot). You could make some instance variables for the arrow, or the soldier, and call them something like TargetX and TargetY. Then you can pick the enemy that's closest to your defending unit, and set the instance variables TargetX and TargetY to be the coordinates of the enemy.

You can then use the coordinates (pick by comparison) to tell your soldier or arrow which unit to apply damage (and also to trigger to destroy your arrow sprite). Simply compare the TargetX and TargetY values to the coordinate position of the enemy. I would recommend setting a comparison RANGE of say, 3-5 pixels or more (depending on the size of your graphics).

Hopefully this hint helps. If you still have problems just let me know here and I will see if I can make a quick example.

~Sol

I had to look up this Dictator series of games, and I will suggest that C2 can easily make this kind of game. C2 can make basically any game you can think of, as long as it's 2D.

The skill in using C2 to achieve the idea would be moderate, but that's what the community are here for. If you have a simple grasp of C2 and just need suggestions or guidance on the best way to approach something, or maybe more direct help with using more advanced features... just post to the forums here

Dictator looks like more data handling than anything, as in, money in/out and volumes of population, random number generator perhaps... all of this is possible and fairly straight forward to achieve. There are no blanket examples of making this type of game, but I would suggest looking up the various ways you can handle data with C2 (saving complex data structures) using browser/webstorage (for mobile devices) or NWjs (for saving to PC platforms).

Have you tried the free version of C2 yet? If not, give it a whirl and follow the basic tutorials that come with it to help you understand the program. If you already have it, then let us know what you'd like help with specifically

~Sol

Looks great at 120Hz but I notice a bit of motion blur at 60Hz... I notice that the blur actually is just a trick of the eye though when moving fast, because if I change focus and carefully look at anything "blurred" it's immediately no longer blurry. When I play at 120Hz though it looks totally fine.

I'd say, like the others have suggested, it's a bit of an optical illusion because things are moving rather quickly.

Neat game btw, and cute graphics.

~Sol