Mighty Megadoubts

Discuss game development design and post your game ideas

Post » Thu Nov 17, 2016 12:00 am

So for more than two years (three? a thousand?) I've been intermittently working in this MEGAQÜEST o' mine. The idea was to do the game whole into one single sandbox level. Backgrounds, as megaqüesters worldwide well know, would be random, same as music. Eventually the player would be able to unblock new ones, and some songs and backgrounds would be unique of certain locations in the map. I wanted also the game to be rather minimalistic in mechanics: jump, walk and attack (three arrows + one action button) should be all. Not even a secondary button for abilities or spells. Rocknrawl. Similarly, aint no inventories whatsoever: one item replaces another.
This approach was challenging and interesting, developer-wise. A bit too challenging sometimes! But the final issue that has me considering a dramatic change in my scheme is (alas!) mobile performance. Yes, I've optimized it right enough (with no little help from many of you guys), to the best of my ability, which aint much anyway. Objects are only active at a certain range from the player etc. But as soon as I began to place barrels and kegs everywhere (its a big map) all my optimizations proved useless again. I have an objectCount of 3800. But even worse: for the idea I have in mind, there's gonna be many (many!) more, so my problem, rather than how-to-handle-4k-objects is how to handle an indeterminate number of objects in my canvas. “Can't” being a very real possibility too, I figure. In that case I guess that, with bitter pain in my heart, I'd split my sandbox into different stages, which would force me to reconsider a lot of basics, and ultimately would mean another waste of time work and effort (not the only one so far, not even the worse... the second or third worse. Most of them are of course followed by several months of crippling depression and detachment to the whole project).
So I'm not sure of what shuddadoo. Not even sure of what I'm asking here either. I'm facing a dilemma: option A may be unattainable, option B would mean lots of stuff to be redone. I feel that everytime I optimize it up its all just a little bit slower than the previous time... and when I compare it with the older versions, where maps where smaller and things went smoother an life was happier, I get depressed.
Any musings?
B
23
S
11
G
6
Posts: 181
Reputation: 5,010

Post » Thu Nov 17, 2016 2:00 am

On those barrels and kegs you are placing, do they HAVE to be at those places? or just setting them randomly? in such case instead of just placing them when you are creating the game, why don't you code it to have them created at random?? that way that many instances wont be on the game from the beginning, but instead triggered to appear at certain times when the character is near an X object or place. You don't have to place 1000 barrels on the layout, just have one and then code a random creation every X time or place accordingly to the character, or whatever is best for your game, would save memory I believe that way
B
39
S
14
G
4
Posts: 174
Reputation: 4,191

Post » Thu Nov 17, 2016 3:29 pm

@arcab072081 Thanks for your answer! Unfortunately, kegs can't be placed at random places. It's not that they need to be at specific points, it's rather that they dont look good just anywhere – and of course they should be on floor too. Sure must be some way, but wont be easy to achieve – not without arising other brand new performance pains. Anyway kegs are no there all the time, they appear when a “proximity box” hits a “token sprite”. But still there's that collision to check. I have not mentioned, the idea is to make everything “autorespawnable”, as it's likely that the same area will be walked through several times.

But see, it's not just kegs... I'm doing something that I thought was pretty cool for the freeversion of C2, with its event limitations, but now that I got me a licence I'm wondering if it wont be causing more trouble than good.
In the early days I decided that all the enemies would be but different animations of the same sprite, and each enemy attributes would depend on instance variables (class=”orc”; hp=”8”; etc). Same applied to items.
Now in the bigger version im working on at the moment, I applied the same philosophy to a new class of sprite, called miscStuff. And miscStuff is everything from kegs to chests to lamps or gates or ships. Each class has one animation, although many are static, and most of them have some rules, which can be as simple as “enable jumpthru”, or more complex things like triggering a function that moves certain elevator, for example. This miscStuff sprite has the following (str) variables: class (“chest”, “lever”, “bonfire”...), then aux1, aux2, aux3. These aux variables can be different things, depending on the class (treasure from a chest, parameters for a function, the hit strength of a trap...).
And (oh surprise) this miscStuff is what's giving me performance pains. Enemies are under control, as they always appear at the same distance (proximity box1) form the player. But then some miscStuffs are doors that you need to open with a key, and I dont want to have them reclosing emselves everytime you get 960 pixels away. So we get proximity box2. Then for some other stuff I want something intermediate, that's proximity box3... I try to use the smallest one whenever possible, as it affects obviously less objects.
This means that I have less than a dozen of visible animated sprite types (not counting invisible boxes or hud elements). That looks good, but there are many instances of them, and the code for each is quite complex, so as I said I have growing concerns about this technique. I wouldnt mind to reconsider it – this or any other thing, really, but it would be very frustrating to take the pains and split all the miscStuffs into many different sprites, then adjust the code accordingly, to finally discover that performance's still shite (or even got worse. That stuff happens).
After all, if I was to split my game blindly, not knowing if it's gonna run better or not, my bet would be on the layout, which I think would be the surest way to improve my fps.
B
23
S
11
G
6
Posts: 181
Reputation: 5,010

Post » Sat Nov 19, 2016 7:12 am

Have you tried using families, to condensate several objects or sprites that have similar attributes? Or maybe like you said the issue might be the many instances or sprites you have running at the same time. Maybe you need to lower the size of them? There is a blog, or tutorial called "dont waste your memory" or something like that, talks about having images too big, or heavy. And how to counter some problems they might give, you may wanna give it a read
B
39
S
14
G
4
Posts: 174
Reputation: 4,191

Post » Sat Nov 19, 2016 1:27 pm

