# Unity To use tiles or pre rendered images for game graphics

This topic is 668 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok this is kind of an odd request for advice but I had great success in using this community last time I needed some help so here I am again.  I'm working on my platformer style game for my indie company and I'm at the point now where I'm trying to figure out how I want to handle the actual levels for the game.  I'm really getting hung up on this and have no other programmers to talk this through so I'm hoping to talk this out with you lovely people.  So the game is going to use parallax scrolling to give depth to the actual level, it is going to be a side scroller and the player controls the main character in the game.  In the level there will be buildings the player can go in and out of as well as points on each level that will allow the player to move between other levels for that specific map.  Its a city street grid if you are wondering.  The thing that I'm running into is trying to figure out what the best way to display the the levels, do I use tiles to build each layer of the level and scroll those or do I use pre rendered images scrolled on top of each other.

I know that this is ultimately my decision and I should be the one to make it but I am hoping to get people's thoughts on the topic, to talk it through online and this will hopefully help me make a final decision.

##### Share on other sites

The thing that I'm running into is trying to figure out what the best way to display the the levels, do I use tiles to build each layer of the level and scroll those or do I use pre rendered images scrolled on top of each other.

Why not both?

Tiles, repeated backdrops, and freely placed images over those backdrops and tiles.

##### Share on other sites

This is why I love this community I get quick and quality responses.  So lets explore this idea of how I would do it that way then my levels will consist of a backdrop layer we will call it layer 0 that will be like a distant city skyline, layer 1 will be a cloud layer, this layer will scroll on its own without the player movement.  Layer 2 is the actual buildings of the level that layer will move at the same speed as the player if that makes sense with layer 0 and 1 moving at different speeds to give the parallax scrolling effect I'm looking for.  The player and other stuff will get rendered on top of layer 2.  I guess yeah that would probably work I could use tiles for Layer 2 which would allow me to use various tile values as trigger points to distinguish what spots are doors to buildings.  Hmm.... I will have to explore this and try it.

##### Share on other sites

In my own game - which is a 2D overhead RPG - I have multiple different layer types, and each layer type can go into any position.

However, you might not need that flexibility/complexity. Instead, I'd start with something like this and tweak it as I go:

//Pseudocode:
struct World
{
Array<Layer> layers;
};

struct Layer
{
Backdrop backdrop; //Drawn first.
Tilemap tilemap; //Drawn second. Can collide with.
Array<Decal> decals; //Draw third.

Array<Entity> activeEntities;

//This controls player-movement-related scrolling. i.e. you multiply this against the player's position to get the layer's scroll position.
//For example, you may want a layer FIXED to the viewpoint with NO scrolling no matter how much the player moves. Like sun rays.
Vector2f parallax;
};

//What I call a large repeating image that scrolls, and can be UNDER (i.e. background) or OVER (i.e. foreground) a player
struct Backdrop
{
ImageID appearance;

//This is the scrolling that occurs automatically, without the player moving. Things like clouds or mist.
Vector2f scrollSpeed;
};

//What I call a freely-placed, freely-rotated, freely-scaled image
struct Decal
{
Position position;
float scale;
float rotation;
ImageID appearance;
};

struct Tile
{
Shape collisionShape;
ImageID appearance;
};

struct Tilemap
{
Grid<Tile> tiles; //Note: Breakable/interactive tiles are entities pretending to be tiles, as are invisible triggers, movable doors, and so on.
};

[b][Edit:][/b] Forgot to include the Backdrop definition.

Edited by Servant of the Lord

##### Share on other sites

I just might have to use that in my project I like that idea for this usage.

Thank you.

##### Share on other sites

From your description, it seems only your "layer 2", the buildings that the player interacts with, has a good reason to be an actual tile map (subdivided into a grid, with specific tile edges having a role in the game as triggers or impassable walls); the decorative graphics in the background could use tile-based assets (buildings with a regular structure in particular), but they can, just as easily, contain independent and independently moving sprites (e.g. many separate clouds, each with its own velocity and animation, rather than a rigid cloud layer; or moving cars and people among the fixed background buildings).

##### Share on other sites

In my own game - which is a 2D overhead RPG - I have multiple different layer types, and each layer type can go into any position.

However, you might not need that flexibility/complexity. Instead, I'd start with something like this and tweak it as I go:

