Randomly Generated in same location?

#1 I created a perfect random generator for a card shuffle algorithm for a card shuffle routine. If you have a set amount of sprites to generate, I'm sure you could implement this code:

function shuffleDeck()
{
   //shuffle the cards
   // start with deck qty, iterate down to 1
   // use a random of how much is remaining, store a temporary variable to the deck iterator
   // store the iterator to the end, and change our temp to the end, swapping out the cards
   for(%i=53;%i>0;%i--)
   {
      %n = getRandom(%i);
      %temp = $deck[%i];
      $deck[%i] = $deck[%n];
      $deck[%n] = %temp;
   }
}

Note that in this case I used a global for $deck as my initial array deck of cards, in your case you could use your composite sprite index array.

#2 Interesting algorithm, although I'm not entirely certain I'll be able to apply it in this case. What I am doing is I am creating a Composite Sprite and defining its %xrange and %yrange. It's in Rectilinear layout mode, so it will fill up a rectangle based on how I define the %xrange and %yrange. The algorithm ultimately ends up with the %xpos and %ypos (x postion and y position) as its output, which tells the Composite Sprite where to add the block. This is all random, so sometimes the algorithm wants to just put a block in the same %xpos and %ypos.

So, in this case, there isn't a set amount of sprites to be generated. I was hoping I could nest an 'if' statement or perhaps add some other variable to define that another block (sprite) has taken a location already.

#3 Ah, I thought perhaps you wanted to randomize the sprites themselves. In your case, a set of nested for loops would probably work, you'd need a little fluff to determine stride, but you could use something like this:

function createBoard(%board, %randX, %randY)
{
   %size = %randX * %randY;
   %board.setDefaultSpriteStride( %size, %size );
   %board.setDefaultSpriteSize( 8, 8 );
   %board.SetBatchLayout( "rect" );
   for(%y=-%randY;%y<%randY;%y++)
   {
     for(%x=-%randX;%x<%randX;%x++)
     {
       %board.addSprite( %x SPC %y );
     }
   }
   return %board;
}

#4 That's exactly what I'm working with. In this example, however, it is just filling in the rectangle. What I have is an algorithm that distorts randomly where the sprites are added by altering the %x and %y values. This results in the rectangle being filled, but randomly so that some blocks are empty and some are filled. I'll give an example, for simplicity's sake I'll just add a single variable to alter the position:

%map = new CompositeSprite();
%map.setBatchLayout("rect");
%map.setDefaultSpriteStride(4, 4);
%map.setDefaultSpriteSize(4, 4);

%yrange = 80;
%xrange = 80;

for (%y = -%yrange; %y <= %yground-1; %y++)
{
	for (%x = -%xrange; %x <= %xrange; %x++)
	{	
		
		%frequency = getRandom(2, 8);
		
		%xpos = (%x*%frequency);
		%ypos = (%y*%frequency);
			
		%map.addSprite(%xpos SPC %ypos);
        
		%map.setSpriteImage("Assets:Blocks", 5);
		%position = %map.getSpriteLocalPosition();
		%map.createPolygonBoxCollisionShape(4, 4, %position);
		
	}
}

This is very much simplified from what I am using, although it should get the point across that the sprites being added can be at a random position. What I'm running into is that the sprites sometimes are added to the same location. The calculations don't discriminate, they just say to add blocks in the space randomly.

#5 I think I understand what you're saying, but what I wonder is why you would go about doing it this way??

I'd honestly say it would be better overall to create the "base" full, and then randomine the pattern based on the index value of the Composite Sprite as I eluded to initially. Otherise, you'd have to write a check routine for every instance of creation which would be costly.

In my original method, you could take the index value of the Composite Sprite itself, and then assign the random factor for assigning the actaul visual aspects.

I've been playing a lot with the Composite Sprite in my re-write of the Checkers tutorial (almost done... lol), so I'm more used to accessing the index value of the Composite sprite and using that as my mod factor. Overall it makes more sense, because as you've run across trying to randomize the placement of your grid just wont work, and the Composite Sprite is not rally meant for that except in perhaps a custom role.

