My guess 100% accurate prediction for XCOM 2: [spoiler]233 571 copies in 3 months. Probably way too low but I'm gonna stick with it cause it's so accurate it must be good.[/spoiler]

dislekcia;39233" said:

For what it's worth, IMVU have been relentlessly spamming these boards for months. You just don't see it because it triggers the spam system.
I'm not inclined to work with people that spam advertise, personally. But if I wanted to find out the business impact of all this, I'd want to know numbers:
-Players of third-party games inside IMVU, how many people play, how many people pay, what do they pay.
-Earnings of top, median and bottom earners using this stuff.
-Do they pay to SA? They mentioned a whole bunch of systems that don't, and only Paypal that does.
-How much IMVU is going to pay to be part of my games.
If anyone here is a dedicated IMVU user that would love to make something for the system, this is your chance.
I'm curious to hear if anyone is interested in this and, if they are, why.

All of this was pretty much answered at the talk they gave on the 13th, which I think was pretty valuable*. We're Skyping with Nate when they get back to the states to ask more questions. I think it's a good opportunity to take a game that isn't doing well elsewhere, fit it with their api and then earn an extra stream of cash to help fund further projects.
*I'm not going to put the numbers here because I didn't write them down and don't want to misrepresent information.

So I was inspired by @Squidcor's post, but was putting it off cause I wanted to write up something. I haven't really had the necessary time, so I'm just gonna post this and if I find the time later I'll combine them then.
I worked on a lot fewer games in 2015 than the previous year. This was mostly due to more of my work focus being on other projects, and it's not an insignificant amount of work considering most of these are solo projects, but nonetheless, I'd like to increase the number significantly in 2016 again. I've listed them more or less in reverse chronological order (most recent first) and added links (favouring MGSA threads if they exist):
Streamline

Luminare

Polygenics

Symmetric Torpedo

Boom Blade Battle Brigade

