> So stop developing C2 - it is flawed because it is HTML5.

> Start work on C3, and go back to targeting the OS, Win\Mac\Linux.

>

I think this might be the wrong engine for you if that is how you feel.

Agreed ; the whole idea is to target a technology that is, to some extent, portable. This pushes a lot of the complexity onto external modules. As soon as we start questioning this philosophy, we start talking about a whole different engine and set of tools.

So yes, relying on web-related technologies can be annoying and frustrating at times, but it is still much much much simpler than developing a cross-platform engine using native solutions and/or custom abstraction layers. Unless we drop the multi-platform aspect and focus on one or two desktop solutions ; but that wouldn't be Construct anymore...

Just having some rendering and shaders that work on both OpenGL (for desktop, and ideally on Windows you'd really want DX11, given the state of the OGL plugins...) and OpenGL ES (for mobile) is a significant amount of work and a major pain in the rear as it breaks as easily as HTML5 with OS-updates...

Scaling, up or down, will always introduce some form or visual degradation. There's no easy way around it, and it's directly related to signal processing theories, with aliasing, interpolation, convolution kernels used for filtering, etc. Also, it seems you're using non-uniform scaling, i.e. stretching, which increases the loss of quality from a perception point of view.

The best working practice is to author resources at the scale they will be displayed at runtime, or close to it ; it's true in both 2D and 3D - there's no reason to have a 256x256 resource to display a 32x32 sprite (which will probably lose the noticeable features and would require pixel art), just like there's no reason to have a 64x64 texture to display a full-screen character 3D model that would require a set of 1024+ textures. Filtering will lose important details and introduce artefacts.

In cases where the asset needs to support wildly different resolutions, usually it is recommend to author multiple sets of resources manually (or using a process that requires human interaction, to control/tweak/maximise the quality). In professional 3D games, certain various mip-levels for important textures are authored by an artist, and not just computed.

It is always possible to scale resources using more complex algorithms (e.g. larger spline-based kernels, etc.), but it quickly becomes too intensive for runtime usage and should be kept an offline process.

Sorry, I couldn't open the .capx, I'm still on v190 - Which behaviour are you using for the motion ? Bullet ? Path planning ? Custom ?

If you're using a Bullet-type movement, you can get a simple but effective "follow" behaviour with just something like :

Enemy | Set Bullet angle of motion to angleRotate(Enemy.Bullet.AngleOfMotion, angle(Enemy.X, Enemy.Y, Player.X, Player.Y), angularVelocity*dt)[/code:n7kt9wge]
with angularVelocity a variable you control to cap the turn rate in degrees/sec to prevent entities from turning too quickly at short angles and get nicer trajectories.

As for getting too close to the target, I would suggest handling that with a simple finite state machine :
state 1 - far from the target > use the Bullet/Follow behaviour ; if close to target, switch to state 2
state 2 - close to the target > do something else (short range attack, etc.) ; if far from the target, switch to state 1

A "follow"-type navigation behaviour when close to the target will always cause problems (overshooting, spazzing out when trying to correct, etc.)

'hope that helps !

Check the manual for the optimisations performed at export time. It does include a stage to process the sprites into spritesheets

Functions are definitely a possible alternative or work-around using the existing features of C2. Though using them only for breaking down formulas or re-using bits of computations multiple times, I think they're a bit overkill, especially when there's no parameter or actual logic involved.

'Just a small suggestion to help keep things neat and tidy

[quote:3fc6xn1c]also to be able to do it in object Properties

Indeed ; it would be very convenient to have this on global/local variables but also member data on objects !

Hi !

I don't think this is currently possible, so I'd like to suggest a feature to let us initialise variables (local and global) with expressions, instead of "pure" number values. A variable would take the value of the expression when the expression is evaluated when entering the scope of the declaration.

When writing custom behaviours for movement, clipping, etc. I find it easier to use local variables to keep the events readable and maintainable, esp. for temporary values that are used in multiple computations. There are lots of formulas using "sprite size" +/- various offsets +/- arbitrary numbers +/- scaling factors, and it's much quicker to write the expression just once.

At the moment I find myself writing a few :

local number foo = 0
(empty) System > set foo to "exression"[/code:kjk7jnxa]
Which is a bit clunky ; it would be much better to be able to specify the expression directly as the initial value for the scope of the variable. Also, this prevents me from setting the variables as "constant", which again would help with readability and maintainability.

If there's a better way, let me know, otherwise I believe it would be a great addition.

Thanks for reading

Some details here :

www DOT scirra DOT com/tutorials/577/construct-2s-export-time-optimisations

(tss, I can't post links apparently, and I don't know why it doesn't take it as plain text instead of clickable...)

GPU details are available to registered developers ; which unfortunately excludes hobbyists and most sole/indie programmers.

Maybe check the DirectX SDK docs, they're usually full of general "good advice" and up-to-date "best practices" when it comes to managing graphics resources. Obviously it doesn't cover engine specifics (for example the padding here already mentioned by Ashley), but it gives some understanding of the inner working.

Though that's only true on PC... For mobile chips, good luck understanding anything at all ; between the Android and Apple, the PowerVR and whatnot, they're all different even across the same family.

Hi !

it's a very general question - I won't provide a specific answer, but some guidelines depending on your scenario.

If by "all the scores" you mean the scores of the players in that session, the host should have all the relevant information. The ending screen with the scores is then just a special scene with no gameplay and very simple logic for limited interactions

If by "all the scores" you mean the scores of all the players including previous and other sessions as well, what you need is an online leaderboard. There are some good tutorials about this, but roughly you'll need a simple database hosted and a basic server and a connection between your game host and the shared leaderboard to look up the top scores

'hope that helps !

Fair statement, and I don't deny it's a sensible request, but I think both points of view can be valid. In the end it's all about what features people think are or are not part of a "default" behaviour. Which is obviously very subjective.

Continuing with the platformer example and the functionalities mentioned previously, many games these days have ledges, ladders, double-jump, etc. Does that mean they should be included in the default movement behaviour ? I don't know ; and I don't think there's a black/white answer to this. There's a trade-off, and a balance to find between components doing too little/too much and the amount of "glue" logic the developer needs to implement.

My worry would be to end up with "monolith" components that try to do too much and become hard to customise every time your scenario doesn't fit nicely in the expected use-cases. If I was designing the underlying modules, I think I'd try to make the "slope/sliding" movement logic bit a separate behaviour (purely reactive, unlike input>movement) that you can add, or not, to the entities. That'd avoid unnecessary coupling in scenarios where this features is not required.

"My personal issue with 8 direction is it rotates sprites"

This is actually a parameter on the behaviour ; it can be disabled, or set to preset values (smooth, 45 or 90deg. angles)

As for the request itself, my feeling is that behaviours and components should remain as generic as possible, letting the end-user achieve the desired results with a bit of custom logic where necessary. Anything beyond this becomes too specific or too convoluted to be practical.

Typically in a game, there will be surfaces that can have wall-slide, and some that don't ; ledges you can grab, and some you can't ; some areas that cause slipping/sliding (ice, etc.), and some that don't. Etc. We don't want behaviour parameters for each possible scenario, that would be clunky, and would imply coupling between concepts that need to remain separate (e.g. character movement <> environment mark-up).

Can you re-create Metroid, Castlevania, Mario, Megaman II and Zelda II, all 2D side-view platformers, with the *same* player behaviour ? Hardly, because each of these have different requirements and work in different environments. You don't want a player behaviour that handles "everything" ; you want a flexible base you can customise to your needs, and that's what movement behaviours are.

I would second Tokinsom ; I really think C2 should focus on the game development process, i.e. the integration of resources and the ease of use to write behaviours, nothing more.

Most of what you are asking for can easily be done already very simply, and providing built-in behaviours for these would be too restrictive for other use cases.

What if I need a button with 3 states ? 2 states with a delay when switching ? etc. All these variants are impossible to implement as default features, and are much better done with a very simple bit of custom logic and events

Also, any kind of resource *authoring* should happen outside of C2. There's plenty of options and software to author sprites, images, animations, etc. already ; C2 doesn't need to try to compete with these specialised tools, it's wasted effort and it's budget that doesn't go into the game "making" module itself. It should focus on resource integration and productivity of writing game logic.