Archer (Working title) Devlog.

A little update.

Creating the whole map in Maya works, but exporting the whole map with textures included seems to be a bit tricky, as the whole map with buildings, rocks, plants and everything counts as one object, so the whole map has to use one massive baked texture, it seems. If don't do like this, editing the map in C2 is a pain, and i can't bake the Ambient occlusion shadows, which is pretty crucial for the feeling as I don't want a completely "flat" world with no contact shadows.

So now I have to chose.

1. Export all objects seperately with no baked shadows. (easiest but looks very flat, and tricky to place all objects in C2)

2. Export objects separately with AO, (a LOT of work to place them precisely at where they would contact the ground)

3. Export the whole map with one large texture map... Maybe i would need a texture size of 4096x4096. or even greater, so I don't know how well this would perform on Mobile, or if it will look good.

No3, is probably my preferred option, but not sure how it will perform or look, so I have to try it.

May 15 update.

Playing around with Q3D, everything seems to be working fine, but been struggling with level editing. I've decided to go back to 2D isometric, as any type of level editing with lots of small props and items placed all over the map at various height and sizes is too tedious to work with, since C2 doesn't support any 3D viewport. All of the benefits of Q3D, doesn't add upp when it comes to editing levels. As I can't get a clear view of what I'm doing, as the visual representation in the editor is lacking.

Hopefully at some point C3 will open up possibilities for plugin developers to make a proper viewport..... so ...

What to do?.

The main reason i tried Q3D was memory issues for mobile, as i wanted a lot of props, characters, animations, and sprites on the map, which was hard to accomplish given that I was aiming to use less than 100Mb memory. Currently my game was using about 50mb, and that's only with 1 character, and maybe a forth of all the sprites I wanted to use. So what's my next option?

* Lowering resultion. Instead of using highly detailed sprites, rendering the game at a resolution of 1280x720, i could save a lot of memory by lowering the sprite resolution. So looking for some feedback here? Should I go for really low pixel art 320x180 or 640x360? Check mockup image below to get an idea.

640x360 would use about a fourth of the memory, so that should be fine.

320x180 would be really pixelled but i would have even more memory budget to play with, for assets, animations, etc etc...

Should I aim for 640 or 320? what do you guys think? what would look better?

Based on the mock ups I'd go with 640

320 ruins the look of your game

Based on the mock ups I'd go with 640

320 ruins the look of your game

Thanks Yeah I think I'll go with that... I think I would save enough memory just by optimizing the assets for 640x360 instead.

Separating trees and other assets to - tree trunks and canopy, i could save a bit of memory as well, and mixing and matching, instead of using several full trees sprites in different variations. Characters and animation I could also separate to smaller parts, to save more memory, but a bit more work.

May 15 update.

Playing around with Q3D, everything seems to be working fine, but been struggling with level editing. I've decided to go back to 2D isometric, as any type of level editing with lots of small props and items placed all over the map at various height and sizes is too tedious to work with, since C2 doesn't support any 3D viewport. All of the benefits of Q3D, doesn't add upp when it comes to editing levels. As I can't get a clear view of what I'm doing, as the visual representation in the editor is lacking.

Hopefully at some point C3 will open up possibilities for plugin developers to make a proper viewport..... so ...

Drat. Now you have me worried, as I am getting close to starting the level design process with Q3D. Using block art and a top-down level layout I hadn't anticipated too much of an issue.

What specifically were you seeing that was giving you trouble? Was it doing things like trying to match up Q3D models with their shadows?

Also, I concur that the 640x360 looks a little better.

Drat. Now you have me worried, as I am getting close to starting the level design process with Q3D. Using block art and a top-down level layout I hadn't anticipated too much of an issue.

What specifically were you seeing that was giving you trouble? Was it doing things like trying to match up Q3D models with their shadows?

Also, I concur that the 640x360 looks a little better.