(this was technically mostly done in 2014, but it was late in Dec and the LD judging results only came out in 2015 so I'm gonna count it)
Imgur album: http://imgur.com/a/hW4fX

Thanks for the feedback guys.
@pieter: Good idea with the tweening. At the moment ALL moves take about 0.2 seconds to tween, which means that although I do some of the stuff you suggest (but not all), it generally happens so quickly you can't see it. I think a better solution would be to make them generally much slower, but speed them up quickly if you start giving more input. I'll need to improve the tweening system a bit to handle that (it can't easily change tweens while they're running now), but it's on the todo list for the next version or the one after :)
So the Ludum Dare judging results came out this morning. I'm pretty happy with my 4th place for fun and 8th place overall. You can see my results on my LD page here: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=23363
I'm busy working on the next version with a some new mechanics, a bunch of new levels, and new graphics. I should have it out within the next week or so :)

Jetstream is an elegant puzzle game where you soar amongst the clouds. Play through dozens of sculpted levels as you travel around the globe.


Steam: https://store.steampowered.com/app/738860/Jetstream/
Website: http://jetstreamgame.com/

Jump ahead to the first post about Jetstream: http://makegamessa.com/discussion/comment/47931/#Comment_47931
-----
Previous OP from 15 Jan 2016:

Grow your line to reach the goal. There are 24 puzzles and a few different mechanics get introduced along the way.

Latest (post-jam) version: http://francoisvn.itch.io/streamline
Ludum Dare entry: http://ludumdare.com/compo/ludum-dare-34/?action=preview&uid=23363
I made it for Ludum Dare 34 this past weekend. I had the core mechanic down in the first few hours after starting to code, and then I spent the rest of the time iterating and polishing. I'm quite happy with how it turned out, but I'm still itching to add a myriad of little improvements.
If I get some time, some things I'd want to add include: more levels, more mechanics, and a procedural infinite mode.
I'd be keen to hear what everyone thinks. Did you figure out how to play easily enough? How was the difficulty curve? General impressions?

It's great to have your own thread for feedback, but it's also great to have all the LD games in one thread.
Drop your games into the thread below!
I'll add to the list as we go:
Ludum Dare 34 Games
Flow Tactics

BOOST

Harmony Bloom


Streamline

Notwell

Concrete Jungle

Prison Architect is about to exit Early Access (on October 6)... I really don't know how much of a bump it's going to receive...
I'd guess a 20% bump on it's current sales of 1,395,176 (according to Steam Spy http://steamspy.com/app/233450 ) during the first two months after launch, and I'm guessing lower than Broforce's bump because Prison Architect has done many deep discounts already https://steamdb.info/app/233450

Update: 24th August 2015
We have released version 0.7.0.3 of Kaboom Arena that addressed a couple of urgent bugs.
Changes:
[FIXED] Bug where the dedicated server would not allow players to pick up items.
Please download v0.7.0.3 for Windows 64 bit here:

• v0.7.0.3 - GameJolt
  
• v0.7.0.3 - IndieGameStand
  
• v0.7.0.3 - Itch.IO
  
• v0.7.0.3 - IndieDB
  
• v0.7.0.3 - ModDB
  
• v0.7.0.3 - DropBox
  

Please download v0.7.0.3 for Linux 64 bit here:

• v0.7.0.3 - GameJolt
  
• v0.7.0.3 - IndieGameStand
  
• v0.7.0.3 - Itch.IO
  
• v0.7.0.3 - IndieDB
  
• v0.7.0.3 - ModDB
  
• v0.7.0.3 - DropBox
  

Please provide feedback through the usual channels.

Update: 16th August 2015
This is a new upload that addresses the issue with the Linux build of v0.7.0.0 not working, we upgraded to v3.1 of Blui in the process.
Please download v0.7.0.1 for Linux 64 bit here:

• v0.7.0.1 - GameJolt
  
• v0.7.0.1 - IndieGameStand
  
• v0.7.0.1 - Itch.IO
  
• v0.7.0.1 - IndieDB
  
• v0.7.0.1 - DropBox
  

Please provide feedback through the usual channels.

roguecode;36386" said:

Firstly, you obviously didn't test Origin enough - I had endless trouble with it in the beginning stages. ;-)
Jokes aside, welcome back to SA!
It is great seeing more people from Durban on these forums. We really need to get meetups going. Even if it is just a handful of people. Regarding venue, we can organize space at a few places, so that shouldn't be too much of an issue.
I did a Unity talk at Dev2 the other day (https://www.eventbrite.com/e/dev-evening-5-aug-545pm-tickets-17673272233) and one of the Dev2 guys mentioned possibly having a gamedev hackathon type weekend at some point. That'd be cool.
We've been building something for a while and will need to start play-testing soon - and bug testing later. So will likely contact you at some point :)

Hey there!
Sorry for late reply. No internet at home atm (using dongle... It sucks).
The testing Origin got me laughing cause I know exactly what you mean lol.
As for meet ups. I am up for that! Actually been looking around to see venues or just do something outdoors! But I am up for organising or helping to organise an event in the future!
As for testing, I am alaways up for that! Just drop me a message when you can and I will be more than happy to test your product!
MY PC arrives in 4 days! Once I build it again, run tests to see if everything is fine (thats a days job), I am ready to go! :)

Firstly, you obviously didn't test Origin enough - I had endless trouble with it in the beginning stages. ;-)
Jokes aside, welcome back to SA!
It is great seeing more people from Durban on these forums. We really need to get meetups going. Even if it is just a handful of people. Regarding venue, we can organize space at a few places, so that shouldn't be too much of an issue.
I did a Unity talk at Dev2 the other day (https://www.eventbrite.com/e/dev-evening-5-aug-545pm-tickets-17673272233) and one of the Dev2 guys mentioned possibly having a gamedev hackathon type weekend at some point. That'd be cool.
We've been building something for a while and will need to start play-testing soon - and bug testing later. So will likely contact you at some point :)

Woah!
Haven't posted here in ages. Bunch of stuff has happened since the Ludum Dare version. Moved towards having the ball be a player, and any player can act as a ball if they're not on a Raptor. Added a mechanic that players can 'shield' - if a raptor-mounted player runs into them when they're shielded, that player gets dismounted. The game is now a lot more about mounting/dismounting raptors and trying to score.
When Raptor Polo was at Super Friendship Arcade, I noticed most players just focused on running around and hitting each other - often only randomly scoring. This is partly a teaching problem - but it's also just because running around and hitting each other feels the most fun. So I added a sort of 'Bloodbowl' mode where each player has health that can be drained through hitting them in various ways. When they reach 0 health, the player that hit them last, scores a goal. I need to test this mode soon, but I feel it's a better direction as it rewards players for hitting each other - which is clearly what most players enjoy :D. Depending how testing goes, I might end up removing 'goals' entirely from the game.

So far, @creative630, @MCA and guys at Rhapsody has made some really cool sounds for this - I've made a build that lets you select the track you wanna play with and sent it back to the artists to check out. So excited to share it with everyone, but I guess that's only for after the compo ends! :)

MutantPigeon24;32332" said:

Hi guys,
I'm having size issues when building for Android.
Whats the best way to export 2D sprites from photoshop? Is there some sort of trick to it?
The PNGs come out at about 137kb, but once imported into Unity, they bounce up to 1.3mb.
I've tried compressing them, but I end up with a lot of banding.

hey man are you using a texture atlas?
check out texture packer https://codeandweb.com/texturepacker

An awesome guy wrote a game in LD full of shaders, and he wrote a thing showing how he wrote them, and I would REALLY REALLY want to understand how it works, so I'll try to study it... I'm pastaing it here.
The piece itself: http://ludumdare.com/compo/2015/05/11/a-shader-made-of-whispers/#more-467042
The effects in totality:

Copy pasta:
A Shader Made Of Whispers
Posted by Managore (twitter: @managore)
May 11th, 2015 4:31 am
For Ludum Dare 32 I made a game called A Knife Made Of Whispers. There’s also a video if you’d like to get a quick idea of what the game is like. Quite a few of the 48 hours were spent writing a shader to add a number of visual effects to the game, including chromatic aberration and diffusion.
I’ve since had a number of people express interest in how the shader was developed and what it does, so I’ve decided to write a guide. While I try to explain things as best I can, there is a fair bit of maths and non-intuitive code involved, so be warned!
Here’s a summary of the effects:
Shader Effects
Basics
The shader is written in GLSL, and is comprised of a vertex shader and a fragment shader. It’s important to note that the vertex shader I used is the stock standard, do-nothing-special, passthrough vertex shader in Gamemaker Studio:
attribute vec3 in_Position;
attribute vec4 in_Colour;
attribute vec2 in_TextureCoord;
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
void main()
{
vec4 object_space_pos = vec4(in_Position.x, in_Position.y, in_Position.z, 1.0);
gl_Position = gm_Matrices[MATRIX_WORLD_VIEW_PROJECTION] * object_space_pos;
v_vColour = in_Colour;
v_vTexcoord = in_TextureCoord;
}
In other frameworks this might look a little different. While vertex shaders can be very powerful, for my game it’s worth mentioning that this code can safely be ignored completely.
The fragment shader is where all of the special effects in AKMOW come from. Here is the do-nothing-special, passthrough fragment shader in Gamemaker Studio:
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
void main()
{
gl_FragColor = v_vColour * texture2D(gm_BaseTexture, v_vTexcoord);
}
Think of this code as the starting point to any shader. The main() function is run for each pixel drawn to the screen. gl_FragColor is the output. It is a vec4, a vector with four values, namely r (red), g (green), b (blue) and a (alpha). In my shader, alpha can be ignored. If you’re unfamiliar with GLSL, note that a vec3, a vector with three values, can have the values referred to as either x, y, z, or r, g, b. So if I have a vec3 called bob, then bob.r and bob.x both refer to the same thing. For a vec4 it’s x, y, z, w, or r, g, b, a.
Inversion
d1
The code is as follows:
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform vec3 u_uSource;
void main()
{
float xx = v_vTexcoord.x;
float yy = v_vTexcoord.y;
vec2 point = vec2(xx - u_uSource.x, (yy - u_uSource.y)*9./16.);
float len = length(point);
gl_FragColor = v_vColour * texture2D( gm_BaseTexture, v_vTexcoord );
if(len>u_uSource.z) gl_FragColor = 1. - gl_FragColor;
}
Let’s go through this bit by bit.
uniform vec3 u_uSource;
The first thing I did was invert the colours in a radius around the lantern. This means I needed to give the shader the x and y values of the lantern, as well as the light radius, and this is what the uniform variable u_uSource does. u_uSource.x and u_uSource.y correspond to the x and y values of the lantern on (or off) the screen, while u_uSource.z corresponds to the radius, given as a fraction of the screen width.
float xx = v_vTexcoord.x;
float yy = v_vTexcoord.y;
vec2 point = vec2(xx - u_uSource.x, (yy - u_uSource.y)*9./16.);
The variable point is the vector from the lantern’s screen position to the pixel’s screen position.
float len = length(point);
gl_FragColor = v_vColour * texture2D( gm_BaseTexture, v_vTexcoord );
if(len>u_uSource.z) gl_FragColor = 1. - gl_FragColor;
What happens here is if the current pixel is too far away from the lantern (if len is too large), then gl_FragColor is inverted.
Diffusion
d4x
Here’s the code, including the inversion code:
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform vec4 u_uSource;
float rand(vec2 co){
return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}
void main()
{
float xx = v_vTexcoord.x;
float yy = v_vTexcoord.y;
vec2 point = vec2(xx - u_uSource.x, (yy - u_uSource.y)*9./16.);
float len = length(point);
float ran = 0.3*rand(vec2(u_uSource.w+xx,yy));
if(len+ran>0.7) gl_FragColor.rgb = vec3(0.,0.,0.);
else {
gl_FragColor = v_vColour * texture2D( gm_BaseTexture, v_vTexcoord );
if(len>u_uSource.z) gl_FragColor = 1. - gl_FragColor;
}
}
The rand() function is a well known pseudo random function so I won’t cover it here.
float ran = 0.3*rand(vec2(u_uSource.w+xx,yy));
u_uSource is now a vec4, since I needed to pass through a time value, u_uSource.w. Using xx, yy and u_uSource.w in the rand() function ensures the static effect appears random. As a result, ran is a random value between 0 and 0.3. The 0.3 was hardcoded in so that the diffusion wasn’t too weak or too strong.
if(len+ran>0.7) ...
A distance from the lantern increases, len+ran>0.7 becomes more and more likely, which makes the diffusion a gradual, random thing rather than a solid circle.
... gl_FragColor.rgb = vec3(0.,0.,0.);
When the previous comparison returns true, the output is overwritten with pure black.
else {
...
}
When the comparison returns false, the pixel is drawn as usual.
Chromatic Aberration
d5x
(look especially to the right side of the gif, to where the red and blue separate out)
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform vec4 u_uSource;
float rand(vec2 co){
return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}
void main()
{
float r1 = 0.0025;
float r2 = r1*2.;
float s1 = 1.-r1*2.;
float s2 = 1.-r2*2.;
float xx = v_vTexcoord.x;
float yy = v_vTexcoord.y;
vec2 point = vec2(xx - u_uSource.x, (yy - u_uSource.y)*9./16.);
float len = length(point);
float ran = 0.3*rand(vec2(u_uSource.w+xx,yy));
if(len+ran>0.7) gl_FragColor.rgb = vec3(0.,0.,0.);
else {
vec3 newcoordx = vec3(xx,xx*s1+r1,xx*s2+r2);
vec3 newcoordy = vec3(yy,yy*s1+r1,yy*s2+r2);
gl_FragColor = vec4(0,0,0,1);
gl_FragColor.r = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.r, newcoordy.r))).r;
gl_FragColor.g = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.g, newcoordy.g))).g;
gl_FragColor.b = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.b, newcoordy.b))).b;
if(len>u_uSource.z) gl_FragColor = 1. - gl_FragColor;
}
}
This part of the shader is easily the messiest, but what is essentially happening here is the shader is sampling the screen at three different magnifications. One for the red value, one for the green, one for the blue. To give you a clearer idea of what I mean, here’s the chromatic aberration turned up by a factor of ten.
d6x
The red value is determined as normal, in the same way that the colour values were determined previously, but the green value is determined by ‘zooming in’ by 0.25% (2.5% in the exaggerated version) and the blue value by ‘zooming in’ by 0.5% (5% in the exaggerated version). Let me highlight and talk about the new pieces of code:
float r1 = 0.0025;
float r2 = r1*2.;
float s1 = 1.-r1*2.;
float s2 = 1.-r2*2.;
The 0.0025 value here determines the strength of the aberration, any number can be used here. r1 and s1 are used for green while r2 and s2 are used for blue. You can see that r2 is simply twice as much as r1.
vec3 newcoordx = vec3(xx,xx*s1+r1,xx*s2+r2);
vec3 newcoordy = vec3(yy,yy*s1+r1,yy*s2+r2);
The previously defined values are now used to calculate new sample positions. newcoordx.r and newcoordy.r are still xx and yy; they haven’t changed, but newcoordx.g and newcoordy.g are now slightly closer to the center of the screen, and newcoordx.b and newcoordy.b even more so.
gl_FragColor = vec4(0,0,0,1);
gl_FragColor.r = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.r, newcoordy.r))).r;
gl_FragColor.g = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.g, newcoordy.g))).g;
gl_FragColor.b = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.b, newcoordy.b))).b;
The first line might not be necessary but simply initializes gl_FragColor. The next three lines calculate the values of the three colours separately, using the three different coordinate values. There is probably a lot of room for optimizing all of this code, but at the time I used what worked, disregarding efficiency.
Chromatic Ring
d7x
This part of the shader was almost a fluke. For a while I had a much faster diffusion ramp between the light and darkness but was never happy with how it looked, so eventually I tried to create a different sort of chromatic effect and this is what I ended up with.
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform vec4 u_uSource;
float rand(vec2 co){
return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}
void main()
{
float r1 = 0.0025;
float r2 = r1*2.;
float s1 = 1.-r1*2.;
float s2 = 1.-r2*2.;
float xx = v_vTexcoord.x;
float yy = v_vTexcoord.y;
vec2 point = vec2(xx - u_uSource.x, (yy - u_uSource.y)*9./16.);
float len = length(point);
float ran = 0.3*rand(vec2(u_uSource.w+xx,yy));
if(len+ran>0.7) gl_FragColor.rgb = vec3(0.,0.,0.);
else {
vec3 newcoordx = vec3(xx,xx*s1+r1,xx*s2+r2);
vec3 newcoordy = vec3(yy,yy*s1+r1,yy*s2+r2);
gl_FragColor = vec4(0,0,0,1);
gl_FragColor.r = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.r, newcoordy.r))).r;
gl_FragColor.g = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.g, newcoordy.g))).g;
gl_FragColor.b = (v_vColour * texture2D( gm_BaseTexture, vec2(newcoordx.b, newcoordy.b))).b;
float zz = len+0.01*ran-u_uSource.z;
if(zz>0.) gl_FragColor.r = 1. - gl_FragColor.r;
if(zz>point.x*0.02) gl_FragColor.g = 1. - gl_FragColor.g;
if(zz>point.y*0.02) gl_FragColor.b = 1. - gl_FragColor.b;
}
}
The idea is twofold. Firstly, I added 0.01*ran to the inversion calculation, so that the edge was slightly diffused. Then, I inverted the red, green and blue values separately, allowing me to offset the green horizontally and the blue vertically, which creates the rainbow effect. The green inverse circle is ‘pulled’ slightly to the right and the blue inverse circle is ‘pulled’ slightly down.
float zz = len+0.01*ran-u_uSource.z;
This new variable zz is just a way to tidy the next calculations up slightly. Note that zz > 0 is equivalent to len+0.01*ran > u_uSource.z, which is very similar to the inversion calculation done before, but with 0.01*ran added in.
if(zz>0.) gl_FragColor.r = 1. - gl_FragColor.r;
if(zz>point.x*0.02) gl_FragColor.g = 1. - gl_FragColor.g;
if(zz>point.y*0.02) gl_FragColor.b = 1. - gl_FragColor.b;
Nothing has changed for the red calculation, but the green calculation is now factoring in the horizontal distance of the current pixel from the lantern, and the blue calculation is now factoring in the vertical distance.
And that’s it! I hope this was informative and showed you something of the wonderful world of shaders. My apologies if it was too confusing, I find shader code can be particularly challenging to explain.
Thank you for reading and please let me know if you have any questions, comments or advice! I’m more than happy to answer a few questions where I can.