#6 It is very possible I am not going about this in the correct way. I am merely trying to use the Composite Sprite as a terrain block for a side-view 2D game. I'm trying to apply distortion to it, so that it doesn't render in a perfect rectangle. Which has been achieved, and I'm sure there is a simple way to flag the tiles as they are created so that other tiles don't get created in the same location.

I'm using the CompositeSprite for the terrain rendering in this way because of its built in culling, so I can make large tilemaps that are randomly generated without a performance hit.

I'm not entirely sure what you mean by 'accessing the index value of the Composite Sprite'. It is very likely I'm just not familiar with this type of indexing of which you speak, as I am relatively new to T2D and script in general.

Edit: Wanted to clarify that the game I'm trying to make is similar to Terraria, so it requires there be a grid of tons and tons of squares. I found the Composite Sprite to be the best way of achieving this with T2D.

#7 As you create a Composite Sprite each element of the Composite Sprite receives an index value, accessable is a few ways. I use CompositeSprite.selectSpriteId(%id), and in the case of my checkers game I wind up checking, setting and moving things based upon a 1-64 value obtained.

What you could potentially do is check the position of the Sprite before placing a new one, and if there is one there, then go back and try again.

You can access the position of any Composite Sprite via CompositeSprite.getSpriteLocalPosition()

I'd look at the options for Composite Sprites, as I delved into creation of the Checkers game I found some pretty awesome things. The Composite Sprite module that comes with the main dowload has some good examples. I try to play with things by putting echo statements in place and having the console available.

I think by checking position of each crate Sprite might be taxing a little bit, but it's just data really until it gets added to the scene, so it might not be so bad.

There's a ton of info out there, also I recommend Torsion if you can afford it, it shows the capabilities of each element very well, and if you're unclear on meaning, echo statements tend to help :)

#8 I'll look over the info again about indexing...

But as you can see, this is a little bit beyond using CompositeSprites in a conventional way. I'm basically laying out the sprites within randomly, in sections based on what the terrain should look like. The bothersome part is that it all works as expected, just it's trying to create tiles that overlap one another.

I was honestly very excited when I discovered I could actually use these algorithms to randomly map the tiles. The only reason I don't use the 'custom' layout or 'noLayout' is because then I wouldn't be able to use the .setDefaultSpriteStride() method. So the tiles won't align in a grid.

It just seems that I could declare a single variable or something right when this happens:

%map.addSprite(%xpos SPC %ypos);

That would say, "I just got created at %here, don't .addSprite(%here)"
I mean, really, I already have the variable %position being created to get the postion of what was just made. Surely that can be referenced to do this.

I'm sure it's simple, I'm just overlooking something obvious..

#9 There is a sort of simple means to check if a spot is occupied by accessing pickPoint. I mocked up a script based on your example, you might have to change the frequency in the second part, but this this should at least prevent location duplication:

%map = new CompositeSprite();
%map.setBatchLayout("rect");
%map.setDefaultSpriteStride(4, 4);
%map.setDefaultSpriteSize(4, 4);

%yrange = 80;
%xrange = 80;

for (%y = -%yrange; %y <= %yground-1; %y++)
{
	for (%x = -%xrange; %x <= %xrange; %x++)
	{	
		
		%frequency = getRandom(2, 8);
		
		%xpos = (%x*%frequency);
		%ypos = (%y*%frequency);
		
		//check if spot is occupied
		%newPos = checkPos(%map, %xpos, %ypos);
			
		%map.addSprite(%newPos);
        
		%map.setSpriteImage("Assets:Blocks", 5);
		%position = %map.getSpriteLocalPosition();
		%map.createPolygonBoxCollisionShape(4, 4, %position);
		
	}
}

function checkPos(%map,%x, %y)
{
   // Pick sprites
   %sprites = %map.pickPoint(%x, %y);
      
   %spot = %x SPC %y;
      
   if(%sprites ==0)
     return %spot;
   else
   {
      //Spot is occupied
      %frequency = getRandom(2, 8);
		
		%xpos = (%x*%frequency);
		%ypos = (%y*%frequency);
		
		//check if spot is occupied
		   checkPos(%map, %xpos, %ypos);
   }
}

