More progress, looks much more professional. Threw in some props for Construct as well should anybody stumble across the movie while crawling through Youtube videos. Deadeye was telling me that some extra muscle around here would be good for the program.

I'd actually done a rudimentary traffic model at the time this footage was taken, but I based it on the "grid" movement behavior, and I think bullet would be better. Grid is much easier to use, but it's kind of hard to get them to stay in their lanes when they are turning. I turned it off for the footage.

Not sure about curves at the moment, Mipey's right, if only key points of a curve are stored in the array then I'll have the curve going over some things on the array - if the curve is stored in two points on both ends, with the curve in the center, then the generator might think those center squares are grass or something. I could do it old school like curves in those old Transport Tycoon games - where a curve is actually like a gigantic L shaped tetris piece on the array, but visually pleasing in the world. Even then though, buildings won't be able to come flush up against the road for instance. It's something to think about, but definitely a tricky situation.

Right now deadeye has me concerned with sidewalks and street paint and all the gritty stuff involving getting those roads and intersections looking like roads and intersections instead of ... well ... sprites on an array.

You can design your own tile map using an array of sprites currently, like I did in my procedural content post, but it is a little more complicated than a tilemap object. It serves the same purpose but requires a lot of looping.

According to David they are at work on a Tilemap object already...though there's no telling when it'll make it into release.

- Whabam! A snap I say! Whipped this up before work specifically for deadeye.

Wish I could keep working on it, but unfortunately Construct requires a running computer - and therefore electricity - and therefore money.

lol arsonide your thing doesn't look nice

At this point it's pretty much purely an algorithm. He does plan on making each building/road/etc a tile (or 3D box as the case may be).

The algorithm is the hard part, applying art to those little dots will be a snap.

Much like the original discussion of procedurally generated content at the Game Developer's Conference by Will Wright was an excuse for him to show off Spore, this is going to be an excuse for me to show off my work.

I'd asked a few months ago if dynamically generated content was possible in Construct and got some mixed replies...it took me a few months to nail the game idea, which obviously has a bearing on progress towards completing it. Needless to say, after nailing the aforementioned idea, and realizing my game was going to be set in the modern era - 1930's to now possibly - not sure exactly when - I set off to make a city generator.

The entire map is held in a 100x100 square array which I feed into a loop to display on the screen. The sprites you see are just 10x10 pixel sprites of solid colors, eventually I will make them about 128x128 and give them art.

The generation process consists of four steps. First I fill the array with blanks, pretty simple. Second is the longest step - the roads. I start out by making a dual lane highway, which right now will always form a cross. Eventually there will be the possibility of straight and maybe turning highways. Then the program will pick a random highway or road, decide what directions are possible for it to go from that point, then branch off in a possible direction and keep going in that direction until it hits something - another street or the boundary of the map. A process which is a lot easier said than done in Construct events. This process will loop about 20-40 times until you get a grid similar to the one you see. The third step is that blank buildings are placed at random along these smaller roads, they don't cluster yet but they should. The fourth and last step is probably the second most complicated one. RCI - Residential, Commercial, Industrial - which is probably a term some of you remember from SimCity. My game is not a strategy game, but for realism I will need these various facilities and thus thought it necessary to add them. The game will choose centers for each zone, and spread the zones into the blank buildings by proximity to these centers...the ones furthest from the centers will be considered "Light Residential", "Light Industrial", or "Light Commercial". Those are the lighter colors you see.

Ladies and gentlemen, I present to you, in no certain order: Brightbourne, Whitemere, Lakegate, and Mossbridge. Four cities I generated in about one percent of the amount of time it took me to make this picture and write this post.

<img src="http://img7.imageshack.us/img7/9673/smallproceduralcitiesin.png">

All of which you may or may not see in my game Crooked sooner or later, depending on how the generator treats you. Crooked is going to be a combination of Trilby: The Art of Theft, Zelda 2, and Spelunky - in that order. That is, assuming I ever finish the game.

<img src="http://img15.imageshack.us/img15/9307/cooltext415895798.png">