Hi there, though I've not done the particular style you have there, I'm an experienced illustrator and photoshopper, and would love to add some sublime fantasy landscapes to my reportoire, so if our needs connect, why not? :)
I wanted to know, what's the direction you're taking your game in? Is it just shooting arrows at the sky at impossibly tiny birds? Where are you going with it?
You can find some of my painting pieces here, though they're mostly an hour speedpaints... Here are some of the ones I like most... Yeah they're not in the style you're looking for, just as a general reference :)

Thanks again to @BlackShipsFillTheSky and the rest of Free Lives, it was awesome jamming there this weekend!
Everyone's games look awesome. I wish I had the time to properly look at each one and give it some feedback, but that's gonna have to wait for a bit :(
So I made something small over the weekend: Symmetric Torpedo, a submarine-on-submarine combat puzzler: http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=23363

Hi, we about a month away from releasing on Early Access on Steam so we looking to start doing some local (SA) game testing to test 8 player multiplayer games.
We hope to give out the first batch of codes for the game this Friday/Saturday (depending on how things go this week).
If you interested in helping test please add your e-mail address on this form.
Some screenshots:

Thanks,
Lighthouse Games Studio

SebastianS;32339" said:

I DEFINITELY think it's a possibility that the CTFED guys would be able to host. I've been to one of their meetups and also know one of their organisers. Should I enquire?

It sounds like the CTFED group doesn't have their own space, seeing as they're being hosted by 22seven? I have some pretty strong contacts with 22seven, if we're short on space I could ask them if they'd be interested in hosting in their theatre... I've been holding back on this until I get back to SA.

MutantPigeon24;32332" said:

The PNGs come out at about 137kb, but once imported into Unity, they bounce up to 1.3mb.
I've tried compressing them, but I end up with a lot of banding.

GPUs have no concept of file formats like PNG, JPG, etc. GPU manufacturers make use of various (often proprietary) compression format that textures need to be in if you want them to be optimal for the GPU. You can otherwise go ahead and use 32 or 16 bit RGBA images that are not compressed at all, and will generally look better, at the cost of more memory and texture bandwidth consumed when rendering.
What you're seeing above is because you have your Android settings set to ETC texture compression (under the Project Settings window I believe...). ETC compression is supported by *all* Android devices... whereas the other Android compression formats (DXT, ATC, etc.) only work on GPUs that support them. So generally speaking, it's much easier to ship an Android title only worrying about ETC compression. The downside here is that ETC compression doesn't support Alpha channels at all, so you end up getting the banding that you're seeing because Unity will set a 'Compressed' RGBA texture under ETC settings to be 16 RGBA, which causes a lot of fine color depth to be lost, generally in cases of soft gradients and falloffs.
Some per-case solutions to this could be:
a) suck it up and ship with the banding; there's a chance that what you see in the editor may not even be very visible on device
b) switch from Compressed to Truecolor for textures that band, which will use up double the memory
c) same as b) but see if you can reduce the resolution to compensate
d) re-design your image to remove soft falloffs in the the RGB or A channels, and stick to well defined color sections that wont make color loss from the quantization very apparent
e) break up your texture into 2 new textures, both RGB only (with the Alpha channel of the original texture now a grayscale image), set both textures to Compressed, and write a custom shader that will use the 2nd texture as an alpha channel for blending operations
There's a ton of Googling you can do to understand texture compression, how it works, and its limitations, and you can start here in the Unity Manual where it talks about Getting Started with Android Development (near the bottom under the heading 'ETC as Recommended Texture Compression').
Good luck; I hope you come right!