This should about do it.. All you have to do is check to see if a spot is selected at the position sent, if there is no sprite, then send back the position, if there is a sprite there, than re-do the frequency... again, might get skewed values here...

#10 Thanks for the help Doc, although I'm not having any luck with this.

I am still under the impression that I should be able to simply flag the variable %position to be 'full' or something similar. Then, with a nested if statement, I could say if %newPos is 'full' don't fill it. I'm just not proficient enough with TorqueScript to say this correctly yet. Anyone? This has got to be really simple...

#11 That's why I used pickPoint, it's far less expansive than a comprehensive check of all positions in use. You could further separate this to check if the position is used with pickPoint, and if so, do nothing. If it's empty than call to add the sprite. All pickPoint is doing is checking against the poisition sent to it and if there is a sprite of the Composite Sprite at the position, then it will have a quantity returned.

#12 That makes sense, thanks for explaining this stuff to me. I feel like I know 'just enough to be dangerous' so I don't always know exactly how to approach the logic. It does make sense to me to only check the position instead of all positions. I am having a little trouble understanding how the new function checkPos is working, but that's due to my n00bness with TorqueScript. If I may ask a couple questions to better understand the script (bear in mind I am a beginner with all this):

When you declare the function checkPos(%map, %x, %y), would checkPos(%map, %xpos, %ypos) be more accurate?

Where it says if(%sprites ==0), I am confused as to how a value of 0 works when the values it is being compared to are 2 numbers (x,y).

At the bottom of the checkPos function, it says checkPos(%map,%xpos,%ypos) which is what I originally was thinking we may want to use as our variables. I don't understand how you declare the function, but also call on it within the declaration.

Thanks for taking the time to look at this stuff with me, sometimes understanding basic concepts is all that stands in the way. I'll continue trying to get your example to work, right now my console's telling me 'unknown command: pickPoint'. I know that pickPoint is a command for composite sprites, but perhaps it can't be called from another function?

#13 Not a problem, we all have to start somewhere. I've been involved with Torque scripting for years, so sometimes it just seems obvious to do things a certain way.
For the function declaration of checkPos(%map,%x,%y) All this is doing is taking in the information sent to it. So, we feed it: %newPos = checkPos(%map, %xpos, %ypos); Which means we are setting a variable equal to the result of the function and passing in infromation in order to get results. The reason I left off the extra pos is that I originally thought you might want to re-formulate the frequency and did not want to get lost with variables, and to keep it consistent with re-calling the function.

For if(%sprites == 0) I left out 1 part here, my bad.. Add this %spriteCount = %sprites.count; and then check against %spriteCount instead of just %sprites. What is happening here with this is we pick a point in the world at x,y and if there is a composite sprite ocated at that position, we get a value (or multiple values if we hit several). Then, we would check the count of that point selection.

For the last part of checkPos, this is a slightly dangerous thing to do, but if done properly you're okay. For the example I had given you, I assumed re-factoring the value and sending it back through the function again to get a result back so when we go to actually add the sprite, it has a valid position. The reason I used %xpos & &ypos instead of %x & %y was due to re-doing the frequency setup.