//Pseudocode:
struct World
{
Array<Layer> layers;
};

struct Layer
{
Backdrop backdrop; //Drawn first.
Tilemap tilemap; //Drawn second. Can collide with.
Array<Decal> decals; //Draw third.

Array<Entity> activeEntities;

//This controls player-movement-related scrolling. i.e. you multiply this against the player's position to get the layer's scroll position.
//For example, you may want a layer FIXED to the viewpoint with NO scrolling no matter how much the player moves. Like sun rays.
Vector2f parallax;
};

//What I call a large repeating image that scrolls, and can be UNDER (i.e. background) or OVER (i.e. foreground) a player
struct Backdrop
{
ImageID appearance;

//This is the scrolling that occurs automatically, without the player moving. Things like clouds or mist.
Vector2f scrollSpeed;
};

//What I call a freely-placed, freely-rotated, freely-scaled image
struct Decal
{
Position position;
float scale;
float rotation;
ImageID appearance;
};

struct Tile
{
Shape collisionShape;
ImageID appearance;
};

struct Tilemap
{
Grid<Tile> tiles; //Note: Breakable/interactive tiles are entities pretending to be tiles, as are invisible triggers, movable doors, and so on.
};

[Edit:] Forgot to include the Backdrop definition.

Why use structs and not a class?

##### Share on other sites

In my own game - which is a 2D overhead RPG - I have multiple different layer types, and each layer type can go into any position.

However, you might not need that flexibility/complexity. Instead, I'd start with something like this and tweak it as I go:

//Pseudocode:
struct World
{
Array<Layer> layers;
};

struct Layer
{
Backdrop backdrop; //Drawn first.
Tilemap tilemap; //Drawn second. Can collide with.
Array<Decal> decals; //Draw third.

Array<Entity> activeEntities;

//This controls player-movement-related scrolling. i.e. you multiply this against the player's position to get the layer's scroll position.
//For example, you may want a layer FIXED to the viewpoint with NO scrolling no matter how much the player moves. Like sun rays.
Vector2f parallax;
};

//What I call a large repeating image that scrolls, and can be UNDER (i.e. background) or OVER (i.e. foreground) a player
struct Backdrop
{
ImageID appearance;

//This is the scrolling that occurs automatically, without the player moving. Things like clouds or mist.
Vector2f scrollSpeed;
};

//What I call a freely-placed, freely-rotated, freely-scaled image
struct Decal
{
Position position;
float scale;
float rotation;
ImageID appearance;
};

struct Tile
{
Shape collisionShape;
ImageID appearance;
};

struct Tilemap
{
Grid<Tile> tiles; //Note: Breakable/interactive tiles are entities pretending to be tiles, as are invisible triggers, movable doors, and so on.
};

[Edit:] Forgot to include the Backdrop definition.

Why use structs and not a class?

These seems to be just data structures - so structs are the best way to define those. No need for classes which is great ;-)

##### Share on other sites

Why use structs and not a class?

Since classes and structs (in C++) are basically identical (except whether they are private or public by default), it seems to be pretty common to use structs for bundles of data, and classes when you're bundling logic with data.

In actual code, I'd make World a class, and probably Layer and Entity as well. But the others, being (mostly) static blocks of data, I'd probably leave as structs.

But mostly I was just giving a pseudo-code example of how he can layout the data, so I didn't put much thought into it.

##### Share on other sites

Why use structs and not a class?

Since classes and structs (in C++) are basically identical (except whether they are private or public by default), it seems to be pretty common to use structs for bundles of data, and classes when you're bundling logic with data.

In actual code, I'd make World a class, and probably Layer and Entity as well. But the others, being (mostly) static blocks of data, I'd probably leave as structs.

But mostly I was just giving a pseudo-code example of how he can layout the data, so I didn't put much thought into it.

