Loading times

Basically, the game I'm creating requires an extremely lengthy loading process. I'm just wondering how long people are willing to wait for a map to load (note- this will only load ONCE per play, unless you decide to start a new save)?

The game itself would be quite complex (performance doesn't suffer except for that initial loading hit, so there aren't any limitations there).

It depends on how good the game is.

It depends on how good the game is.

Agreed

Doesn't matter if you quit before it completely loads. I'm looking for the time it takes for someone to give up on the game loading the first time that they play. Doesn't matter how good it is if you left before you started.

I disagree, the quality of the game can influence wait time. Granted, it's impossible to know personally if it's good or not, but word of mouth, portal ratings, viral spread, etc. all can influence the perception of a game in advance of encountering the loading screen. If there's enough want, they'll be willing to endure more wait.

On release, a bunch of people claiming the game wouldn't load would definitely kill ratings though.

I don't exactly have a portfolio of past successes.

As long as it's only once per whole game, I don't think it's *that* horrible! O.o'

However, having some sort of progress bar could make the waiting much more pleasant. Adding some funny text describing what supposedly happens during that loading process would help as well, but generally it would be good to give some approximation of how long the player is supposed to wait!

By the way, what is the map which takes so much time to load? Perhaps it can be optimized somehow, or at least split for a few more series of loading (as in, the territory which hasn't been generated yet would be generated at the time of visiting and then saved for eternity)? ^^'

The problem isn't my calculations, it's the tile API. All calculations happen within 1-2 seconds, but the tiles being drawn will stall the program for about 30-40 (we're talking about a small map here, large sized ones would take forever). I've managed to eliminate the problem where the game would literally give up on calculations and give you a half-finished map by spreading things out, it draws one "slice" of the map per frame.

Pleasantly funny text is planned (along with progress bar that totally does not move backwards every time you look away).

I suppose I could use the tile API to render things in chunks, but I'm trying to minimize calculations during gameplay because of all the stuff that has to happen.

I think as long as the player knows it's doing something (instead of being stalled or frozen), doesn't take more than a minute, and doesn't happen too frequently, they shouldn't mind.

Hmm...

1) Do tiles take part in some sort of collisions (in other words, do they matter for the game mechanics or are only for visual purpose)?
2) If so, do they have other collision shapes than tile-sized rectangle?

I ask, because I wonder whether it wouldn't be possible to use 2D Array system (for keeping information about tiles) and lagless actorey thingamajigs (to draw proper tiles at given places). If they were taking parts in collisions, things might get more complicated, but hopefully not too much! >.< However, if tiles have irregular collision shapes, there really isn't much which can be done. ^^'

The act of editing a tile on the map takes a long time. I run through a 2D array with the map's tiles in it. Creating the array doesn't take long, but making tiles appear takes forever.
I've only been working on map generation so far, so there is no collision. It just renders empty tiles.

By rendering less tiles (say, if the item on the map says 0, then I don't change the tile I'm looking at), things are a lot faster. It still takes a while if I want to make something big though.

EDIT: There will be actual collision with the tiles once the game is done though.
EDIT2: Going to bed. Sickysickysickysick :c

Drawing tiles with no collision shapes should be very fast (you can redraw an entire screen of 32x32 tiles each update with very little cost). What size are the tiles? Is it actually the tile drawing that causes the slowdown, or some logic in the behavior?

Be aware that tiles created at runtime like this have their own collision boxes and are not combined into larger shapes, as they are when placed in the scene designer. This can cause all kinds of problems if you intend to enable collisions, including a massive performance hit.

Just before I go:
tiles are 4x4.

For testing purposes, a maximum 36864 tiles are drawn (192x192) it's usually around 3/4 of that, so roughly 27000 tiles are edited. Maps are planned to be 1024x1024 (over a million tiles). I'll probably have to work out some sort of chunk-loading system for that.

4x4 pixel are maybe the smallest tiles i have ever seen o.o

§To ease waiting you can make also simple mini games like popping bubbles or dodge falling spikes.They are often so soft that don't slow at all loading times, and makes the waiting part of the game.
If done really well people won't play your game, they'd just keep playing the preloader

Four... times... four... tiles? O.o'
Yeah, I can see how, like, 15360 calls per 640x384 screen can increase render time. O.o'

Also, what is the largest screen size you're going to use? I ask because I wonder whether single BitmapData could cover it all, thus making it possible to draw all these tiley thingies at the very beginning and then only copying the visible fragment onto another bitmap, which would be then displayed during Drawing cycle. Should be this done in the most crude way (as in, the whole screen-sized fragment would be drawn on the "display" bitmap, then that bitmap would be drawn again in Drawing cycle), it should take 2-3 screen drawings per cycle.

Also, I've done a little test, and on my machine drawing 640x360 image 25 times (which is supposed to represent 24-25 screen drawings per cycle) takes about 12-13 ms to render at worst, with both player and browser checked. If you want to check how it runs on your machine, you can get "Efficiency Test" behavior on Forge I just sent. ^^

(and what type of game is that, anyway? There's a huge difference between tile-based Sokoban-like collision and shooter-like pixel/rectangle precise collision ^^')