-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
GAF Indie Game Development Thread 2: High Res Work for Low Res Pay
- Thread starter Jacksinthe
- Start date
- Status
OldmanAndroid
Member
One-off powerups.
For some reason it really bothers me in a game where I have too many guns that just simply kill in a different way (Axiom Verge for example, or Bioshock with the vigors). I prefer it when the enemies are designed around the weapons, sort of a "right tool for the job". Many enemies lunging at you from different directions? Pull out the shotgun. Enemies keeping their distance and trying to pick you off? Pull out the sniper weapon.
Thats just me though, I dont like having different weapons that all basically do the same thing, but just "look cool".
Having separate ammo for each gun is sort of a happy medium perhaps. Out of pistol ammo? Pull out the shotgun.
Yoshi
Headmaster of Console Warrior Jugendstrafanstalt
Personally, I hate complication in games. So, if I had the choice, I'd prefer a single weapon with power ups. In games with several weapons, either it is obvious which one is the best and then I'll always just switch to the best, or it is not obvious and then I just stick with whatever I have because I don't want to deal with this stuff.
Sweet! Nintendo will email you on release date for the patch, so if you don't hear from them in a few days (few days since it's approval), email Nintendo. Just letting you know incase they didn't email you.
Congrats.
Generally I find "my" weapon and stick with that for as much as I can. I'll try other weapons as they come and then quickly either revert back to my favored weapon or start favoring the new one. The only time I'll switch between weapons regularly is if combat design makes it impractical (or impossible) otherwise.
That said, the control scheme also factors into this. Consider a game like Jak II or Jak 3, where you have melee moves on square and circle and gun moves on the right trigger, and d-pad changes which gun you're carrying. In those games, I switch between melee and gun attacks constantly because it's immediate and it's practical, but about the only time I ever switch which gun I'm using is if I run out of ammo for my preferred gun.
So I think wanting players to use multiple weapons concurrently means adding separate attack buttons for each of them. Similar, I think, to the right- and left-handed weapons in Castlevania and Dark Souls, except I haven't actually played either of those games properly.
I want the rocket to fly off, but you can only see it in that box. And without having to design it so that the rocket flies "behind" something.
Thanks, you both had help me out a lot!
-------------
New screenshot and pose, just because:
electroflame
Member
I want the rocket to fly off, but you can only see it in that box. And without having to design it so that the rocket flies "behind" something.
Maybe use a RenderTexture (pretty much a RenderTarget) to get a texture representing what the camera is drawing and then crop the result?
My first thought was having it fly behind something. What is the outside of the box going to show in your game? Sky, space, clouds, foreground objects?
I want the rocket to fly off, but you can only see it in that box. And without having to design it so that the rocket flies "behind" something.
This page has some discussion that might give ideas. Maybe the camera parent idea would work, though I don't quite understand what they mean when they mention a mesh mask.
http://answers.unity3d.com/questions/590800/how-to-cullrender-to-through-a-window.html
*edit* For the mask stuff, it sounds like they're talking about similar techniques to what one would use for a minimap: http://answers.unity3d.com/questions/20676/how-do-i-create-a-minimap.html
HellBlazer
Member
I want the rocket to fly off, but you can only see it in that box. And without having to design it so that the rocket flies "behind" something.
I've been linked to this kind of shader when I looked into this before. Never did end up trying it though...
Also, if you happen to have a Pro license, you can use their "early access" 2D features, which include cool-looking masking functionalities.
Thanks for the help guys!
Yeah, this could work. I'd have to setup one camera to render to texture, then another camera to render the quad (to draw the renderTexture) correct? Or maybe I can mess with the culling masks and what not and do it with one camera...
I don't have pro, so I can't use the new features unfortunately. With that shader, I'd need to pass in the masking texture to everything that's inside the box right?
It's another background image outside the box. I saw that unity forum thread, but got scared away since I don't know much about shaders. =/ If I'm not mistaken, if I go that route, everything that's "inside the box" needs to be rendered with a shader that does the stencil test? Would that mean I'd have to use a custom shader for everything?
electroflame
Member
Previous "pro features" are available in personal for Unity 5, but beta builds and features are still pro license holders only I believe.
electroflame
Member
HellBlazer
Member
They started releasing alpha builds of the (awesome) new features the 2D team is working on, but you apparently need a Pro license to run it: https://bitbucket.org/Unity-Technologies/2ddemos
I'd like to use the masking feature. These new 2d features. I haven't checked out 5.1 yet to see they've been released, but I don't think they're in 5.0.
HellBlazer
Member
This happens so much to me as well.
electroflame
Member
Jacksinthe
Banned
I appreciate your insight, all. This is something I've been bouncing back and forth with for a while on how to handle weaponry. Pretty much in all my playtesting I revert to using the disk as the most versatile weapon. I'm going through most of my AI routines to spruce them up a bit for enemies and need to rework several more difficult, smarter types, so I've been trying to nail down the weapon balance for a while. It's proving difficult because weaponry is a nice thing to have, but it also will wind up leaving you with completely rote situations of enemy AI, weaknesses, strengths, etc. I'd rather have the end-game per each weapon serve a specific purpose other than dealing damage or getting by defenses. I am taking a more situation-based approach that provides utility, not just the aforementioned defense bypass. This way I can provide alt-weapons as pickups that you can swap out, but never carry more than one that is worked in with the theme and structure of movement/traversal/attacking.
Dewfreak83
Neo Member
Sure, I'll give some feedback!
electroflame
Member
I'll be happy to take a look in the morning, if you still need feedback.
Here is the (all-integer) stretching algorithm I talked about recently.
Well, the interesting aspect of this algorithm is that it is a 1:1 copy of
Bresenham's integer line algorithm for drawing lines on the screen. Hence,
with the very same algorithm for drawing lines you can stretch an image up and
down in one dimension. This should renew some interest in Bresenham's integer
line algorithm for those studying computer graphics for video games.
To keep this post within resonable bounds, I'm not going to explain
Bresenham's integer line algorithm, at least not today. So I assume you
already have some experience using it, yet don't hesitate if you haven't. You
can apply my algorithm below with ease no matter whether you know about
drawing lines or not.
Code:
void stretch_line_bhm(img *imgSrc, img *imgDst, int widthSrc, int widthDst)
{
int x = 0;
int y = 0;
int dx = widthDst;
int dy = widthSrc;
int e = 0;
// determine iteration direction
if(dy < dx)
{
e = 2*dy - dx;
// iterate over x (scale up, widthSrc < widthDst)
while(x < dx)
{
// setpixel(x,y)
imgDst[x] = imgSrc[y];
if(e > 0)
{
y++;
e -= 2*dx;
}
x++;
e += 2*dy;
}
}
else
{
e = dy - 2*dx;
// iterate over y (scale down, widthSrc >= widthDst)
while(y < dy)
{
// setpixel(x,y)
imgDst[x] = imgSrc[y];
if(e < 0)
{
x++;
e += 2*dy;
}
y++;
e -= 2*dx;
}
}
}y. This algorithm differs from Bresenham's only in so far as we don't have to
compute the deltas dx and dy (they are already given) and we also don't need
to look at their signs (always positive). I also skipped some other boundary
cases (dx or dy = 0, dx = dy or the like). From the perspective of Bresenham's
algorithm, we simply draw a line from (0,0) to (dx,dy), yet we won't plot
pixels on the screen by calling for example setpixel(x,y), nope, we instead
update our image/line array via imgDst[x] = imgSrc[y], which is the only real
modification to Bresenham's algorithm. Hence, if we scale down for example, we
take the Bresenham-computed y coordinate to actually reference a color in our
source array and put it into our destination array (yet we only need to update
if x changes, but I left it the way it is to better show the similarities).
But there is more going on; basically, given a ratio a/b (slope of a line), we
can stretch an array using this algorithm. But who said that the values need
to be colors? Hence, you can stretch any 1d array. You may replace the image
type (img) in the declaration of the function to the type you need.
The algorithm shown above is conceptually one of the fastest scaling integer
algorithms able to deal with non-integer scaling factors (yet there are faster
ones, implementation-wise). It's speed comes from converting a division into
an iterative division (by subtraction) with some Bresenham juices in the mix,
i.e. in modifying the optimal condition dy/dx <= 1/2 leading to Bresenham's
special error term while staying all integer! So you can implement this
algorithm on integer (graphics) hardware quite easily.
Let me open up a different perspective. Let us consider a mapping of one
interval onto another one by a function. If the function is linear, then this
function will represent a line. Now if the slope of this line is less than 1,
then any given interval will be compressed by f. You may draw a coordinate
system with a line starting at (0,0) having a slope of, well, dy/dx = 1/3 and
select any interval on the x-axis, i.e. [a,b] with f.e. a = 0, and b say 5,
hence [0,5]. Now if you map this interval using a line f(x) := 1/3*x (note; we
will map the entire interval straight instead of looking at each x
individually, hence we will write f([a,b]) instead of saying f(x) for each x
in [a,b]), we can see that the function f will compress the interval [a,b] to
another one [c,d]. So we have f([0,5]) = 1/3[0,5] = [0,5/3]. Hence, our
destination interval is the compressed (scaled down) image of [0,5] by a
factor of about 1.667. On the other hand, if our linear function f is given by
f(x) := 2.3x, we have f([0,5]) = [0,11.5], a dilatation (scale up) of the
interval [0,5] by 2.3. However, contrary to our real intervals [a,b] and
[c,d] our source and destination image arrays (the array of color pixels to be
scaled onto another one) are discrete. Hence, some array elements of the
source array will be mapped to the same destination element when scaling down.
For example, let us map the array indices of element s[1] and s[2] via the
function f(x):=1/8*x, hence f(1)=1/8 and f(2)=2/8. Since f(x) will index our
destination array, we need to truncate making it an integer. We find,
trunc(f(1)) = trunc(f(2)) = 0. Hence, both source indices (1 and 2 in this
case) map to the same destination index. If you try to plot this trunc-
function for a couple of values, i.e. i -> trunc(f(i)), you will see that it
is a piece-wise constant function following the line given by f. And those
constant pieces (spans) are exactly what Bresenham's algorithm computes. If
you look at it, a line on a raster is a piece-wise constant function. But
wait a minute! Where is our raster in here? Well, our raster/grid is spanned
by the source and destination array's indices. Scaling a source array (of
color pixels whatever) now amount to raster a line (f, our scaling function)
on a grid spanned by the source and destination indices of our source and
destination arrays. This rastered line on the grid will give as the function
(index mapping) i -> trunc(f(i)) which we need to map the source array onto
the destination array like d = s[trunc(f(i))] (imgDst[x] = imgSrc[y], see
the algorithm above). The crux of Bresenham's integer line algorithm is that
it computes the trunc() function in such a way that the error to the true line
(f) is minimal for each i, and of course it's all integer based and quite fast.
The actual algorithm given above can be simplified by kicking out Bresenham's
special juices and just rely on the intrinsic idea. I may show a simplified
algorithm next time. But let's stick with this one and let us do some cool
stuff with it. Well, one may try to make some wavy patterns like seen in the
animation above by simply animating the width of each destination line of, for
example, a sprite or even the whole screen. The animation shown above just
uses a cosine function to animate the width of the line up to the right border
of the window while the scaling algorithm iterates over each line doing its
thing.
As I said, you can also stretch vertically. You may want to shrink the screen
or do some cool little effects like John Carmack did back in the days of Doom.
Do you remember his special melding screen effect? Way cool! I never saw this
effect again. Well, we have millions of blending effects these days, but those
little cool ones relaying on some clever little algorithms I do miss. Well, I
think we can improve on Carmack's melding effect a bit. If I remember
correctly, the foreground was melding away to the bottom of the screen at
unequal rates per column (like dropping a curtain) exposing the background
(the new screen) at the same time. I think it would be cool to let the new
image (background) also meld into the screen from above with the old one
melding away to bottom at the same time, but with the two processes
synchronized (per column). Anyone?
Mess end. xD
The 90% thing.
Probably better to wait. People will be checking Steam's store page, but they won't be checking Greenlight.
MrNyarlathotep
Banned
Outside of games that use forced hard-typing (eg "you must use fire weapons to kill the red guys" or whatever) I'll stick with the weapon that fits my playstyle for that game for the entire duration of that game, and reluctantly swap to a secondary if I run out of ammo for my favourite.
Note this isn't necessarily the 'best' weapon, just the one that fits how I like playing the game most. In games with huge weapon variance like Borderlands, I'll often use lower powered weapon type of the type of weapon I like (shotguns in Borderlands case) even if I have stronger / better alternative weapons I have looted (eg a sniper rifle)
If you can do this as a UI element rather than as a game element, Unity UI already has sprite masking functionality
You should wait. Between Steam Sales and E3 it's gonna be some intense 10 days.
I almost had to change the release date of my game when they announced the sales to steam developers.
I want the rocket to fly off, but you can only see it in that box. And without having to design it so that the rocket flies "behind" something.
Can't you make a box collider and when your object is inside it you turn on the sprite and/or other necessary scripts of it and when it moves outside do the opposite?
SpacePirate Ridley
Member
Thanks guys, will sent your regards to jon, the pixelartist. He was a little bit down today so that hopefully will up his spirits.
Looks great!
Looks great!
It has been said a few times already but I agree on waiting a bit, spend a few extra days on setting up the Greenlight page, make it perfect, and post it after the sale.
Good luck with the Greenlight process!
Unfortunately they're not UI elements.
I get the concept. Would this be done in a shader?
I want to see a part of the rocket when it leaves the box, not disappear as a whole.
Thanks again for the help guys!
Jacksinthe
Banned
Aye. I'm pretty much the same way. We've created a bunch of weapons for the player outside of boss style weapons and have gone back and forth on the weapon system. We've narrowed down some trick weaponry we want to keep in game but really REALLY want to edge out level and enemy design with encounters for the main weapon and not the hard-type as you've mentioned. It's fun to have weapons that you can use either temporarily that work, are pretty OP and make you feel powerful while you use them. We've run into making cool weapons that need to be toned down just to work with the rest of the game due to permanent use and we want to avoid that - we want flashy, snazzy, HOLY FUCK style one-offs to blow things up with.
Everyone pretty much agrees a solid main weapon and one-offs are the way to go. I concur.
Again, everyone, I appreciate the help.
Dynamite Shikoku
Congratulations, you really deserve it!
^ I also agree with what the others said about using one main weapon.
I asked this in the iOS gaming thread, but I may as well ask here too. Which do you guys think would be a better option for releasing a new game on the app store?
1. A paid version, and a separate ad-supported free version OR
2. An ad-supported free version with an IAP to remove the ads.
Any thoughts?
I asked this in the iOS gaming thread, but I may as well ask here too. Which do you guys think would be a better option for releasing a new game on the app store?
1. A paid version, and a separate ad-supported free version OR
2. An ad-supported free version with an IAP to remove the ads.
Any thoughts?
Option 2 would make it easier for players to remove ads. Instead of having to download a separate game, they'd be able to instantly remove ads.
Jacksinthe
Banned
Exceptionally small time like everything else shown so far. The good stuff will be saved for later after we announce but this is enough for now to get a feel for the art and animation
Thanks for the input, Dynamite. Seems to be the going rate
As for the app I would vote for 2. I should have done it that way with our mobile game but it was a learning experience
Thanks for the input, Dynamite. Seems to be the going rate
As for the app I would vote for 2. I should have done it that way with our mobile game but it was a learning experience
I'd go with 2 as well. Just simpler all around.
Is that a gun shield? Awesome!Exceptionally small time like everything else shown so far. The good stuff will be saved for later after we announce but this is enough for now to get a feel for the art and animation
Dynamite Shikoku
Congratulations, you really deserve it!
Thanks for the responses. I'd actually just rather have a paid app, but I don't know if many people pay for apps these days so that's why I'm thinking about doing it as a free one.
Yoshi
Headmaster of Console Warrior Jugendstrafanstalt
Can't you have both? If someone wants to purchase the game anyway, he can right away (and then option 1 is more convenient), if someone wants to try it out beforehand, option 2 is more convenient. Does it cost extra to offer both options?
You don't have to. In the end you need the visible pixels of your rocket and
an offset coordinate to put them at the right place on the screen (inside the
window in this case). The window has a bounding rectangle (the window itself)
likewise does the rocket have. The intersection of both rectangles can be done
by simple min/max tests for each corner, assigning the result to the
respective corner of the new (intersection) rectangle. The intersection
rectangle (if not empty, otherwise you are done) now serves as the offset from
where to take the pixels of the rocket texture and also serves as on offset to
where the pixels should go into the window (perhaps another texture). So you
need to compute those offsets into each texture (given the intersection
rectangle) and then start to copy the opaque pixels over.
Cool stuff, bro! Your game will perhaps serve as an ideal example for some ofExceptionally small time like everything else shown so far. The good stuff will be saved for later after we announce but this is enough for now to get a feel for the art and animation
...
the stuff I am working on -- alas you may not know why and how. Anyhow, keep
these huge uniform colored pixels coming!
Edit: What will be the native resolution for this game? What about the
game-pixel's size given the native resolution? Say the game runs at 1080p,
what will be a game-pixel's native pixel size on the screen?
@Dynamite Shikoku:
I want to buy the game straight, not seeing any ads (putting me down)
whatsoever. So option 1 for me, but option 2 is perhaps the better one on any
global scale.
Dynamite Shikoku
Congratulations, you really deserve it!
Option 1 is both. It doesn't cost any extra.
That looks really cool and once again a lot of personality in just few pixels. I really like the way it's pixel art, but the individual pixel movements aren't constrained to the same grid, makes it look really hypnotic and fresh.Exceptionally small time like everything else shown so far. The good stuff will be saved for later after we announce but this is enough for now to get a feel for the art and animation
- Status