Arsonide's Forum Posts

  • Subscribe to Construct videos now

    - 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.

  • I got it working for the time being...it's working pretty good now actually. Once I figured out that the function that detects it automatically references the unique ID of whatever it found to the actions I tell it to do. (I was thinking too hard.) The turret movement finally "stuck" and stopped disappearing, and I added the targets and initial move sequence to the "On Layout Start" instead of "On Application Start". It's flawless now.

    Now all I have to do is figure out a way to get the AI controller to choose multiple paths through the level to get to the objective instead of the same straight line every time, using waypoints. However, that'll be on my own time and is unrelated to this problem.

    Sorry to bother ya.

  • Ok this is really weird...now I have a bug where my RTS movement is simply not working. Their max speed is 250, they have received TargetX and TargetY, (I made sure by debugging and watching them.) They are not moving at all though. Speed is 0. That is the only movement they have, and they are not receiving any orders, only one when the application starts.

  • Yeah, theoretically it'd work, but I add RTS, then I add turret, then I go to the event sheet and make all the events. Then I go back to the layout and turret has disappeared from that unit's movements. It just vanishes.

  • That would be ideal but the turret object needs a base object, and for the amount of objects I need...having two rather than one is pretty inefficient.

    They need pathfinding, and I've tried assigning both RTS movement and Turret movement to a sprite. When I do, Turret movement disappears after I add it.

  • I'm having trouble, I'm having two bases spawn a lot of dots and send them at the other base. If they hit another dot, they die, and it works great.

    Now, I want to get the dots to chase enemy dots if the enemy dot gets within a certain range. I'm using the RTS movement...and I can't figure out how to do this.

    Say I tell a red dot to locate it's distance to blue dot. Well each color is an army of dots, but there are only two sprites. Getting the distance to "blue dot", is not sufficient, as there are about 40 blue dots. I need the distance to the NEAREST blue dot, then I need that dot's ID so I can chase it.

    It'd be a little easier (I think), if the LOD movement had a range. I tried using turrets but that seems like a waste of resources. I'm sure there's a simple, event based way to do it. Any ideas?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I am making a basic version of what I intend to do, basically a turn based game without the squares and such, so that movements are in real time but while you're moving your movement bar goes down which limits the distance you can go in one turn...which is where I'm running into a problem...the pathing is not very efficient, atleast how I'm using it. It's wasting movement points for basic movements...and I was wondering if there was something I was doing wrong.

    Right now I have it set at 30x30, which actually made pathing better than 10x10. I also cranked up the rotation speed which seemed to help.