It's just that i have sooooo many objects of different kinds in different sizes from small pebbles, mushrooms, twigs, flower, to large houses, and trees. Placing all that on the map without any accurate representation of what it would look like until I press preview was my major turn off. If i had the patience I could probably pull it off. If I had a lot less assets and a flat level (instead of height variations as i was doing) it would be a lot easier. If you're game is pretty simple, and most assets are on the same plane, and similar size i guess it's okay. I guess my game is just too complex in terms of the details

That's my only issue... visual representation in the editor.

I just didn't have the patience to place something, preview, tweak position and scale, and test again for thousands of objects..

> Based on the mock ups I'd go with 640

>

> 320 ruins the look of your game

>

Thanks Yeah I think I'll go with that... I think I would save enough memory just by optimizing the assets for 640x360 instead.

Separating trees and other assets to - tree trunks and canopy, i could save a bit of memory as well, and mixing and matching, instead of using several full trees sprites in different variations. Characters and animation I could also separate to smaller parts, to save more memory, but a bit more work.

If there is any chance your game might end up being played on living room TVs, eg through androidTV/shield or even console then you might want to consider 1024 576, I found, unless you are specifically aiming for a blatant pixel art look, lower resolutions on big HD TVs just look too pixelated and expose a lack of detail you don't notice on smaller HD screens.

I found 1024 576 was a good compromise. It gives a sort of amiga500 higher res pixelart game look on big TVs.

If there is any chance your game might end up being played on living room TVs, eg through androidTV/shield or even console then you might want to consider 1024 576, I found, unless you are specifically aiming for a blatant pixel art look, lower resolutions on big HD TVs just look too pixelated and expose a lack of detail you don't notice on smaller HD screens.

I found 1024 576 was a good compromise. It gives a sort of amiga500 higher res pixelart game look on big TVs.

I was aiming for mobile to start with. All the assets are rendered in high res, so I could release a "HD" version later, for TV's and tablets. I just wanted to optimize the game to be playable on low-mid end phones without running into memory issues.

I wish there was a way to chose what assets to load. Now I have to settle for something that looks okay, on High end phones with big screens, but is playable on low-mid en phones. >_<

>

>

> Drat. Now you have me worried, as I am getting close to starting the level design process with Q3D. Using block art and a top-down level layout I hadn't anticipated too much of an issue.

>

> What specifically were you seeing that was giving you trouble? Was it doing things like trying to match up Q3D models with their shadows?

>

> Also, I concur that the 640x360 looks a little better.

>

It's just that i have sooooo many objects of different kinds in different sizes from small pebbles, mushrooms, twigs, flower, to large houses, and trees. Placing all that on the map without any accurate representation of what it would look like until I press preview was my major turn off. If i had the patience I could probably pull it off. If I had a lot less assets and a flat level (instead of height variations as i was doing) it would be a lot easier. If you're game is pretty simple, and most assets are on the same plane, and similar size i guess it's okay. I guess my game is just too complex in terms of the details

That's my only issue... visual representation in the editor.

I just didn't have the patience to place something, preview, tweak position and scale, and test again for thousands of objects..

Got it. I wonder if a lot of the really small stuff could be taken care of algorithmically?

FWIW, now that we aren't sure what is going on with X3M, I've been looking into what it would take to do a C3 port of babylon.js. It is a little overwhelming, but I think it might be easier to create the necessary plugins for babylon.js rather than three.js. I'm definitely not the ideal person to start the process of creating a set of 3D plugins for C3, but if no one else volunteers I might consider taking on the project.

I think it would be wise to wait until we have z-ordering capability in the editor though.

cjbruce Yeah both of the 3D plugins for C2 is pretty good. I understand that scirra don't want to make Construct a 3D editor, but I do keep my hopes up that somewhere down the line they would consider adding some functionality that plugin creators to make use of, to get a better viewport for those plugins

For now I'm going put my efforts aside with the 3D plugins. Technically it works great, with good performance, it's just the editor that doesn't support it fully yet, so it's tedious to work with.