Yes...I exaggerated the logo specifically to let you know it's pronounced with two syllables. But back to the subject at hand, procedural generation. A few things I've learned so far. I looked on the web for algorithms, and ended up not finding any...you won't really, especially if you have specific needs. Even if you did find one, it's not going to translate into Construct very well, because Construct is almost conversational in implementation. You just have to imagine how you would draw it, or how it would be. I opened up paint, drew up some roads, and realized I was using 90 degree angles from random points, and that's where I began. Thinking of things literally in that way made it much easier to translate into Construct than trying to think of it mathematically or programmatically. Another thing - doing natural generation has to be a lot easier than doing man-made stuff I would imagine. Random terrain must be a snap compared to this. Anyway, if any of you have any questions, tips, or suggestions, please leave them.

Edit: Posted in general because I don't have a cleanly commented *.cap to upload yet, and while I have plans on making one - this isn't a tutorial yet either.

No there's no performance issue, it doesn't hang at all since the program doesn't even start. It just throws a vague error on startup. If I knew where the logs for these errors were at or maybe could find a more descriptive error it'd help.

So I made a 50,000x50,000 playfield, and spawned 3000 clusters of objects in it. Yeah the program wouldn't run, and it is the size of the numbers because when I reduced them it ran fine, albeit boringly.

It's basically a large space field filled with asteroids and stuff...but it needs to be that populated and it needs to be that large. Is there some way I can stream the objects from an array or something? Things are going to be changing in other places as well, so the objects need to be in memory somehow...either via an array or whatever.

[quote:laoixdvz]Yep, lots of bug reports in the platform behavior at the moment - I'll try sorting it out.

Sorry I couldn't be more specific with the bug reports, but it seems to be any time any part of the sprite touches the ground or leaves the screen. When it spawned in mid air and fell to the ground it froze when it hit the ground, regardless of where the hotspot was. Sometimes it would hit the ground and succeed but freeze when I tried to move. I turned off gravity to test the skew and then noticed it also freezes when it skews off the side of the screen (and there's no solids over there, so I don't know what's going on).

The horizontal skew and a very slight rotation are working miracles, but the image point the gun fires from does not skew with the image, meaning when I aim up and it skews left, the bullets are spawning from mid air rather than out of the gun.

Also I'm having a lot of runtime crashing and freezing with the platform behavior right now...to test the skew expression out I literally had to turn it off, cause it crashes almost every time I run the program.

Now my bad guys are fairly straight forward, they face left, or right...and that's it. The humans on the other hand, they can aim...and I've tried various methods of animating this and none look very natural.

I've tried the following methods:

Seperating the torso from the legs and rotating the torso.

Seperating the head and the arms from the torso, but leaving the torso connected to the legs, and rotating the arms/head instead.

None of these appear very natural and I was wondering if any of you knew of a way to solve this problem using some effects or an image manipulator trick or something. I'm just hoping I don't have to stylize it in the end with Worms-esque floating hands or a human that looks straight forward and fires straight up, or something.

I think I'm going to try rotating the entire body, but not directly at the mouse, just enough (10-20 degrees up/down), so that the player can tell he's looking up or down. There will still be a crosshair to know exactly where, I just wanted some feedback with the player model.

I was trying to feed an 8000x8000 heightmap into the image manipulator, then crop it to 640x480 (It makes a nice random detail texture on the grass with proper effects). However I kept getting a gray box.

After a while I noticed there was SOME detail, but it was really hard to make out. I started narrowing down the actions to see what was going on. I even tried manually setting the crop points, and then took out the crop altogether and manually cropped it in paint...same problem.

So I tried making a small 100x100 pixel bitmap, and loading that in and simply assigning it to a sprite that was also 100x100. The resultant sprite was 312.5 pixels by 312.5 pixels. I tried again without modifying it at all, and it worked fine. I think Construct has some memory glitches going on or something. I get this kind of stuff a lot...like if I open two projects I'll get sprites from one project in the other and have to close both and reopen them one at a time.

I like the tool, obviously, and I'd like to know if I'm doing something wrong with the image manipulator. It seems that it is importing the images incorrectly (sometimes). Even when the sprite it's shooting the image to is the same size as the image itself, and even then when I give a resize action to make it that size, it'll be bigger sometimes.