If the console is saying that pickPoint is an unknown command, we might be losing our reference (even though we pass our CompositeSprite through to the function, sometimes... well.. it acts quirky. So, what you can do to potentially remedy this is to give your CompositeSprite a class, for instance:

%map = new CompositeSprite(){
   class = "myMap";};

Then instead of using %map.pickPoint() You would use myMap.pickPoint()

It really depends on what you want as a final goal. I probably misunderstood exactly what you were looking for through some of this.

One thing I wasn't sure about was %yground I didn't see it declared anywhere? Mybe you have it started elsewhere?

I hope that explanation helps a bit. I could probably re-write what you need accomplished, but might need a little more clarification. Or if you really need some tweaking, you could send me the files and I could send it back through e-mail.

Usually try to stay on the boards here for the most part, as it's better for everyone to see what "can be done" ;)

#14

Quote:Usually try to stay on the boards here for the most part, as it's better for everyone to see what "can be done" ;)

Absolutely. Sometimes it just takes getting a good look at it for yourself to see what is going on as well. First, I just want to say thanks to the community here for helping me along up to this point. I don't believe I would have even known where to start without the T2D boards! By the time this is all finished, it may well be the 'T2D Community Terraria Game' :P I'll explain here for the community, and also send you the unaltered project. When it starts, you can briefly see that the blocks are indeed randomized but a popup occurs saying Torque2D stopped working. The console just shows that the script was repeatedly trying to add blocks on top of existing blocks.

Anyways, I started out just making a big rectangle and adding a simple animated sprite character. He's running along the top of the rectangle, check. So now I wanted to randomize that rectangle a bit. So the algorithm I learned about is similar to perlin noise. Because all of this is taking place within the 'rect' layout, we cannot use the frequency or amplitude values precisely as they would normally be used. This would render the distorted rectangle so accurately squares would be stacked very close and on top of one another. Keeping this in mind, we just added some distortion to the rectangle:

function World::createCompositeSprite( %this )
{
	//Terrain 'Gradient'. Declares 'y' value for different elevations.
	%ymountain = 80;
	%yhill =  20;
	%yground = -1;
	
	%yrange = 80;
	%xrange = 80;

	%map = new CompositeSprite();
	%map.setBatchLayout("rect");
	%map.setDefaultSpriteStride(4, 4);
	%map.setDefaultSpriteSize(4, 4);

	for (%y = -%yrange; %y <= %yground; %y++)
	{
		for (%x = -%xrange; %x <= %xrange; %x++)
		{	
			//%o is octave
			for(%o = 0; %o < 8; %o++)
			{
			//just using frequency as a multiplier to distort here.
			//normally frequency would be a fixed value
			%frequency = getRandom(2, %o);
			
			//not including amplitude in this example, 
			//but we would multiply our (%xpos*%frequency) and (%ypos*frequency) by this
			//would prefer this to not be random and be a range from 0.5 - %o ??
			//%amplitude = getRandom(0.5, %o);
			
			%xpos = (%x*%frequency);
			%ypos = (%y*%frequency);
			%newPos = %xpos SPC %ypos;			
			
			//Feel like there should be an if statement here to 
			//determine if %newPos is full before adding.
			
			%map.addSprite(%newPos);
        
			%map.setSpriteImage("Assets:Blocks", 5);
			%position = %map.getSpriteLocalPosition();
			%map.createPolygonBoxCollisionShape(4, 4, %position);
				
			}
		}
	}
	
	%map.BodyType = static;
	worldScene.add(%map);	
}

The 'yground' is just an identifier to say we only want to render up to a certain height within this terrain block. After I got an initial randomized terrain block to actually work, I planned on having the scene be comprised of different terrain blocks set to different elevations. I figured I may end up putting all of this into 'classes' but one step at a time for me atm.

#15 I realized that if I changed the %xrange and %yrange to a much lower value the world will load. The console will still log repeated attempts to place blocks in the same location however.

In any event, while the algorithm can be used to generate noise and manipulate that noise I am not sure it will work for this situation. When I loaded up the world with a smaller range I realized that the farther away from 0,0 the character got the farther spaced apart the blocks were. This obviously won't work, back to square 1 apparently...I'm beginning to wonder if all of this will even be possible using CompositeSprites.

If not, I am not sure how to even approach placing these tiles. In theory, and on paper planning it seems that it should be simple. In application, it is far from it. I am sure that if I tried to place every single tile by logical position, assign it a collision box, and grid out the world it would be very expensive on the system. Even so, I wouldn't know where to begin on setting up an array of tiles to begin with. With the CompositeSprite, the rectilinear layout takes care of all that and also deals with the culling...while still being able to add collision boxes. Each day it seems I take 1 step forward and 2 steps back with this project, and lack of information available on applying TorqueScript is very discouraging. Sure, I can try to reverse engineer pre-made toys but that can only take me so far without real-world examples or guidance. Also there are no toys that map out blocks of tiles for terrain in a grid and randomly generate them.

I see lots of little 'terraria' style engines and games around the web, perhaps Torque 2D is not the best approach for me to use trying to make this game?

#16 After looking through the code base you gave me, I think there is potential to get the system working... It will just take some innovation.

As for creating the tiles, theres a couple options available. You could create a taml base file for most of it which would be less resource intensive, it's just a matter of setup.

I'm not too familiar with Terreria honestly.. But I know the potential of the CompositeSprite system, and I believe it can perform what you're looking for.

This seems a very interesting project you've got rolling. I'm close to polishing up a fix (I've found that you've over extended your loops a bit and your frequency variation is causing a slight hiccup problem)... This is mostly with re-doing the system though.

I think T2D can handle this project, it will just take a bit of work.. and no good project gets completed without effort applied.

Maybe some others would like to chime in here as well.. but I'll help out where I can, I just need a bit better understanding of the game mechanics that need to be implemented.

#17 Thanks for your encouragement. At least this is some reassurance that I may not be on a fool's errand. I am at a crossroads atm, where I think T2D will be able to handle this easily if it were all coded correctly. Here's some key things I'm trying to have:

Terrain blocks that are randomly generated (lowlands, hills, mountains, etc.) As the player travels left-right, basically the 'y' axis varies (up = empty, down = full) so the ground level has some variance.

Each block will need to be able to be removed (dug up by player). So the collision shape needs to be able to be removed, so the player doesn't collide with the block he just dug up.

The player will 'collect' a block he digs up, incrementing an inventory item representing the type of item he dug up. Those gathered blocks can then be placed in the world, decrementing the inventory # for that type of block and creating a collidable block anew.

Fundamentally, those are the most important things that need to happen to even get rolling :) I haven't even begun to get into player behaviors and input to make the player sprite interact with the blocks. I would love to get a proof of concept or prototype that would merely allow the rendering of multiple terrain blocks as a start. I feel a lot could be done with that amount of progress. I've been taking it all a step at a time.

