This is how I did it:

I see Toralord beat me to it with this one but this is my take on grid based pathfinding.

Wot I did was:

Use the Hunter sprite with the RTS behaviour and changed the settings so it could not move but would point in the right direction based on whatever path it has determined.

Always set its position to Hunter2 which has the grid behaviour

Then, depending on the Hunter's RTS direction, changed the angle of Hunter2 and let the grid movement do its thing. Technically you probably shouldn't even need to change Hunter2's angle or worry about whether or not it is blocked or most of the other checks you see in the code but I would prefer that the pathfinding spaz out and not move than end up in a solid object.

Piece of cake.

Personally I wouldn't worry about polishing sprites until you're satisfied that the basic engine works but I would make the effort to make sure that my placeholder or prototype sprites are approximately the same shape and colour as what you plan on eventually using. Otherwise you're very likely to run into bugs and design problems later on (for example, don't use a block when the final sprite is going to be a non geometric shape like a fish or a star.)

I prefer not to use the editor included in Construct, I make all the images in paint.net or photoshop, save them to disk and update them when I decide some polish is needed in case a change I made in the graphics causes some kind of problem and I need to revert back to an earlier version of the sprite to figure out what caused the issue. Don't get me wrong, the editor is perfectly good but an external program gives me more control over masks and transparency.

Prototyping before you bother polishing also makes sure you don't spend hours polishing and perfecting some lovely tiling textures before you notice that you need some additional sprites that you never accounted for and won't fit without scrapping a lot of the work and having to go back to the drawing board. Or worse still, that the sprites just flat out don't work for what you had in mind.

Most games, even the massive budget triple A titles look like blocky crap right up until the last few weeks before release when the developers are sure that everything works the way it should.

Despite working on my game for freaking ages now I never noticed this oddity until a couple of days ago. It seems my little bad guys have a vendetta against one of my soldiers to the exclusion of everything else, including their own safety. While I appreciate their dedication I feel that a little focus might be in order.

The situation is this:

I have a simple enemy AI set up using LOS and RTS behaviors. The AI is

Enemy Has LOS to Player

System: Repeat For each Enemy

Enemy Move to Player

