Halfgeek's Forum Posts

  • Congrats!

    I heard from other devs, you need around 6000 yes votes before someone at Steam takes a serious look at your game. It usually passes with 6K.

  • Iolva Thank you.

    DARTH Crusher

    Haha yeah that stupid green font (been using it since the start) is place holder. I STILL haven't found a replacement that I like. Something simple & very readable.

    If I can't, I might just use the white info popup font but bigger.

    Edit: Here's with the bigger white font. Very readable!

  • Here's some screens of the UI. From my devblog: https://halfgeekstudios.wordpress.com/2 ... irst-look/

    --------------------------------------------------------------

    I’ll be the first to admit, I am terrible at making good looking & functional UI. Functional yes, but not functional & good looking. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> So I will keep it simplistic, minimal and hope that the ease of function will work for most players.

    Upon landing on a planet, you proceed directly to the Mercenary & Merchants Guild HQ at that location. It’s often a more seedy spot, where anything goes.

    Here, you can access the trade menu to sell/buy goods, hangar menus to buy/sell/store modules as well as ships.

    For Modules, each ship share 5 main categories for upgrades: Energy, Armor, Shields, Engines & an Active Slot. Each slot, there's many options, but players have to pick & choose. There's definitely trade-offs with module choices.

    The weapon slot & size depends on the ship itself. If the ship has secondary weapons, such as launchers or drone bays, it’ll be displayed.

    I’ve made the launcher/drone bays universal, of different sizes, from S to L-Class. Missiles, Torpedos & Drones have sizes accordingly.

    The idea is a S-Class bay can hold X/Y/Z of S/M/L-size armaments. This means smaller ships with S-Launchers can still pack a bunch of high-powered Torpedos or they can pack a lot more smaller S-size missiles.

    Its flexible to allow players to pick & choose what best suits their playstyle.

    There’s also storage for modules on your ship, with larger ships having a larger capacity storage. It’s useful not only for storing loot from battles, but also extra-modules in case the situation changes and you need to re-configure your ship.

    For ships, there’s a wide range, with each ship focused for a particular niche within its class, of which at launch there will be three: Corvettes, Frigates, Cruisers.

    Corvettes are the fast, agile & evasive. They have an innate 50% evasion against weapons of M-Class or above, this means Frigates & Cruisers have trouble 1) tracking such a fast agile target and 2) even when they fire, it may simply miss completely.

    The goal is to make them good as entry ships, but also the later Faction Corvettes or advanced prototypes can be used as an end-game ship by players who love the fast & furious gameplay (ie. with good flying, Corvettes can dodge ALL enemy missiles!).

    Frigates sacrifice some speed & evasion for a lot of firepower, as they can equip multiple M-Class Turrets as well as often packing bigger Launcher & Drone bays. They still have an innate 25% evasion bonus against larger turrets, so its a good trade-off vessel.

    Cruisers lack speed and have no evasion, but have higher armor that defeats smaller weapons, and more weapons options, as well as access to L-Class Turrets which have by far the most firepower.

  • Darth, it's coming along great. Been a very productive two months.

    Squad combat & orders all done.

    Modules, cargo, storage and ship purchase menus all done. Tons of different modules & variants for loot table.

    Just mostly boring UI stuff but its turning out nicely.

    I'll post a few screens soon so you can give some feedback on the UI.

  • Why does 30 fps in any native/console game means smooth game,

    and 30 fps in any Construct 2 game means slow, almost not playable game?

    Maybe it's silly question, but I'm just curious

    Because consoles are designed to run at 30 fps, the engine is capped at 30, so there's no fluctuations. A stable 30 fps is very playable.

    A stable 60 fps is more fluid though.

    The problem is that games designed to run at 60 fps sometimes can't and the dips cause frametime variance, to the end user, it looks as though the game is very stuttery, fast, slow, fast, slow etc. This makes it feel worse than if its running stable 30 fps.

    It's the same for PC games, running with or without vsync, if the frame rate jumps all over the place, the game feels very choppy even if its running 40-80 fps.

  • Regardless if vsync is slightly off, chrome still has the fastest javascript and WebGL performance as far as I've tested informally by running various projects. The issue of occasional tearing isn't nearly as big as the issues IE11 tends to have in all other areas IMO.

    Its not just tearing, its stutters. Frame latency that varies a lot make fluid 60 fps feel very slow.

  • The situation on mobiles has gotten better, but only for iOS.

    Android, we're still stuck with Crosswalk 7 because the more recent ones are based on a buggy Chromium, leading to erratic and terrible performance. Performance hasn't gotten any better since around Feb 2014. O_o Not that it was any good to start with, just tolerable with a lot of optimizations.

    Also, physics is still a no-go for mobiles. There must be something inherently flawed, its as if the physics isn't hardware accelerated on mobiles. I've used native box2D in Eclipse before, it handles hundreds of physics objects on a weaker mobile. Try the same in C2, we're talking single digit objects.

  • Relates to audio and music too. There absolutely needs to be an unload asset option to give developers more control that they need for more complex or large scoped games.

  • I use Letter Box scaling on my games. Scale Outer with a base 1920 x 1080p will look really awful on 800 x 480 or 960 x 540 devices (unplayable in fact), even 1280 x 720p devices will have most of the screen cropped out.

    Most Android devices are 16:9 or 16:10 ratio so Letter Box scaling on 1080p will look just fine and will present the full-scene.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • My games are optimized for tablets & phones.

    What's your Intel XDK settings for this game? Take a pic of it.

    Also, regarding the poor performance, check your C2 project settings:

    Fullscreen scaling, change from High Quality to Low. Your project is already 1080p, you do not need to use HQ, it will look fine on Low on mobile screens.

    Use High-DPI Displays: change Yes to No. Again related to the high resolution of your game, there's no need to have Yes here, it just take additional resources to render.

    Try it, performance should improve massively, without much of a reduction in image quality.

  • If you have a short "victory" music, you can put that into the sounds folder to ensure it plays instantly without touch input.

    Longer audio tracks leave it as music, touch to start is a limitation on browsers for mobiles, just work around it or incorporate it into your game.

  • To quote Ashley from the "Optimisation: don't waste your time" blog post:

    [quote:d9gjptbb]

    Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering - even when hardware accelerated! In other words, if you're not getting 60 FPS, the #1 thing to do is think about how to speed up the drawing of the game.

    If you want to use that quote, you have to get specifics, define a "fairly complex" game.

    Any mobile gamedev who has used C2 on a large project knows its limitations: JS suffers a performance penalty especially on mobiles. It's also single threaded which is not good for mobile CPUs which are often made up of 4 weaker cores (imagine only ever using up to 25% of a mobile device's capability!).

    Optimizations is key for mobile devs. Ignore it at your peril, then come back and make a post about why "C2 sucks for mobiles" or "C2 performance on mobiles blows donkey"... like the many threads we have on these forums on a daily basis.

  • Thanks again for the help. I already reduced the memory usage by splitting one layout into two (was using container layout already).

    Now I've got a question about music.

    For some reason, on an iPad, music only starts when touching the screen once the layout has started. This cause massive music problems in Healer Quest, and it happens when exported both with XDK and Phonegap Build. FYI there is no such music problems on android, and I think it's correct on iPhones, too (problem iPad only AFAIK, experienced on iPad Air 2 and iPad Mini 2).

    To counter this, the only solution I found was to add the music into the sound folder, and here is my question : Does making this increases the memory usage even if the music is not played?

    Another question : Is there any "clean" way to play music correctly on the iPad?

    Thanks!

    Never put Music into the sounds folder, it explodes the memory usage to insanity due to decompressing your music into raw wav files to store in memory to play instantly.

    Music is streamed, to minimize memory usage.

    The touch before playing is an issue with some browser engines on mobiles. You can bypass this by making a intro screen at the start of your game, requiring users to touch it to start the game. Think of consoles, "Press Start Button" menus.

  • Does it means that if I have a 1024x1024 pixel spritesheet in my "image" folder, whether it is full of sprites, or just plain transparent with only a few sprites on the top half of it, it will use the same memory during the game?

    Yes.

    1024 x 1024 images in vram is 4MB of memory, regardless of the original format or whats on it.

    2048 x 2048 = 16MB of memory.

  • Nesteris,

    Actually I wouldn't worry at all about most Every Tick events. The biggest source of slowdown on mobile is related to graphics, not logic. Unless you've got some hardcore physics calculations happening, forget optimization and just make sure your code is organized and pleasing to the eye. Setting A equal to B every tick has practically zero impact on performance. Ashley has addressed this on his blog. If you haven't already, read it and feel relieved.

    https://www.scirra.com/blog/83/optimisa ... -your-time

    The best advice is to periodically export the game and check its performance on mobile. That way, if you made a change that breaks performance, you can re-evaluate your approach.

    <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

    Worse advice you can give to a mobile dev.

    Don't you see this forum is constantly filled by complaints of poor performance? 99% of the time its because mobile devs failed to optimize their games ground up.

    Even for the PC, it's best practice to always optimize your game and design it around extracting peak efficiency. This is especially true for mobiles, even if your game runs 60 fps. If its efficient, it runs 60 fps while using less CPU cycles, resulting in less "battery draining" or "overheating devices".

    ps. Setting A = B every tic doesn't matter much, but repeat those wasteful events enough, it becomes bloated, poorly optimized and then it truly matters.