@arcab072081 thanks again for your interest mate. Yep, I've been re-reading several blog entries like that and I'm making some improvments. So enough with the wailing and the moaning. Main problem is im no coder, and find it difficult some(most)times to understand how javascript will react. C2 makes it easy, but i guess you still need a bit of lore sometimes...
B
23
S
11
G
6
Posts: 181
Reputation: 5,010

Post » Wed Nov 23, 2016 10:01 am

It's sounds like you're going to run in to some major memory and performance issues if you're going to keep it all on one big sandbox map. Especially if you are developing for mobile, since there's no way to unload graphics from memory. (Except from changing layout. As far as I know), As the object count grows even just picking objects will become heavier and heavier.

I think you have to rethink the huge sandbox map approach. There are ways to Optimize huge maps, but on mobile it's not really good, since you're limited by the memory. Turning on render cells is one thing, but i doubt it will do much difference.

Another approach might be to load graphics externally by using "Load image from URL" in the sprite actions. That way you can probably replace the URL based on what area you're in. If you're in a "Snowy area" you're loading the snow sprite. If you're in a desert area, your replacing the image with a desert sprite. I have never tried that out myself but might be a solution.

Another way could be to load your whole map from to an array from an external file. That way you can keep the whole world map on a file and your layout can keep a minimal size. (Approximately a bit bigger than the size of your screen) Anything outside screen is not loaded. So if you move across the map. You just update what cells are loaded, sort of. Anyway it's just theorycrafting, but I think that could be a way.
Follow my progress on Twitter
or in this thread Archer Devlog
B
42
S
18
G
19
Posts: 1,061
Reputation: 14,056

Post » Wed Nov 23, 2016 10:12 am

[__o__.XX___v______T___y__________________MM____________5____o______A________zz___ _____] <- Your whole level in an external file
______[XX]__________________________________________________________________________________ <- is what's loaded to your layout.

You load from the above line (external file) what should be shown in the layout.
As you move across the line, anything outside the layout get's deleted, and new stuff loads in according to the level file above.

That way you can pretty much have a MASSIVE size level, but your layout only shows the necessary stuff.

Hope that makes sense.
Follow my progress on Twitter
or in this thread Archer Devlog
B
42
S
18
G
19
Posts: 1,061
Reputation: 14,056

Post » Wed Nov 23, 2016 2:25 pm

I am not expert, but as they guys say above. By the sounds of it, for levels as big as the ones you are talking about then you want to be mapping them into arrays. maybe even a couple, eg one for your maps, one for item placements and states, one for enemy positions and states etc. You can continually update the arrays in real time and just display whatever is in/near the window. I'm sure that's how some of the old-school games would have done them. Makes save games easy to do as well. Sadly would probably need some major reengineering of your code and development of a level editor, but would also give you much more freedom and speed for level development. All part of the fun no????

also , I am sure you have implemented already, but for mobile, as recommended elsewhere on this forum. using a low resolution with fullscreen scaling = no, high DPI = no, sampling = point, downscaling = low q, clear background = no can get you back up to acceptable frame rates for games with a lot of sprites. Though your issues seem to be related to size of the levels rather than graphics.
...
B
47
S
25
G
7
Posts: 365
Reputation: 8,436

Post » Wed Nov 23, 2016 7:00 pm

@NetOne
@tunepunk
@arcab072081

Well thanks a lot for yr answers and tips guys. So yeah I red this blogpost about collision (or was it draw) cells and thought the sky was the limit. But load levels from arrays...! That's rocket science for me :/ Do you fellas know a good tutorial or... ah nevermind, i'll have a look meself. Btw when you say "load map from array"... whatya mean, the whole layout? Or... the different layers of sprites instances? My basic scenery is all included in one single tilemap object... and (as usual) i dont know if thats a good or a bad thing, performance-wise.

Id really regret to have to split it apart in stages, coz the sandbox concept is one of the main points of the game, in many ways. I even did consider hiring me some thug (programming thug) from the forums to do the job... but Im not sure i could bear sharing my prrrrecious with somebody else XD Also, buying one of those natty game templates they sell in the store (and iv never even been in the store yet), if i could find something that fix me. Anyways I'd like to try myself first, so i'll have a look at this "level from array" stuff -- and see if i can grasp it!
Thanks again! y'all rock!

PS: Hey here's an unofficial, very incomplete, glitchy, bound-to-be-destroyed-in-a-couple-of-days demo of the game -- if you wanna see what youre helping me to achieve, hopefully. As you see, there's still large empty areas still with no enemies or objects (and many more straight undone), and the tilemap is not finished either -- which means that everything's gonna be much worse, in performance terms :/ still, should flow alright on pc...
B
23
S
11
G
6
Posts: 181
Reputation: 5,010

Post » Wed Nov 23, 2016 11:51 pm

Dude!

1) Game looks awesome so far definitely worth persevering with, especially for mobile.

2) I found this video on YouTube which shows a simple construct 2 level editor using arrays. It's not rocket science. They're just data stored at coordinates like a spread sheet. Once you understand writing to and reading from arrays you can adapt it for anything. I've not played with arrays in construct yet. But looking at the video they look reasonably straight forward to implement. https://youtu.be/2kQ27MZ-6nA
Dunno tho if this will help tho. run a test first to make sure. I thinking your miscstuff spriitesheet approach could be causing you issues as you say. I do recall reading sonewhere on here that mobiles don't like large spritesheets. I think you'll need to find someone with propper mobile experience on here to confirm. I'm just a noob so will shut up now....
...
B
47
S
25
G
7
Posts: 365
Reputation: 8,436

Next

Return to Game Development, Design & Ideas

Who is online

Users browsing this forum: No registered users and 1 guest