I never got the point of structs. I mean, it's literally just like a class, except it can't do anything (by which I mean have methods, as far as I'm aware). What's the point of that? What can it be used for?

Edited by Ovicior

##### Share on other sites

I never got the point of structs. I mean, it's literally just like a class, except it can't do anything.

It's exactly like a class. When you say, "it can't do anything", what particularly can structs not do? it can do everything a class can do (constructors, destructors, operators, functions, inheritance, etc...). It's exactly the same thing - two different keywords for identical purposes.

(Note: because C++ likes to repurpose keywords for unrelated purposes, 'class' is also an unrelated keyword for template arguments, and is interchangeable with 'typename' - but that's unrelated to the regular usage of the 'class' keyword)

'C' had 'struct'. C++ wanted the idea of object-orientedness, and added the 'class' keyword for basically no purpose except to underline the OOP-ness. It could've just as easily kept using the 'struct' keyword and C++ would be 100% the same, or could've easily gotten rid of the 'struct' keyword and only used 'class' for everything. The only reason it didn't get rid of the 'struct' keyword was for backwards compatability, and the only reason they added the 'class' keyword was... to be hip?

I'm trying to underline that they are the same and so am being slightly facetious, but you can read Bjarne's own reasoning (at least somewhat). Essentially, though, it's just a quirk in C++'s design that there are two separate keywords.

Here's some example code showing that they have the same features:

#include <iostream>

struct MyStructBase
{
int var = 0;

//Structs can have member functions.
void MemberFunction()
{
std::cout << "var = " << var << std::endl;
}

//Structs can have virtual functions (even pure virtual).
virtual void SetSomething(int x) = 0;
};

//Classes can inherit from structs (because structs are classes - they're the same).
class InheritsFromStruct : public MyStructBase
{
public:
void SetSomething(int x) override { this->var = x; }
};

//Structs can inherit from classes (because classes are structs - they're the same)
struct InheritsFromClass : public InheritsFromStruct
{
//Structs can have constructors and destructors.
InheritsFromClass(int value)
{
//Structs can do polymorphism just like classes (because it's two keywords for same feature)
InheritsFromStruct &polymorphism = *this;
polymorphism.SetSomething(value);
}

//...stuff...
};

int main()
{
InheritsFromClass myStruct(357);
myStruct.MemberFunction();

return 0;
}


What's the point of that? What can it be used for?

Well, since structs and classes are exactly the same (except for the aforementioned defaulting to public vs private, and the default access for structs/classes you inherit from - which is arguably an inconsequential and unnecessary difference), they can be used for exactly the same purposes. Two reserved keywords for the exact same functionality.

So, since they are the same thing, C++ programmers have generally decided to give them conceptual differences: structs for collections of data without logic, and classes for logic bundled with data, or just logic (or just interfaces without logic, or etc...). It's a "how we code" difference, rather than a difference in C++ code.

When you want an integer, do you do "int" or "signed int"? They both mean the same. You can also say, "signed long int", "long int", or just "long".

When you want an unsigned integer, do you do "unsigned" or "unsigned int"? They both mean the same.

(alright, so on some architectures "int" and "long int" may be different sizes, but on many systems they'd be the same)

Different people come up with their own coding styles and guidelines, and the C++ community in general has come to some consensus on some of it.

For bonus points:

auto signed long int myInt; //Usage of 'auto' prior to C++11. This usage of auto has now been either removed or deprecated.

Alot of older C++ features are so underused, some of them could be removed. Personally, I never liked the whole signed/unsigned/long system, and think C++ should standardize around the int32_t and friends, though I use 'int' and 'unsigned' when I don't care about the size.

##### Share on other sites

I never got the point of structs. I mean, it's literally just like a class, except it can't do anything.

It's exactly like a class. I don't understand what you mean that "it can't do anything"... it can do everything a class can do (constructors, destructors, operators, functions, inheritance, etc...). It's exactly the same thing - two different keywords for identical purposes.

'C' had 'struct'. C++ wanted the idea of object-orientedness, and added the 'class' keyword for basically no purpose except to underline the OOP-ness. It could've just as easily kept using the 'struct' keyword and C++ would be 100% the same, or could've easily gotten rid of the 'struct' keyword and only used 'class' for everything. The only reason it didn't get rid of the 'struct' keyword was for backwards compatability, and the only reason they added the 'class' keyword was... to be hip?

(I'm trying to underline that they are the same and so am being slightly facetious, but you can read Bjarne's own reasoning (at least somewhat))

Here's some example code showing that they have the same features:

#include <iostream>

struct MyStructBase
{
int var = 0;

//Structs can have member functions.
void MemberFunction()
{
std::cout << "var = " << var << std::endl;
}

//Structs can have virtual functions (even pure virtual).
virtual void SetSomething(int x) = 0;
};

//Classes can inherit from structs (because structs are classes - they're the same).
class InheritsFromStruct : public MyStructBase
{
public:
void SetSomething(int x) override { this->var = x; }
};

//Structs can inherit from classes (because classes are structs - they're the same)
struct InheritsFromClass : public InheritsFromStruct
{
//Structs can have constructors and destructors.
InheritsFromClass(int value)
{
//Structs can do polymorphism just like classes (because it's two keywords for same feature)
InheritsFromStruct &polymorphism = *this;
polymorphism.SetSomething(value);
}

//...stuff...
};

int main()
{
InheritsFromClass myStruct(357);
myStruct.MemberFunction();

return 0;
}


What's the point of that? What can it be used for?

Well, since structs and classes are exactly the same (except for the aforementioned defaulting to public vs private, and the default access for structs/classes you inherit from - which is arguably an inconsequential and unnecessary difference), they can be used for exactly the same purposes. Two reserved keywords for the exact same functionality.

So, since they are the same thing, C++ programmers have generally decided to give them conceptual differences: structs for collections of data without logic, and classes for logic bundled with data, or just logic (or just interfaces without logic, or etc...). It's a "how we code" difference, rather than a difference in C++ code.

When you want an integer, do you do "int" or "signed int"? They both mean the same. You can also say, "signed long int", "long int", or just "long".

When you want an unsigned integer, do you do "unsigned" or "unsigned int"? They both mean the same.

(alright, so on some architectures "int" and "long int" may be different sizes, but on many systems they'd be the same)

Different people come up with their own coding styles and guidelines, and the C++ community in general has come to some consensus on some of it.

By saying they can't do anything, I meant that they couldn't use methods. Seems I was wrong.

##### Share on other sites

Yea, it's just by habit and from coding style, programmers have mostly standardized on not giving structs functions to communicate intent.

I still occasionally give them functions, most often just constructors, but occasionally something more.

##### Share on other sites

So much great information I have learned from this thread I am going to take the various advice and put it to good use.  Hopefully in the next month my company will have our first demo of the game ready to show to potential investors and to the world in general.

##### Share on other sites

Hey another question related to this same topic I'm trying to decide how I want to store the data related to my levels do I simply use text files, do I use XML or do I use lua?  One big thing that is making it tough to decide is I am not sure what is supported on the XBOX One and with plans to release the game on there I was wondering if anybody has any insight into what is supported?  I only ask because I can't find any documentation because I'm not a registered developer yet with Microsoft.  So any insight into the topic would be appreciated.

I'm so far leaning towards either using text files to initialize the levels and maps of the game, or XML or I guess the other option is do hard code the texture file names and tile atlas/ sprite sheet data into the game?  I realize this is something I need to decide but again just looking for people to help me talk this out lol.

##### Share on other sites

Hey another question related to this same topic I'm trying to decide how I want to store the data related to my levels do I simply use text files, do I use XML or do I use lua?

Whichever makes the most sense for your project.

Personally, I'd use human-readable text files (which includes XML and Lua, and other things like JSON and YAML) and, if necessary, have your editor produce both the human-readable files, and produce optimized binary files for your project's actual releases. However, this most likely isn't needed for your current project.

One big thing that is making it tough to decide is I am not sure what is supported on the XBOX One

Doesn't matter. Focus on PC first (focus on whichever OS you use), and you'll be able to adapt it to XBox One once you do get that information. Your effort won't be wasted. If this is your first project, you should really focus on getting your project finished and running on your development machine before you worry about the "what if's" of console development.

I'm so far leaning towards either using text files to initialize the levels and maps of the game, or XML

XML is text files, as is JSON and YAML and many others. Lua also, unless you pre-compile the scripts, is text.

I think what you mean is, "I'm leaning towards making my own format, or using a pre-existing format".

I personally don't like XML, because I think it gets overused for situations that don't make sense and where XML is weak at, but many developers will tell you that they happily use XML.

Personally, I'd look at JSON first, and I'd suggest that to you (despite not using it myself! ) because it seems like it'd fit your map data better. However, look at examples of several different human-readable

I guess the other option is do hard code the texture file names and tile atlas/ sprite sheet data into the game?

Unless you have less than, say, 50 sprites, this is not a good idea.

##### Share on other sites

Hmm OK I see what you are saying and yes I do mean making my own format, I was just trying to decide if that was really a path I should follow or not.  As far as focusing on primary that is good advice.  I just always keep the fact that I want to release on console in the back of my mind when I'm planning on various systems for my game.  I just don't want to get to the end of something and find out that in order to make it work on a console that I have to completely rework a large chunk of code.  To be honest I was mainly leaning towards just putting everything into .txt files, texture names, the map data for parts where I use it and other stuff like that.  But when I started looking into the various tile map editors out there I keep running into the option to export to CSV, XML or lua.  That got me to thinking well which one was a better option.  I know how to work with CSV files and already have code for handling them and pulling the data out but I started to question which way is faster.  But after reading your thoughts on my question I seem to be heading in the right direction.  Now to actually get a map displaying on the screen....

##### Share on other sites

By saying they can't do anything, I meant that they couldn't use methods. Seems I was wrong.

As an aside:

It's always (at least since proper C++, not sure if pre-standard C-with-classes was different) been the case that structs and classes were identical except for their default access specifier and their default inheritance (when you derive from a struct and don't specify public inheritance is assumed, but for classes private inheritance is assumed). Looking at it from this light, its plain to see that 'class' as a keyword was invented strictly as a way to promote default private accessibility and inheritence since the default behavior of the 'struct' keyword could not be modified without breaking backwards compatibility with C; the same could have been achieved simply by saying "you need to start a private specifier block to keep things private" or by not having blocks but requiring the private keyword to appear on each declaration as other languages have done. Bjarne, probably rightly, rejected those options as putting excess keystrokes between the programmer and best-practices, programmers being lazy and all (and also, computers were small back then, and the size of source code files was a legitimate concern).

Of course, the irony for myself and many people is that 'public:' is almost always the very first thing I type into my class declaration since I prefer public members to appear first, starting with constructors -- I usually only put private typedefs and the like in that initial private scope.

[addendum] And if that's news, you might also be surprised that unions probably aren't as limited as you thought either -- they can have constructors and member functions, and even have class types as members since C++11. They can't inherit or be inherited, can't have static member variables (but can have static member functions as long as the union has a name), and can't hold references (I'm not actually sure why this needs to be prohibited, and I think it should be allowed with the additional requirement that this would require the union to have a constructor that sets them). I find that not a lot of people know that.

Edited by Ravyne

##### Share on other sites

This topic is 668 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628645
• Total Posts
2984015
• ### Similar Content

• hey guys i hope you doing all well. last night i released my first game in google app store, i really appreciate you guys  to download it. and share your reviews about it
the idea of game comes from mini hackgame of Bioshock.
many thanks

• Who We Are
We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! Currently, we're progressing very quickly with our first project and there are plenty of opportunities and work for new interested programmers. With this project, our development platform is Unity 5.5.2 and C# as our behavioral language. Since this project is our first release, the game itself is a smaller project though progress is moving quickly. We are looking to finalize the current project and get started on future projects in the near future and are expanding our team to do so.

Who We Are Looking For:
Programmer Level Designer
Ours is the tale of two siblings, thrown into a world of chaos. Living in the shadow of their parents' heroic deeds and their Uncle's colorful military career, Finn and Atia are about to become the next force to shape our world. How will you rise through the ranks of Hereilla and what will be your legacy? Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.

Previous Work by Team
Although we are working towards our first game as Forged Interactive, our team members themselves have worked on titles including and not limited to:
Final Fantasy Kingsglaive FIFA 2017 Xcom 2 Civilization
What do we expect?
Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques

What can we offer?
Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.

Contact
If you are interested in knowing more or joining, please email or PM us on Skype. A member of our management team will reply to you within 48 hours.

E-mail: Recruitment@ForgedInteractive.com
Skype: ForgedInteractive

Regards,
David, Colin and Joseph

Reddit: www.reddit.com/user/Forged_Interactive

• By dell96
I'm trying to make my first project but I'm stuck i don't know how to make my crate to start to spawn again when i hit the start button after i die.
hoping someone can help!!!
Crate.cs
CrateSpawn.cs
Cratework.cs
GameController.cs
GameManager.cs

• 9
• 9
• 10
• 21
• 20