What's the best way to save memory with images for a mobile game?

In my spare time I am developing an application that will be a collection of 1001 2D games for mobile, which I will make available on Itchi.io. Two of the purposes of the project are to develop expertise in the use of Unity; And build a portfolio (although I've already done some work for companies and institutions but it's not possible to use the projects for nda reasons, even more being game designs).
In fact, this project should contribute a lot for me to develop better game designs for future programming teams that I will work with in the future.
I'm game design, my programming knowledge is extremely basic. I would like some veteran in the area of programming with Unity to evaluate my solution to the problem that I will present and, if possible, give me some guidance on the matter.
The point is that, as it is a mobile project, there is a great concern regarding the game's memory and its processing in the game's action. It is not possible for each of the 1001 games to have a distinct set of images (sprites). I will only have to use a single set of images to build all 1001 games.
As the idea is to develop all the games myself, as part of the Unity learning and compression process and developing some gamedesign skills, I will only use geometric shapes to build the objects, both the setting and the characters. This makes it a lot easier, because I'm not a designer and animator either. But I intend to develop simple animations.
In my ignorance, I looked for solutions to this memory issue, which would make it viable to develop this collection of 1001 games for mobile.
The most efficient solution I could think of was to develop all the drawings through programming, that way, there would be no image assets (sprites) in the project, only scripts, which I believe require less of a device's local memory (I don't want to use data through the cloud, this is another design limitation). Furthermore, the game action would only process what would be visible on the camera, which would greatly reduce the issue of game action processing and loading processes. — I could be perfectly wrong because of my inexperience in programming. — However, this solution is not possible with the level of programming understanding I currently have. Maybe in 2 years I will be able to put this solution into practice, but I would like to know if this assumption makes sense and if it really would be the best option for the case.
Studying some tutorials on Unity, I elaborated another possible solution, which I could develop, even with a certain level of difficulty. I came up with the following solution:
I must create a tilemap and a palette with the geometric shapes to use in all games, this way I can also use the "2D composite collider" technology to save on collider processing.
So I will create both the scenery and the characters of the games through this palette using the geometric shapes. But there is a problem in relation to the simple animations that I intend to make the characters, I believe that there is no way to animate them, nor to have an animation control, of these characters using tilemaps. This would be a problem that would have to be solved by creating a scriptable capable of collecting the drawings of each frame of the animation to animate it and also controlling the animations through the character's states (idle, walk, jumping...).
I would like to know if this is really a good solution to solve the device memory and game action processing problem.
— In addition, I'm also interested in any way (except using the cloud) to save memory and processing in other areas of the game: audio, programming...
Any contribution to reduce memory and processing usage to make this 1001 games collection project possible, I would be extremely grateful! — I think I should credit the game with a thank you to the Unity community and list all the names of those who were able to bring me a light of knowledge and understanding.
Note: I'm Brazilian and I'm still not very good at English, I hope my text can be at least reasonably understandable.

 

* Have you ACTUALLY run into a problem with storage not being large enough? Modern smartphones are not weak.
* Are you sure you want to make a 1001 games? Because that's a lot. Even if you were doing ludum dare every day, it would take years, and it is not possible to maintain tempo of ludum dare for long - you'll simply tire yourself out and burn out.

 

With that, it will most likely take few months, before you will get any first game in playable state.
Depending on motivation and available time.

I would strongly suggest try to make one game at least, first, before even thinking making another one.
Start with that.
Not to mention 1001!

By the time you will make first, second, third ... game, you will understand, what it will take to make and maintain them. Specially on the mobile.

 

Yes, the best idea would be to make a single one game, without worrying about storage concerns. Just finish it.

1001 games make me think about nes cartridges and doesn't sound like something you could realistically do by yourself.

 

I think you're doing preemptive optimization, which to a degree is as bad as not optimizing at all. Planning ahead is an important skill when it comes to any project (regardless of whether it's a Unity game or more "real-life" things) but it's important to differentiate between roadmapping and trying to fix things that don't yet exist. I have a feeling that you might be coming from a background where you need to account for mistakes/inefficiencies early on, but thankfully in Unity you could change things pretty easily if something is not up to your expectations.

1001 game sounds like a lot. Are you sure that it's a task that you really want to accomplish? If you're trying to make an homage to the shovelware bundles of yesteryear, those used to copy games interchangeably, where some assets from Game 1 could appear in Game 20. Most of the times, there would be 30 to 50 original games at most (with plenty of bootlegs/outright stolen games).

If you've set such a goal for yourself due to some other reason, may i ask you...why? Are you absolutely sure that making 1001 minigames is the best idea that you have for a project? I'm sure that you have far superior ideas for games that don't involve spending at least a year (given that you make 3-5 games a day, and that's without testing).

If the goal is strictly financial, the shovelware bundles are not as big as they used to be.

