Refeuh's Forum Posts

  • Hi !

    I might get this wrong, but why use physics at all If you have a match-3 puzzle-style game where everything is nicely grid-aligned, you can just manage the board state yourself (arrays, etc.) and write a simple "move" behaviour to get your blocks to fall down. Assuming the blocks have a predictable motion (e.g. all come from the top and fall perfectly vertically, etc.)

    This would much MUCH less expensive in terms of computations. You really want to keep physics only for situations that require it, e.g. when you don't control the environment, when you want projectiles or entities with realistic behaviours, vehicles, etc. For a board game, create your own representation of the board.

    'Hope that helps !

  • Same here after working for a long time with C2, the editor becomes unresponsive and slow.

    I found a workaround though - when I start to feel the UI is getting sluggish, I change the skin/theme, that seems to force a refresh of the widgets and you're good to go for another few hours !

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Saving the project structure works well enough, as long as team members compartmentalise their work and avoid convoluted overlapping changes. I would recommend developing new features on separate prototyping layouts/sheets, and only do a proper "manual" merge if necessary when everything is in place.

    Also, I would strongly suggest to use an actual versioning system, e.g. Bit Bucket + Smart Git, or any other good alternative you are familiar with. Just make sure you set it up to ignore all "ui" and backup files, otherwise these will "pollute" the history log when searching for diffs

  • Hi there !

    [quote:o08987nw]I've never seen an game engine where you can implement networking that easy!

    I totally agree And it's really easy to understand as well, with the very detailed tutorials explaining the design of the multiplayer module. Coming from a background of low-level programming, that certainly is a change !

    Anyway... I don't have much to contribute to the initial question, but I was wondering about the "dedicated server" idea. While I understand the principle (ensuring you're the host by being the first to join the room, etc.), and while I have some knowledge of general networking, I have little expertise of server-side technologies (the typical light-PHP and simple databases).

    If I were to do something like you describe, there are some questions I'm not too sure how I would deal with... For example, I guess there's always a risk of the "server" (i.e. host here) crashing or losing connection. Does that mean you need some kind of a daemon process to monitor the session and spawn a new "host" if necessary ? Or maybe there are infrastructures that guarantees your server will always be up (e.g. using some black-voodoo-dark-magic stuff like the popular Amazon AWS) ?

    If you have a few minutes, and don't mind sharing some infos of course, I would really appreciate a quick overview of the kinds of technologies / services you need to build something reliable to support this idea.

    Regards

  • Brilliant, I will need to look again at the windows desktop exporter soon, and I read here and there there were issues with the node webkit package ; these instructions will surely prove useful ! Thanks for sharing your process.

  • I believe layers are not synced ; they shouldn't move if created the same way, but you can force your objects on the right layers locally on each peer, like in the multiplayer pong/shooter examples.

  • I think productivity of the existing tools should be an obvious priority, if not the priority, for future developments ; time saved by developers creating games can be spent on project-specific needs, e.g. advanced optimisations, integration of 3rd party plugins, getting obscure platform exporters to work, etc. This would be easier for game developers with a technical background, but would benefit the entire community, as it already does.

    If we focus only on some of these modules, only a subset of the C2 projects will benefit from the improvements, while at the moment that are still certain aspects of the IDE that are a bit clunky and that are clear "time-wasters"

  • Personally I think C2 does exactly what it says it does - nothing more nothing less, and it's the right balance between productivity and functionalities.

    I wouldn't want C2 (or C3, as people start to talk about C3 which I think would be a bit premature) to become what it's not ; there already are other solutions if I want to target native features, do 3D, actually program, etc.

    I think it's all about user expectations, and there are 2 points in particular that keep coming back :

    • Multi-platform ; cross-platform development never works easily and perfectly ; all engines or technologies advertising "write once deploy everywhere" have their flaws and specific issues. Targeting HTML5 is a clever choice ; it works at least as well as other solutions and has the advantage of moving a lot of the complexity to 3rd party companies. I see it as an advantage because these companies have a lot more man-power to burn to develop technologies ; it means we depend on solutions we don't fully control, but without HTML5 and theses companies there wouldn't be crossplatform at all in C2.

    I have worked with in-house engines used for AAA consoles/PC games, and we always needed dozens of full-time senior programmers just to maintain the platforms. C2/HTML5 has its limitations, but it's not greener on the other sides ; it is viable and is the "clever" choice for a small company, and it will continue to improve in the future as part of the evolution of web-technologies.

    • "no programming" ; I'm always wary when a product advertises "no programming required", and C2 falls in this category. Whether we actually write native code to compile, scripts to interpret, or events, it's all the same : programming is about designing solutions, manipulating data and implementing algorithms. That's exactly what we do in event sheets, even if they hide a lot of the complexity (few data types, objects only expose suitable operations in a given context, etc.)

    Hiding the actual complexity also means that lots of people rely almost exclusively on the built-in behaviours, and we end up with lots of requests to make new behaviours, or make existing behaviours work like this or work like that, etc. And while these requests all seem sensible in a given project, they usually conflict with each other when looking at the big picture.

    I would be in favor of exposing a bit more of the building blocks to let people come up with their own behaviours more easily. It would still be a lot easier than programming, but would require people to actually understand how things work to adapt to their needs.

    As a final word, my "only" request for the future of C2 would be to improve the productivity of the editor when writing event sheets ; at the moment manipulating data, using variables, writing small algorithms, etc. is a lot more painful than it should, and there are lots of *small* things that could be done to make it a much more enjoyable experience. That an a real debugger to go with it ! Not being able to trace certain control structures is a real time-waster.

  • +1

    Same issue as previous posters ; working with 8x8 tiles is very impractical, you need the image opened in parallel with a different software to locate the tile you want and then guess where it is in the C2 tilemap window...

  • > 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