Developing the actual core gameplay is my favourite bit, but making music is a close second
-
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.
Indie Game Development Discussion Thread | Of Being Professionally Poor
- Thread starter chubigans
- Start date
- Status
Developing the actual core gameplay is my favourite bit, but making music is a close second
Ihateyouchris
Member
Developing the actual core gameplay is my favourite bit, but making music is a close second
Core gameplay is definitely the most fun for me as well. I was really worried when I first started making music for my games that people would hate it, but that thankfully hasn't been the case (I think...). It's a nice diversion from coding and art for me, aka "Aww, fuck this bug Imma make some chiptunes and let my subconscious brain figure this shit out"
I wish I was good enough to make chiptunes, lol. I'm creative, I just can't ever think of how music should go in my head for what I'm making.
I think that's a secret to making progress. Hopping from one thing to the next, keeping it fresh. I've had these results screens on my mind for weeks, but have been doing odds and ends instead until I've finally got them straight in my head. Now writing them is much less of a chore than it would have been, so they should be way radder for it!
I think that's a secret to making progress. Hopping from one thing to the next, keeping it fresh. I've had these results screens on my mind for weeks, but have been doing odds and ends instead until I've finally got them straight in my head. Now writing them is much less of a chore than it would have been, so they should be way radder for it!
Definitely one of the big things is to switch it up now and then. You will come back to it thinking of a solution you didn't when you were in the thick of it.
Just got in contact with my composer, and he'll be supplying some fresh beats for my game very soon. I'm thoroughly excited, to say the least, to actually have music over my gameplay!
One of the thoughts I think I'd share with you is one of the things any platformer should have especially in today's market:
Evolving levels.
What does this mean? Well, in platformers, especially after they ship, they often are shipped with a specific level pattern and level types. In today's world, however, with DLC and updates, I think platformers can be expanded and improved upon well beyond the original shipdate. One of the features of my game will including these evolving levels.
Some time after the release of the first world, I'm going to continue updating it with more routes, paths, powers, and secrets, so each time the game updates, you'll find more hidden things emerge as you progress through the world. It changes, evolves. The game won't be the same as it was when it was released, but it'll be richer, more fully realized.
This creates sort of anticipation toward the game in general. You can tease updates to the game before they happen, or make stealth updates that your fanbase would love to explore and find out what's going on.
Today I'm working on fully hooking up the controls and the big push towards making powers actually working, then it's entirely level design from there.
Diablohead
Member
Being december I have been real busy with store work but this weekend is my gaming crunch weekend, currently bug squishing and adding in the final things I want before I start to plan making stages, wish I did this months ago but just been too busy.
Screenshot Saturday! What do you have? I HAVE
TREESSSSSSSSSSSSSSSSSSSSSSSSSSSS
And enjoy another video!
http://www.youtube.com/watch?v=yZdihIWTDbs
TREESSSSSSSSSSSSSSSSSSSSSSSSSSSS
And enjoy another video!
http://www.youtube.com/watch?v=yZdihIWTDbs
MikeHaggar
Member
so i just realized it's going to be a HUGE challenge to port the current game i am developing to ios. the lead platform is xblig and the game seems to just be far too ambitious in regards to art assets to squeeze it onto ios.
does anyone have any experience with this? should i really only be using roughly 140-180MB of ram on ios hardware that has a total of 512MB? that seems.... crazy to me.
it's really not an option to simply not release on ios, so we're going to have to do something, but i hate the thought of having to scale back the game design in order to accommodate the small memory available on apple's devices. the worst part is that the game is not overly ambitious aside from the high quality, 2d, hand-drawn art that it features...
any insight into max ram utilization on ios platforms would be helpful. all i can find is that apple states that after 20MB your app runs the risk of crashing depending on what all is going on in the background (of course developers state that you can get away with far more than that on newer devices before having to be concerned).
does anyone have any experience with this? should i really only be using roughly 140-180MB of ram on ios hardware that has a total of 512MB? that seems.... crazy to me.
it's really not an option to simply not release on ios, so we're going to have to do something, but i hate the thought of having to scale back the game design in order to accommodate the small memory available on apple's devices. the worst part is that the game is not overly ambitious aside from the high quality, 2d, hand-drawn art that it features...
any insight into max ram utilization on ios platforms would be helpful. all i can find is that apple states that after 20MB your app runs the risk of crashing depending on what all is going on in the background (of course developers state that you can get away with far more than that on newer devices before having to be concerned).
PSA
Next week is Ludum Dare (http://www.ludumdare.com/compo/). I've made stuff for the last couple, but never had anything I was comfortable with submitting. Using these competitions, though, has helped me learn new tech, as well as create new libraries/tools to make development easier. I really recommend trying to get involved. Hopefully this time I'll have something playable at the end.
Next week is Ludum Dare (http://www.ludumdare.com/compo/). I've made stuff for the last couple, but never had anything I was comfortable with submitting. Using these competitions, though, has helped me learn new tech, as well as create new libraries/tools to make development easier. I really recommend trying to get involved. Hopefully this time I'll have something playable at the end.
Notch apparently didn't schedule his weekend properly so he's missing this one.
I like the idea of Ludum Dare, but not only should I be doing real work/chores/errands during the weekend, I feel like if I took the time to work on it, I should instead be working on my actual engine/game project. I suppose I could try to use the ludum dare period as inspiration to work on what I'm working on normally.
I like the idea of Ludum Dare, but not only should I be doing real work/chores/errands during the weekend, I feel like if I took the time to work on it, I should instead be working on my actual engine/game project. I suppose I could try to use the ludum dare period as inspiration to work on what I'm working on normally.
Woohoo!! Partayyyyyyyyyyy
So here's the fruits of my efforts after solving control issues:
http://www.youtube.com/watch?v=KDsUNvx2tsE Video Here
Soon my precious... soon
http://www.youtube.com/watch?v=KDsUNvx2tsE Video Here
Soon my precious... soon
Dreamwriter
Member
Here's the problem: iPad 1, iPod Touch 4, these do not have 512MB, they only have 256MB. And the Touch 4 is the most popular iOS device. If you want your game to run on a Touch 4, 140MB RAM is probably the upper limit (better to stick closer to 100MB). 512MB devices, you can probably use around 200MB, maybe a bit more. The 1GB devices (Pad3/4, iPhone 5) you're gold.
The trick with memory is that iOS does support true multitasking for its native apps, and Safari uses a TON. It's supposed to clean up that memory when an app is running low, but that doesn't seem to work very well, it's more often the app that gets told to shut down.
Notch apparently didn't schedule his weekend properly so he's missing this one.
I like the idea of Ludum Dare, but not only should I be doing real work/chores/errands during the weekend, I feel like if I took the time to work on it, I should instead be working on my actual engine/game project. I suppose I could try to use the ludum dare period as inspiration to work on what I'm working on normally.
I think things like this help with the fatigue of larger projects. It's something I've experienced before, and having little projects with strict time limits (48 hours) helps to relieve some of the stresses that may have built up, all while minimizing the extent of the distraction.
MikeHaggar
Member
thanks for the input. it amazes me that there are no definitive answers to this. i mean, how does one develop an application if they don't know how much memory they can use?
at any rate, i guess i'll see what i can do to squeeze everything into 100MB. i doubt that's going to be possible though. the current build on xbox is using roughly 170MB of art assets at a given time and they are all required to be in ram. i'm not loading anything that isn't necessary...
interesting infor on the touch 4, i didn't realize that's the most popular. that gives me some incentive to try and support that device. thanks again!
The game won't immediately crash. Various parts of your application will receive didReceiveLowMemoryWarning: messages, or something similarly verbose. At that point, you really have to purge all that you can to get within the trigger threshold, or the device will force kill your app. One suggestion I would make is to use less detailed. I know you mentioned that you aren't really willing to compromise on that, but that's the only thing I can recommend. As far as how much memory you can expect, at work we sampled this in the wild, and our conclusion was actually much more conservative than 100MB. Rather, we are going to try to shoot for something around 40 - 60MB at any given time.
What about streaming and/or lossless compression?
MikeHaggar
Member
i'm assuming the 40-60MB is for devices that have 256MB of memory?
i don't think streaming will work as the game features single-screen gameplay. like i said, all of the assets i'm loading are absolutely necessary. i'll have to look into lossless compression. i wasn't aware there options available for that. i'm using .png files.
png is already lossless compression. When compared to something like bmp, a png will have the exact same data, but reduced size. It's almost identical to just zipping the image, rather than removing a bunch of data from it like jpg would.
So works begins today on moving around with enemies being "cooked" in Mr. Wave. I'm so much more experienced with Construct 2 now than I was when I started, so I can effectively cut down the time needed to make this work than the basic controls. It's just basic animation changes based on the "state" Mr. Wave is in (enemies inside him or not).
MikeHaggar
Member
right. that doesn't really help once the image gets loaded into ram. the image size in ram is then width (in pixels) * height (in pixels) * 4 bytes (8 bits for each r,g,b, and alpha). so a 2048x2048 png spritesheet ends up coming out to:
2048 * 2048 * 4 = 16,777,216 bytes = 16.8MB
i was under the impression he was referring to some type of lossless compression available to be applied as a feature of the ios sdk (similar to how you can apply dxt compression within xna).
Ah, gotcha. I don't know anything about that.
Finally, a new demo of my game is ready! I'm releasing this to the public to get the word out, and I'd really appreciate it if anyone could give me some feedback, mostly regarding the levels and their difficulty.
Here's the game's changelog:
Play demo v5 (in browser)
If you're interested in hearing about the game's development, feel free to follow me on Twitter (@JulianImp), where I post frequent updates on the game as well as other game development-related stuff.
I'll be doing some frequent updates for my final exam on December 21st, mostly adding new levels since that's what my teachers are asking for. I intend to add one new level at the very least, but it's likely that I'll be able to finish two levels in time. However, if I have enough time, I'll keep adding as many levels as possible before that date.
Here's the game's changelog:
- Added a new level, 1-2
- Made some tweaks to level 1-1 to avoid some Z-fighting issues between the block outline objects
- New game results GUI for when you reach a level's goal
- Migrating shaders to make them compatible with DirectX8 and/or OpenGL 1.0. There still are a few objects that use the old and more power-intensive shaders, but they're limited to a few leftover menu buttons now
- Added game text localization and a way to change the language in-game. Supported languages are spanish and english for now
- Added anti-alias and screen resolution settings (the latter only works on standalone builds)
- Changed the system used to unlock worlds and levels, both graphically and programmatically
- The "back" command now recognizes the right mouse button as well as the Escape key. The in-game pause menu remains bound to Esc only
- Implemented an interface system to make menus and sliders work on touchscreen devices
Play demo v5 (in browser)
If you're interested in hearing about the game's development, feel free to follow me on Twitter (@JulianImp), where I post frequent updates on the game as well as other game development-related stuff.
I'll be doing some frequent updates for my final exam on December 21st, mostly adding new levels since that's what my teachers are asking for. I intend to add one new level at the very least, but it's likely that I'll be able to finish two levels in time. However, if I have enough time, I'll keep adding as many levels as possible before that date.
Great job with your game man! It looks and plays great!
One of the things you need to stress to players is that you need controlled clicks to move the Quark. People are going to click like crazy trying to get him to move and it's not going to work very well. It's what I first tried, until it clicked that I had to conserve my clicks to move around.
But overall, really slick man!
One of the things you need to stress to players is that you need controlled clicks to move the Quark. People are going to click like crazy trying to get him to move and it's not going to work very well. It's what I first tried, until it clicked that I had to conserve my clicks to move around.
But overall, really slick man!
I really like what I see! With some good level design (the first 2 are quite good actually) and some kick-ass music to fit the mood, your game could be a killer one!
Best of luck with it
Mr_Appleby
Member
damn, i'd like to give this a shot one year but I'm in the middle of two research projects (game-related, which is fun) and have promised to get drunk on the weekend.
They do 3 of them a year, so come back in 4 months for the next one. I'm probably going to enter, using javascript because I am bad at it.
I'm reeeeeeeeeeeally thinking about entering.
Except Guild Wars 2 is starting their Winter event this weekend. fuck!
I really like what I see! With some good level design (the first 2 are quite good actually) and some kick-ass music to fit the mood, your game could be a killer one!
Best of luck with it
Thanks a lot for the feedback, both of you!
Regarding the player controls, during playtest sessions I've seen most people play the game by clicking wildly to get where they wanted. It's really interesting to hear back from someone who moved around in a more controlled way.
Level 2-1 is an early design which has resisted change partially because it's meant to appear later on. I'll probably tweak it a bit once I've built the earlier levels.
1-3 will probably introduce hazards, which I've been toying around for a while. It's one of the things I want to add to avoid making the game into too much of a hardcore platformer/time attack game and more into a mix of stages that can be played both by speedrunning and leisurely jumping around, which requires adding some interesting levels and features other than just static blocks and rotating gears.
I've also tested reversed gravity fields, and let me tell you, they're a lot harder to get used to than I thought they'd be.
Brummer!
Doesn't depend on single-screen gameplay. Guess how they did allthe sprites on a single screen on the C64 and Amiga500, far exiting their
sprite-hardware capabilities?
Well, you have at most screen_width*screen_height*depth texture information
on the screen at any given time. Far less than 16.8MB, I guess. How you
organize the display of this information is up to you. You may have to change
the rendering order to shuffle the textures in as needed. One possible way
doing this it to start tiling your screen into regions and render them one
after another. Sprites aren't likely scattered all over the screen at once.
So you can tag the sprites needed for a given region, load them in, render
them, and go to the next region. Regions are your friend. And if you have even
less memory available, scanlines are your friend. That way you need only a
fraction of memory. The drawback is an increase in setup overhead for the
rendering engine. But I haven't heard you saying that there is any shortage of
CPU power. So you may better utilize it in your favor.
This. Don't know about the gfx chipset in iDevices, but I assume it features
texture compression, which isn't any new technique at all.
Not necessarily. The png format features different levels of compression.
No compression is also possible.
It's that time again... I finally fixed the controls for moving around while having an enemy inside Mr. Wave, and WOW it took me a LOT less time than I thought it would, my experience with Construct 2 GROWS.
Now I get down tomorrow to the best part EVER. Actually making powers work! WOOHOO!!!
Once I get that and spitting back enemies out finished, I'll have ALL the game's core systems intact for gameplay!
What does this mean? I'll have a DEMO for you guys to try out VERY soon.
Now I get down tomorrow to the best part EVER. Actually making powers work! WOOHOO!!!
Once I get that and spitting back enemies out finished, I'll have ALL the game's core systems intact for gameplay!
What does this mean? I'll have a DEMO for you guys to try out VERY soon.
I thought the point was that the PNG will not have lossy compression -- since he's using PNG's, he's using a lossless format, and I'd say it is EXTREMELY unlikely that he has coded up his own program to generate uncompressed PNGs for some reason. His PNG's might be made smaller by using PNG compression level 9 in an image editor, however.
As pointed out though, if the actual uncompressed texture data is getting used in memory, the file format itself won't really help, since that just saves on disk storage space/data file size.
usea perhaps meant that, while being lossless, they can't be compressed any
further. And I was just saying that some people may use not-so-compressed
pngs - independent from MikeHaggar's posts. Since I know that MikeHaggar don't
want to sacrifices image quality, I haven't written anything about lossy
compression at all.
Dreamwriter
Member
Most iOS games set the device to only 16-bit color, you can most likely convert your assets to 16-bit color with very minimal quality loss, halving their size/memory hit.
Also, you should try using lossy compression on some of your biggest files and see how noticable the lossiness is: on iOS you get HUGE memory savings for using PVRTC compression. PVRTC can use either 4-bits-per-pixel or 2-bits-per-pixel, so that 2048x2048 texture now only requires 2MB or 1MB of memory (2-bits-per-pixel is rather lossy, though, for your game you probably want to stick to 4). And PVRTC compression is native to the GPU, meaning it doesn't get decompressed into memory - the 2048x2048 texture would load faster, transfer to the GPU faster, and stay at 2MB RAM when compressed.
Where PVRTC's lossiness is most noticable is in fine gradients, often I've compressed textures and not noticed the difference without looking very carefully for artifacts, but large gradients often get bandy. Also GUI elements seem to get noticable artifacts.
Your game is like a rocket-jumper dream
The controles feel great and moving around is immediately satisfying when you get the hang of it. (the break function is a cool trick)
I stuggled a bit with small slopes that require precise orientation of the shot : Point downward a bit to much and you go backward, point a bit to high and you don't move..
I can't wait to see what you planned to spice up the experience! Explosions that do not need a surface to trigger ? charged explosion ? Or perhaps you want to keep it really simple at the core and expand on the level design elements, timing variation, etc. (like the gravity fields you mentionned)?
Good luck !
Thought about the problem once more...
Here is another solution which can be combined with the tiling one. Instead of
loading an uncompressed image into memory, one can load parts of a compressed
image into memory and deflates them as needed. How?
First we will construct a new file container, called .mac (memory am cry). The
container is composed of blocks. Each block has a header consisting of at
least two entries, i.e. an id tag and the size of the data block immediately
following the header. The id is used to identify a sprite and is at the same
time a key to seek into the file, which becomes easy now, since one can
traverse the file via the headers to seek the block in question. Worst case:
O
, n = #"sprites". Best case; O(1) if you build a table which holds for each sprite-id the address of the data block within the file, such that you
can seek straight to the data block in question. But what do these data blocks
now contain? What ever you want! But let's be a little bit more specific. A
data block may now contain a .png image, i.e. a sprite animation sequence that
correspond to the given id tag. Hence, given an id tag, we search through the
file, load the associated data block, in this case a .png file containing a
spite animation, into memory, and decompress it as needed.
The MAC file:
Code:
// the file
struct MAC_FILE_t
{
char file_hdr[5]
block_t *pblock
};
// a MAC file block
struct block_t
{
char id[32]; // block character string
int length; // length of data block
void *pdata; // data block
};The file header could be MAC + EOF (end of file, oh please!) + an id of what
type the data blocks are made of, i.e. .png or whatever you have. Well, you
may have recognized that the block's id field is chosen rather large. One
can go with just about 3 characters, or even use integers for identification.
However, the power comes with more characters, but maximal 80, thereafter
any advantage degrades exponentially!
~ Well, this way you can label yoursprites/whatever properly and even build different version solely
differentiated by their id tag, i.e. SPR_ENY0_HI vs. SPR_ENY0_LO (read; sprite
enemy zero low-resolution) contained within the same file. But the real power
of this file format is that you can extend it at will without killing
programs/games using an older versions. Just skip any header you don't know
while traversing through the file.
Ihateyouchris
Member
I really like what I just tried Chris. Nice art as usual
Thanks!
I was talking with some friends and they really didn't like Andy's design, and I tend to agree. I made this new design, was wondering what people thought. Better? Worse?
MikeHaggar
Member
wow, that could be exactly what i need. i'll have to try pvrtc compression on some of our assets and see the results. thanks for the info!
Thought about the problem once more...
Here is another solution which can be combined with the tiling one. Instead of
loading an uncompressed image into memory, one can load parts of a compressed
image into memory and deflates them as needed. How?
First we will construct a new file container, called .mac (memory am cry). The
container is composed of blocks. Each block has a header consisting of at
least two entries, i.e. an id tag and the size of the data block immediately
following the header. The id is used to identify a sprite and is at the same
time a key to seek into the file, which becomes easy now, since one can
traverse the file via the headers to seek the block in question. Worst case:
O
each sprite-id the address of the data block within the file, such that you
can seek straight to the data block in question. But what do these data blocks
now contain? What ever you want! But let's be a little bit more specific. A
data block may now contain a .png image, i.e. a sprite animation sequence that
correspond to the given id tag. Hence, given an id tag, we search through the
file, load the associated data block, in this case a .png file containing a
spite animation, into memory, and decompress it as needed.
The MAC file:
Code:// the file struct MAC_FILE_t { char file_hdr[5] block_t *pblock }; // a MAC file block struct block_t { char id[32]; // block character string int length; // length of data block void *pdata; // data block };
The file header could be MAC + EOF (end of file, oh please!) + an id of what
type the data blocks are made of, i.e. .png or whatever you have. Well, you
may have recognized that the block's id field is chosen rather large. One
can go with just about 3 characters, or even use integers for identification.
However, the power comes with more characters, but maximal 80, thereafter
any advantage degrades exponentially!
sprites/whatever properly and even build different version solely
differentiated by their id tag, i.e. SPR_ENY0_HI vs. SPR_ENY0_LO (read; sprite
enemy zero low-resolution) contained within the same file. But the real power
of this file format is that you can extend it at will without killing
programs/games using an older versions. Just skip any header you don't know
while traversing through the file.
that's something to keep in mind. i'm going to look into the pvrtc compression before resorting to attempting something like this. i'm skeptical that i could be loading and unloading all of the required assets in a single update/draw cycle without a noticeable hit to performance/frame rate.
i appreciate both of you guys help on this. hopefully i can return the favor at some point!
Thanks!
I was talking with some friends and they really didn't like Andy's design, and I tend to agree. I made this new design, was wondering what people thought. Better? Worse?
I like the older sprite a lot more. I think the guy in a suits doesn't fit the wacky and colorful environments you've shown as much as the more casually-clothed guy(... I know, Braid...).
@Ihateyouchris: The new one looks better from over here.
further down the road again, even while using pvrtc. The approach I explained
is quite universal and can be used on any scale. About your performance
consideration; Don't fool yourself thinking that this is a slow approach just
because you read "files". You can likewise hold the .mac file, with its
compressed subimages, in memory as well. In this case performance is down to
decompress some subimage (stored in main memory) quickly. Not a big issue at
all. And last but not least, one can use an LRU cache (part of main memory) to
remember the recently used/decompressed sprites. Hence, no decompression
necessary for the most active sprites on the screen. Beautiful!
As you can see, the approach given can be tuned/balanced to the problem at
hand at various different levels.
Try pvrtc first, for sure. However, you may run in the same problem a little
further down the road again, even while using pvrtc. The approach I explained
is quite universal and can be used on any scale. About your performance
consideration; Don't fool yourself thinking that this is a slow approach just
because you read "files".
You can likewise hold the .mac file, with its compressed subimages, in memory as well. In this case performance is down to
decompress some subimage (stored in main memory) quickly. Not a big issue at
all. And last but not least, one can use an LRU cache (part of main memory) to
remember the recently used/decompressed sprites. Hence, no decompression
necessary for the most active sprites on the screen. Beautiful!
As you can see, the approach given can be tuned/balanced to the problem at
hand at various different levels.
Thanks!
I was talking with some friends and they really didn't like Andy's design, and I tend to agree. I made this new design, was wondering what people thought. Better? Worse?
The new one looks like a lawyer. Sorry, haha.
I'd try for a mix of both designs and see what comes up. You might find something more "interesting" in there.
Ihateyouchris
Member
See, I kinda like that contrast, with a normal looking dude gradually becoming more ridiculous as the game goes on.
*Whips out candy cane rocket launcher
"It's business time motherfuckers!"
Here are a few more variations. #3 is one I had made already, I was thinking of making him an unlockable character called Bram (Brother fRom Another Mother)
BomberMouse
Member
See, I kinda like that contrast, with a normal looking dude gradually becoming more ridiculous as the game goes on.
*Whips out candy cane rocket launcher
"It's business time motherfuckers!"
Here are a few more variations. #3 is one I had made already, I was thinking of making him an unlockable character called Bram (Brother fRom Another Mother)
6 or 8. For such a low res it might me important to show the eyes. You can make it blink when idle, replace with X when taking damage, etc.
Thanks!
I was talking with some friends and they really didn't like Andy's design, and I tend to agree. I made this new design, was wondering what people thought. Better? Worse?
I like the mixture of harsh chunky pixels with soft drop shadow!
I prefer the new, for no better reason than I like it more on first inspection..
I like number 4 a lot, and in contrast to BomberMouse's statement you still could totally do emotion with glasses, example being that when you take damage they could look cracked.
- Status