Given that I could actually get a compositeSprite to randomly generate without crashing the game, there are several approaches that could be taken to filling the entire scene. Smaller 'chunks' of blocks, wider 'biome' zones, variance in the amount of blocks depending on height (empty sky, rolling mountains to hills, thick areas of ground full of blocks, some empty and some full in caverns below the surface).

It's all there given the correct math performed on the compositeSprite. That takes some doing, although I feel like I'm getting closer but missing certain details due to my lack of experience with the engine. Thanks a lot for the help Doc, it's definitely welcomed and appreciated. I've been constantly after solutions to these problems, but I guess my skin is getting a little thicker :P

#18 If I understand your posts correctly your process involves populating the compositeSprite with patches of various terrain types and then distorting the patches by moving blocks around semi-randomly. Your trouble is that compositeSprite does not like the way you reassign the blocks.

A simple array variable will not care how you change cell values. What if you create a map in an array variable first, work on it as an array, and only populate the compositeSprite once it is finalized?

That is, do not populate compositSprite and shuffle the sprites. Instead create an array variable the size of your terrain, populate it, distort it, and only then generate compositeSprite. Your compositeSprite filling routine would read the terrain block names from the array and generate the appropriate sprite at the matching address in compositeSprite.

#19 Thanks for your feedback, Michael. As a matter of fact, after more research and further investigation into the CompositeSprite class I have ultimately come to the same conclusion. I hadn't updated the thread here (mainly because I'm actually being somewhat productive) but the project is moving along a bit more smoothly now. I have started to revamp the entire project, making changes to the entire structure of how it handles the CompositeSprite.

This is requiring me to create several functions to manipulate the data accordingly, but it all looks very promising at this point.

Additionally, Doc308 has 'taken me under his wing' so to speak and has been offering extremely insightful input via e-mail. I'm new to the engine and TorqueScript, but beginning to finally wrap my head around how to use it effectively. The community here has proven extremely helpful, and while they can't write the program completely for me usually I am pointed in the right direction at least.

The only current snag I have run into is how the CompositeSprite handles collision on sprites within. I have another thread about this problem here on the boards, but given time when I get this new system in place that problem may not exist.