Refeuh's Forum Posts

  • Jayjay : there's a conflict of requirements between designing desktop/console games that "need [the] extra content and CPU" and targeting the "dual-core CPU with HD4000". By essence applications made to run on low-spec hardware should be stripped to the bare minimum, without the extra content and cpu-intensive stuff, to ensure it runs well.

    Btw, have you profiled your game to see why it performs badly on some hardware ? Maybe it's just a bottleneck that can be avoided or worked around

    Some very good showcases are progressively appearing ; I'm thinking The Next Peneloppe by Aurel, CopyGirl and the Metroidvania Gamekit by Tokinsom & 7Soul, etc. This proves moderately complex games can be made to perform well.

    Native and platform specific optimisations are always done last on a game project, and they don't account for that much in terms of performance boost. Optimising the content and reworking the algorithms usually do most of the job.

    Additionally, depending on the hardware, well designed content, good logic and native tech sometimes aren't even enough. For example a specific generation of mobile devices was absolutely terrible at processing certain types of graphics things (few and poor pixel processing units, abysmal texture read operations, appalling blending performance, etc.) ; to work on these devices, entire sets of art assets needed to be reworked to avoid this hardware limitation ; basically spreading the cpu/gpu/ram/vram load differently. Just an example, but typically this is an extreme case of something a tool cannot do.

    It's impossible to create complex games easily ; the complexity of the underlying technology always reflects the complexity of the games. Which also means a stronger constraint on the user to understand the technology in order to use it efficiently.

    Ease of use, functionalities, efficiency, portability, cost, etc. One single solution cannot do it all, because these are conflicting requirements.

    There are already lots of other solutions to create games - native programming frameworks, portable engines, visual tools, complex modular editors, etc. C2 fits nicely between all these and provides a good answer to a collection of problems.

  • Thanks for the comments - I am in the process of implementing a collection of small changes (mostly balancing, legibility, etc.) based on the feedback of a first targeted focus group.

    I am almost done with this iteration ; expect a demo within a couple of days !

  • I guess this can be used for monetisation, microtransactions, etc. And when it comes to online payments, a regular browser feature, I'd rather it to be part of a widely spread technology (Chromium/node.js) rather than having to rely on less-used 3rd party addons which are more likely to have flaws.

  • Hi -

    people will need a .capx to investigate the problem

  • As a non-linear platformer in a single large world, Parasite definitely shares a certain amount of core gameplay mechanisms with the Metroidvania genre ; though I would also mention that the player abilities are all unlocked reasonably early in the game, making the "skill hunting" phase much quicker. It is then up to the player to use his abilities to navigate the environment, progress in the various available areas, collect bonuses, find secrets, etc.

  • No rush, but it'd be nice to have a confirmation on this bug ; the only work around at the moment is to modify the level design to avoid these "corner cases"

  • Another tip if you want to go "OOP"-style ; I'd recommend having a "ClassInterface" Family that only adds a s_className to objects. You can then use Families as interfaces and use the s_className to call appropriate functions (e.g. "call FooIF.s_className + "BarMethod(uid, param1, param2)" ") implemented in the objects' relevant event sheets.

    Therer no encapsulations, so it's all about working practices to keep things tidy really.

    Think about how it was done in C to have a "OOP"-like structure, with custom typing mechanisms and emulated function tables.

    I actually wanted to write an article about this ; if that's not sufficiently clear in this post, I should publish more details soon-ish

  • Thank you for the first impressions -

    The lovely visuals are courtesy of a couple of great talented pixel artists. Having received confirmation from most of the respective authors, credits go to :

    PIXEL ART

    Adam "Atomic" Saltsman

    http://adamatomic.com/

    Environment

    Christopher "Oryx" Barrett

    http://oryxdesignlab.com/

    Characters

    AUDIO

    Victor "Snabisch" Navarro

    https://makeagame.bandcamp.com/

    Music

    Jesús "Jalastram" Lastra

    http://opengameart.org/users/jalastram/

    Sound effects

    My initial focus test group provided sufficient feedback for an initial iteration ; I will implement a collection of changes (mostly balancing, legibility, etc.) before widening the tests.

    More to come very soon <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

  • I belive this might be fixed in r214 : https://www.scirra.com/construct2/relea ... lease_r214

    Careful it's still beta...

  • mudmask : fixed ! All image links clickable for bigger versions. Sorry for that :/

    I will also try to record a video and make a short montage ; the very low resolution (160x88) makes static screens feel less "legible" than it really is in motion.

  • Also, if I have time I'll try to write a couple of articles regarding C2 development ; especially one about what I would call "EOES" (Entity-Oriented-Event-Sheets) to help organise the gameplay logic, and another one about using Families as "abstract interfaces" to promote and factor common code while keeping maximum flexibility.

  • Hi all,

    I'm here to talk about Parasite, a small project I've been working on my own for some time. The game is currently playable but not available publicly as it requires a bit more testing.

    ***UPDATE 06/11/2015*** Final demo

    • Core mechanics update (energy, morphs, etc.)
    • More content (x2 playable area)
    • Additional story elements
    • New enemy types
    • Improved resources
    • Keyboard configuration
    • Customisable visual style (scanlines, bulge, etc.)
    • Endless list of balancing and level design tweaks, plus various bugfixes

    Previous focus test demo is no longer available

    New demo shows ~15% of the game content (tutorial area + 1 out of 8 modules)

    Browser demo

    Recommendations : up-to-date Chrome + Xbox360 compatible gamepad

    https://dl.dropboxusercontent.com/u/526 ... index.html

    Desktop demo

    Recommendations : Windows 7/8/10 + Xbox360 compatible gamepad

    https://dl.dropboxusercontent.com/u/526 ... emo0.9.zip

    OVERVIEW

    Parasite is a non-linear retro platformer with a mix of action and puzzles. The player controls an alien worm wanting to get rid of a human space colony on his planet. There are multiple shapes to unlock and to switch between to facilitate the navigation and sabotage the complex.

    SCREENSHOTS

    KEY FEATURES

    • 4 unique environments with their own specificities
    • 4 shapes to unlock, each providing an exclusive ability
    • Non-linear level design allowing for routing choices
    • Use health as a resource to change shape and work around obstacles
    • Integrated timer, for the speedrun enthusiasts
    • Deactivate all 8 station modules before too many humans can escape !

    FACTS

    • Estimates play-time : ~2h for a first playthrough (complete game, demo is ~15%)
    • Playable area : 1 giant level, ~250 accessible screens
    • Variety : 20+ types of "gameplay" entities - enemies, traps, interactions, etc.
    • Development time : ~3 months
    • Team : myself
    • Development tools : Construct 2, Tiled, PyxelEdit
    • Production tools : Trello, Toggl, SmartGit, BitBucket, OneDrive
    • Technology : HTML5, playable in a browser or on a variety of platforms after export

    CREDITS

    Adam "Atomic" Saltsman

    http://adamatomic.com/

    Environment

    Christopher "Oryx" Barrett

    http://oryxdesignlab.com/

    Characters

    Vesa "Master484" Vanhatupa

    http://m484games.ucoz.com/

    Visual effects

    Victor "Snabisch" Navarro

    https://makeagame.bandcamp.com/

    Music

    Jesús "Jalastram" Lastra

    http://opengameart.org/users/jalastram/

    Sound effects

  • Tokinsom yeah, I agree the whole thing could be a bit more streamlined ! And I do like the idea of keeping sprite sheets internally to make resource management easier. Plus it shouldn't prevent the user from editing individual animations, re-ordering frames, adding image points, etc. all these would just need to be kept as metadata in parallel of the sheets. Maybe for C3

    Though I do see a point in re-slicing/re-packing the sprites ; automatic processing of large amount of resources can usually lead to better results than manual management. For example maybe several sprite sheets can be recombined into a single texture atlas, maybe some animation frames are unused and can be dropped from the export while keeping them at edit time, etc.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yeah, it happens for a collection of very specific Y values ; these must be corner cases that are not dealt with properly in the collision logic

  • Tokinsom : oh, I see what you mean ! Thanks for clarifying Keep the sheet itself as a resource, instead of processing it and slicing it into frames directly on import. Indeed that makes resource management, especially animation updates, easier.

    Though I think OP is mostly after building an animation from a spritesheet, regardless of the slicing, instead of manually importing one frame at a time, which is clunky and time consuming. Something C2 is capable of.

    As for efficiency and performance, frames are packed into texture atlases when exporting anyway, so delaying the processing or not should be negligible.