Ramblings aside, the solution for you is to use the assets interchangeably, compress as much as you can (as long as the quality does not go down), design for low sprite data size, use low resolutions, optimize the spritesheets. Creating images through code, while possible, is not going to provide as good of a result compared to just re-using sprites (at least at this point in time).

Make 10-20 high-quality minigames instead. 10 Unity 2D and 10 Unity 3D. This is going to give you an understanding of how Unity works. If you have a project in mind (other than 1001 game) then get to working on it (as long as it's not a "i want everything in my game with best graphics, million player count multiplayer on one server and cool sounds!!!" and is something that a single developer is capable of finishing). This is going to be far more helpful to you. Think about this: with each quality minigame, your portfolio is going to expand. With each minigame you make for your 1001 minigame project, your portfolio remains the same, as those minigames are essentially games within a project, not games on their own and only after you finish all of them you're going to have 1 finished project rather than 20.
Or better yet: make 5 Unity 2D games, make 5 Unity 3D games and afterwards, after you got a gist of things, start working on something far more focused than a 1001 game project.

 

The idea is really long term, the collection will be released with 10 games and I will continue the project until I complete 1001 games, even if it takes 5 years. It's a game design challenge that I set for myself, the more games in the collection, the bigger the limitations and I'll have to be more creative.

 

Thank you so much for your answer. I liked very much.

This project will be done in extremely spare time.

Currently, I'm putting aside the demands of customers (whether a company or an individual).

I'm working on the development of two games for the still unknown team I'm part of. One of the games will be for mobile (launch on itch.io and soon after on Google Play Store); And the other will be released on Steam soon, just a few tweaks to the game's levels are missing.

Our team is made up of just 2 people, 1 programmer and 1 game designer.

These games will be our team's launch into the indie development universe. We are still developing the visual identity of the studio.

My main time is invested in these projects. Then I invest my time in other digital income sources. And finally, I reserve my time for the 1001 games project.

This project, in addition to the goals I have said before, is a personal challenge, here in Brazil, a few years ago a MiniGame was very popular that claimed to have 1001 games, but it didn't have all that. The idea for this project came from that.

It's an absurd challenge. I know. Still, it's something I want to do, as long as it's not my main activity/source of income.

 

Before trying to make 1001 games, consider just what kind of quality each of these is going to have. The old unlicensed NES game "Action 52" should be required study material for you, and that had "only" 52 games.

AVGN had a pretty savage yet accurate take on it, if you like that sense of humor.

 

offload assets into asset bundles, only load the asset bundle associated with the target "game" when its needed, unload when its finished being used. Store asset bundles either on disk, or remotely using something like AWS S3 buckets etc. Assetbundles can be downloaded remotely or from disk using a webrequest, which are optimized for asset bundles.

https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequestAssetBundle.html

Good luck

 

You need to consider that releasing 1001 games can take not 5 but 50 years. Or more. A reasonable timeframe for a tiny polished game is around a month, but even that can be called too short by many. 1001 months is 83 years.

I'd recommend to look at the "Last Call BBS" by zachtronics. Those guys are making puzzles, and decided to release all their prototypes as one last game collection before they close their studio. They do not have a 1000 titles there. They were in business for at least a decade.

 

I'm relieved to hear that, as after re-reading my post, i feel like my response came off as a little abrasive.

Take it as an advice from a random person on the Internet: develop your visual identity after you finish your first project. The lessons that you're going to learn during the development as well as the projects artstyle, assets and much more, could help you to s y n e r g i z e the style of your product with your companys visual identity.

I can't deter you from attempting to accomplish that, as that's your time and effort that you're spending, but i would HIGHLY recommend against going that route. Still, if you're serious about it, then good luck! But before you're going to start working on your megaproject, i'd like you to ask you to do something (again, you are not under any obligation to take advices from random people on the net, but still): as i'm sure you have game ideas other than the 1001 project, take those ideas, put them on paper and compare how much effort you need to finish those projects (that includes time and money spent) to the actual result that you're expecting. Basically, imagine both the 1001 megaproject and any of your other game ideas side by side, finished, and try predicting what would be a better route for you.

 

Over time, developing games for other people, I've learned that constructive criticism is more valuable for growth than praise, not that it's bad.

Your reviews were good for seeing my ideas in a more mature and realistic way.

I will follow your advice to buy the 1001 games project with other projects I have in mind.

Something interesting came to my mind when I read your latest contribution. I ended up remembering an old book I read when I was about 16 years old, which explained management theories, both general and specific. And I don't know why I ended up remembering specifically the production method developed by Ford, to produce cars on a large scale.

It is likely that I still follow the idea of the project but now I want to follow it in an extremely fragmented way and with even less pretension. And along the way, create shortcuts in drawings, programming and music, that allow me to reuse much of what already exists to create new gaming experiences.

 

Don't do that.
You won't get much of it, you will struggle understand someone's code, specially that you never wrote any game before. You will waste more time understanding the code, or even project structure, than writing it your self. Plus you will waste your money for nothing.

You much better is to find mini project on youtube and github. Not that it will help you.
Or at least will help you to understand, what you really don't know.

Did you even tried to complete any of tutorials?
Have you ever heard about feature creep? Same applies to your 1000+ games goal.

 

Uhh, this is not exactly what my advice was... My advice was to compare your 1001 project with your other projects that you might have in concepts and decide for yourself what is better for you.

This is an interesting approach, considering that automotive manufacturing is limited by the availability of resources, while creative jobs aren't. Don't feel obliged to follow everything those books say though.

Now that's a more "optimized" approach to the 1001 project. If you are on your path of optimizing your approach, may i also suggest picking a lesser number? There are some great numbers out there that are widely associated with gaming: 8/16/32 (in relation to bits). Perhaps 8 games made in 8-bit style would be a great starter?

 

I wanted to say "compare with my projects I have in mind" but I ended up writing "buy".

I'm using an online dictionary to talk to you, "compare" in Portuguese is a little similar to "buy" in Portuguese. lol!

Sorry for the mistake.

 

I wanted to say "compare with my projects I have in mind" but I ended up writing "buy".

I'm using an online dictionary to talk to you, "compare" in Portuguese is a little similar to "buy" in Portuguese. lol!

Sorry for the mistake.

Yes, the suggestions you proposed are interesting.

I think I can produce these 8 simple games, publish Itch.io, and go little by little without a routine production obligation, increasing the game collection, until I reach these 1001 games. So those 1001 games wouldn't be a promise but just a production limit that I've determined this collection will have.

I think it's healthier to think in this more realistic and flexible way. Thanks for the advice, it was very helpful.

Developing this collection of minigames will be more of a hobby and a challenge to try to be more and more creative with the limitations I imposed for this project.

Now a few questions, referring to your first advice:

1. What are "assets interchangeably", does it have to do with "assembles"? - To study this subject, should I research assembles?

2. When you said that I should "compress as much as I can (as long as the quality doesn't decrease)", are you referring to the format and size of the sprites? (If you have tutorials on the subject, I would like to study everything you have. Or if you have keywords that can help me do a more assertive research on the subject.

3. "use low resolutions, optimize spritesheets" — The lowest resolution game sprites I know of would be 8x8, but is it possible to use lower resolutions still? In the case of low resolutions is it necessary to increase the DPI from 72 to 96 or more?

That's it!

I'll start doing some resolution tests to see how far it can go, I'll also seek guidance from some game development colleagues who work with drawing and animations to get more on the subject. For sure, these conversations and experiences that I'm having now will help me become a better game design and more aware of the work developed by other areas. Mainly programming.

I am deeply grateful for the advice and attention you have given to my case.

Thank you very much!

 

well whether you plan to make 1 game or a billion you can only make one at a time.

 

Wow, i would never know that! No worries, given enough time, i'm sure you're going to be able to speak and write as fluent as you are in Portugese.

Again, you're welcome. I'm glad that i managed to provide a bit more realistic perspective to you as more often than not enthusiastic developers tend to overestimate their capabilities. This is not a bad thing and is often a sign of someone who loves their craft, but many become discouraged when things go wrong.

No. What i meant under "interchangeable use" was (for example) using the same sprite for different purposes. Think Super Mario Bros.:

I'm referring to several things: the format (PNG/JPG/other options), the size (which can have drastic decrease if a correct format is used), how much data the file carries regardless of the format (for example, an image that is a solid square of colour that has a resolution of 1024x1024 and is in PNG format is going to have a lesser filesize than an image of a colorful bush in front of an old TV-set that showcases white noise with the same resolution (1024x1024) and format (PNG) and the way the image is stored in Unity (is it a part of a spritesheet?). Basically, i should have said "optimize" instead of "compress", sorry.
Yes, i do have keywords and i have topics for you to research: image data, image file formats, sprite data, image compression. Those are all related to the process of "optimizing" your sprites (which are image files).

Depending on what result are you trying to achieve. Speaking of 8x8, i think that this might interest you: https://blog.unity.com/technology/2...-up-your-unity-project-for-retro-8-bits-games

Don't hesitate to visit the forum, ask questions and seek advice. If you have a problem with your project that you can't quite overcome and you made all the effort that you could to resolve it (or perhaps you have issues with setting up for the project (understanding what you need to use, what components you might need)) – ask away, but remember to be verbose about the issue that you're facing and provide as much information in your post as possible.

I'm glad that i could be of help! I understand that language barrier might be an issue, but while we're on topic on optimizing your project, check these out:

Again, it is important to understand these things, but don't get caught in the trap of optimizing things before you actually have anything to optimize.

 

Ok. For now it's just to stay on top of the subject.

 

Sorry to add, but have you considered not to use images at all, just material with colours, wouldn't that be the ultimate saving?