(I suspect that my problem stems from this being TOO simple but I can't figure out what I need to add to fix this)

This works perfectly with one player but when I have two player sprites there are two scenarios:

If both player sprites are moving around then the enemy AI works exactly as I would expect, they all move towards the player sprite when it enters their LOS.

If one sprite is selected and moves into the enemy LOS then one or two of the enemy will move towards the first player sprite that was created on the layout.

I have a .cap at http://www.schwoom.com/Engine/RTS.cap

(Drag-select to pick the units you want to use, space to remove your selection. The soldier at the top is the first one that was created)

Edit - I'm using 99.62 and 99.82

I'm breaking this up to avoid a gigantic wall of text.

Assuming you don't have the $200,000 (conservative estimate) to pay people to engage in a project like this you're obviously going to have to go down the freebie and charity route.

Also assuming that you've put together a good design document, pitch, business case and legal setup (the open source community covers a lot of these bases thankfully) consider this.. or look at this. Sourceforge.net currently has 21,965 projects in the "Games" category. Of these 3096 are listed as "Production/Stable" i.e. fit for release, use and making money. Twice that number are listed as "Planning" and 677 are listed as inactive. My point is, not many projects make it to completion.

This is a major pitfall - people don't want to work on projects that never see the light of day, it is discouraging, disheartening and almost ensures they won't want to work with the people they see as being to blame for the failure of the project to reach completion. So ask yourself if you are willing to see the project out through thick and thin because if you aren't you're doing yourself a disservice and an even greater disservice to the people you hoodwinked into spending their time and energy on the project. The game development community, even the indie one is SMALL in the greater scheme of things and your name and reputation is very important. Failures are forgivable but walking away from a project or sinking it is not.

Which brings me to my next point. Everyone on these forums, or indeed ANY game development forum are here because they're interested in making games, typically their own. Everyone's time is finite and you need to persuade people to give some of that precious resource over to your project. So why should *I* take time away from my projects to develop yours? What makes your project a more enticing prospect than me realizing my own dreams? (I'm not trying to be aggressive here, these are thinking exercises because you'll need to persuade people of this mindset). The people you WANT to help on a project are the competent and skilled developers and artists and they're the ones you need to persuade but are, unfortunately, the hardest to persuade.

Finally, if I come across as condescending, patronizing or rude, that was not my intention. This represents my own experience (both as a hobbyist and a professional) in areas related to what you are talking about.

Thats my advice, take it or leave it.

Edit: I appreciate the irony of going on about spending an hour writing about how a person's free time is finite in response to what may well be a particularly crazed bot thank you very much.

Hello again i recently posted the making OS but when i woke up this morning i came up with a brilliant idea of making a game console for the PC with pre-installed games and mini games this project will last a long time and be massive but i think that the end result will attract a lot of attention and if good enough make some profit.

Things you will need :

A prototype/proof of concept, I see you did something along those lines with your shell. At the bare minimum you should have done some layouts in photoshop or similar to give prospective stakeholders [(People who will be investing time in the project). A design outline (for pitching to people you want involved in the project) A detailed design document for your own use and for anyone who joins the project. This needs to describe, in detail, EVERY ASPECT of your idea. No "I'll decide this later" or "To be designed" if you start out with a bad design document you will be lucky to finish with a crappy product. Take something as simple as pong - Two bats, one ball and a barrier at the top and the bottom. Simple right? Well hang on, how are you calculating the angles? Do you know the Newtonian physics equations for impact angles and deflection? How are you calculating the velocity of the ball relative to the bat and how will collision affect this? Something as simple as pong would have a two page design document at least. At minimum I would expect to see a fifty page design doc with illustrations for what you're describing. Excellent communication skills - Not to be mean but your post is slightly lacking in basic grammar and punctuation. Unless you can communicate your ideas with a high degree of precision and in a manner that leaves no room for misinterpretation you will have serious problems. A project outline/timeline/budget - Are you planning on paying people? are you going to sell the end product? How will you reimburse people for the time spent if you DO sell it? Do they get a flat payment or a percentage? Do they get anything for version 2.0 of the product even if they're not directly involved in that? How long will it take overall? How long will each stage take? How much time must each team or team member invest in this? When will their assistance/input be required? Will they be working on it for an hour a week throughout the whole project or for a solid fortnight at the end? Are you going to translate the product? Who will test it? What is involved in testing? When will testing begin? What input methods are supported? Is multiplayer involved? Is it simultaneous or hot seat multiplayer? Are you familiar with various software licenses? Do you have the legal know how to ensure that you're not left financially liable for any work done by a team member? How are you going to manage the team? How are you going to plot out the timeline? What are the critical points? How will you deal with delays or failures by team members to deliver on time and to the required standard? Now, in case you think I'm being deliberately obstructive, these questions represent only a sample of the variables and problems you need to consider before the first byte of code is written. Granted, I may have overestimated the scope and size of what you're talking about based on your very brief description but as you said yourself - "Massive". Finally, let me give you a very quick example of the scope of the average Xbox live game (much less what you're talking about). The average podunk 800 MS points crappy remake or regurgitated remake requires: Five developers, possibly one designer/developer[1], one development lead, one functional QA team lead, five functional testers and six months of time. Not to mention additional financial costs like the Xbox Live submission process, lawyers, PR and licensing fees (Which I know will not be a problem for a PC game but it serves to illustrate the hidden fees no one expects to be hit with)

[1] Pure designers are a rare beast indeed. They all get their hands dirty.

Here is an exe of one of the two games I am working on at the moment (and by far the furthest along)

http://www.schwoom.com/Engine/Engine.exe

Controls are:

Space - clear selection

Drag the mouse over units to select.

Numpad 1, 2, 3 or 4 to create groups then 1, 2, 3 or 4 across the top of the keyboard to select your groups.

Left click to move

Right click to shoot

Left click while right mouse button is down to fire a special weapon

Z to cycle through special weapons (rocket launcher, grenades and sniper rifle)

Or here is a screenshot showing pretty much everything you'll see in the exe.

It is very much a work in progress, the graphics are obviously somewhat mismatched and placeholder-y and I'm well aware of the flaws in the system and graphics right now

http://www.schwoom.com/Engine/Screenshot.png

Impending improvements include:

Fixing the shadows on the trees

Using CTRL + 1, 2, 3, 4 to create groups

Using a circular image to highlight selected troops rather than the square unitbox.

A far broader range of sprites for terrain.

A more elegant solution for the grenades.

Vehicles that can be entered and exited.

Three questions before we begin:

First, are you having multiple pink squares running around with many groups of orange boxes attached to them? Or do you just have one pink square with one group of orange boxes attached? (If you have just one pink square and one group of orange boxes then you don't need Containers.)

There will be one set of pink/orange boxes. This may be where I misinterpreted the purpose of containers - The containers page on the wiki says one use is "To connect objects with detectors for collecting passive input (detecting walls, floors, etc.) " which is what I'm going for here.

I assume that by not needing containers you mean that defining the image points and attaching the boxes to them is what will do the job and containers are redundant?

[quote:ti2v3vx9]Second, do all of the little boxes perform the same function, or is there some special reason why you need to have each box be a separate object? (You may be able to make this grid out of many copies of one orange box... but then Containers wouldn't work that way.)

I could have done a MUCH better job of explaining this so apologies.

The purpose of the grid is something along the lines of:

A non player sprite (enemy or wall or whatever) overlaps box 1a. This triggers an event which displays "Enemy in zone 1A!" warning elsewhere on the layout. If that enemy moves to box 2A the warning changes to "Enemy in zone 2A".

If a second enemy appears and moves in on box 4E then the warning will change to "Enemies in Zones 2A and 4E!". Different lights will flash, sounds will play and so on depending on which box is being overlapped.

So they all perform the same function (with the exception of the P sprite) which is that of a grid based radar. Once walls or enemies are interacting with P, P is in combat and a whole different bunch of events come into play. the 1a to 5e boxes exist to tell us where the enemies are before reaching p.

[quote:ti2v3vx9]Third, do all of your orange boxes exist all the time, or will some be destroyed and/or created as the game progresses? (If you need to destroy some of them, then again Containers won't work. All objects in the Container must exist, or none must exist. There is no middle ground.)

No, all the boxes exist or none exist, no problems there

[quote:ti2v3vx9]Now then. I've gone ahead and shown a method here anyway that will allow your contained sprites to work as intended. But like I said, answer those questions just to be safe, you could be saving yourself some trouble:

http://dl.dropbox.com/u/529356/containers.cap

What I added:

1. Image points to your pink sprite. It would need 25 in total, one for each of your orange boxes. I <Snip>

I've tinted the orange boxes for the group on the left with a red color filter so you can see that the container is separating them properly and the matching ones are lining up only with their contained pink sprite.

Thank you very much ! That appears to do exactly what I was thinking... and a lot more elegantly than the first few drafts I'd knocked together

I'll see if I can knock something together in the next day or so to give you a clearer idea of what I had in mind, hopefully it'll surprise and delight.

I have the feeling I might be trying to run before I can walk here so feel free to call me out on it. I've gone through the Ghost shooter tutorial and the usual culprits but I can't figure this one out. The wiki mentions that containers can be used to combine sprites to use as invisible "detectors" or the like but I can't even persuade my sprites to move together.

I've got a 5x5 grid of sprites. I want to move all twenty five of them in unison and rotate them as one around the central sprite (marked with a P). Something like this.

http://www.schwoom.com/Engine/Illustration.jpg

(excuse the poor art skills there, I'm more of a 3D render guy)

I've included a basic .cap if it helps.

http://www.schwoom.com/Engine/FiguringOutContainers.cap

Hello there,

I've been using Construct for about four months now, playing with ideas and building engines before getting bored trying to make the graphics.

After ten years in the workplace (several of them in the games industry) I'm taking a few months out to catch up with all the things I never got around to doing, learning to drive, reading books and most importantly building the games I've been designing in notebooks and random .txt files for the last decade.

Gotta say though, Construct is something I've been looking for for a long time. Hell, even my inner QA/Tech writer can't find anything to complain about so I reckon I've found a winner here