CF78's Forum Posts

  • Thanks a bunch KaMiZoTo Your works are inspirational

  • Found it for ya droxon

    See here :

  • Dang gillenew Looking top notch!!!

  • Where can I see which version of NW I'm using?

    Go to your Programs folder where Construct 2 is and look for either NWjsForC2 (10.5 ish) or NodeWebkitForC2 (NW.js 12)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Curious about which version of C2 is most stable and gives best results in terms of performance(?) To note: NW 10.5 has been a better choice for me thus far in terms of exporting as opposed to NW.js 12.

  • I think you are correct newt

    I have been doing some further testing on this issue. I went backwards with C2 installs (back to 196.2) and it didn't resolve the issue with my current tilemap. If I create a new tilemap it seems to alleviate the issue. Which leads me to believe that somewhere along the line a C2 version broke / corrupted tilemaps files - and then was fixed, but left issues on past tilemap files(?) Also It seems that not only are tilemaps effected, but sprites as well. For I have been having to manually replace any image I want to update in C2.

    Tilemaps :

    Updating through C2 does not save. Doesn't even update texture while open.

    Updating through Tiled appears to save, until next opening of file.

    Manual updating via the project folder files : solves issues. (so far from what I can tell)

    If I manually update Tilemap texture via project files, it works and saves.. And once that's done I am able to update inside of C2 (this is also the same method I have been using for sprites as well)

    I first noticed this issue on r200 with sprites.

  • Just played this in the arcade. Super fun! Nice work!!

  • Devlog Update : 4-28-15

    I wanted to share some more progress. In one of my previous updates I discussed how I had put level design off until I had a solid direction of functionality and overall game play. The reasoning behind this is that, every time I added, changed, or removed something during the early stages of development, it directly effected game play. Which resulted in me rebuilding levels to compensate for changes. That ate up a lot of time (as level design does) which was frustrating early on to keep redesigning levels... This is pretty obvious for most, but considering this is my real first game with some direction, I wasn't directly aware of it.

    I switched focused to player mechanics, enemy AI, art, etc. and took my time polishing it all up. Now with everything in place and working as intended (player, enemies, obstacles, a boss, etc), I have begun to work on level design. Interestingly enough, the early levels were very small and enemies came from everywhere. As development progressed, the levels (or test LEVEL) got increasingly longer, but still very platformer'ish mario bro's style. I assumed this would be the ultimate direction in terms of level design. Long platform levels.

    I recently wrapped up on “The Maker” boss, which for me personally was a milestone to move forward with level design and to wrap up all the ideas bouncing around in my head. (or on paper) and get a demo out for people to play. That said... I had 3 level designs that I was going to offer in the demo due to my uncertainty of what works best.

    1) Platform (long mario style)

    2) Tall Platform (vertical platformer)

    3) Metroid Level

    #1 was done (as it was my overall testing level) so I started on #3 the “Metroid Level” over the weekend figuring it would be the most challenging. As I had assumed, it was a challenge. I realized early on that my tilemap art was not created for such a levels, so I had to make a few adjustments. I also had no real way of getting the player from a high point to a low point (or vice versa) without platforms to jump on. So I had to create an elevator. ( A smart one that returns when you are near ) After I took care of the little issues that arose, I began to test out the level. At first I was unsure of the direction, (most likey due to being used to a specific level layout) but that feeling soon went away after I let some close friends play test it. The response for this level was better than I had thought. Seems this layout style really gave the game an extra boost, along with opening the door up for some more possibilities in relation to overall gameplay. Admittedly this adds a bit more to the process but, it's an addition that's well worth it.

    Test / Current level :

    Metroid Style Level:

    Development To-Do's :

    1. Add some more weapons

    - EMP Cannon

    - Laser

    - Rail Gun / Disk Gun

    - Proximity Mines(?)

    2. Stationary enemies (turrets, mines, etc)

    3. Boss defeat scoring

    4. Speed & Jump boost level indications on UI

    5. Story / Game Tip Art

    6. Replace particle explodes with animations (optimization)

    Promotional To-Do's :

    1. Add devlog to tigsource

    2. Add concept to steam (?)

    3. Robot 505 website

    4. More Promo Art

    5. Press Kit

    6. Post, post, post

    I am pushing for a playable demo release within the next couple of weeks. Stay tuned for more info on Robot 505

  • Impressive looking game play!

  • Well I just opened my project after updates made to tilemap via the 'Tiled' export, import route, and lone behold... The old tilemap image is back :/ Can't update tilemap images without creating a new one.

  • If I use 'Tiled' to import and export, I can update tilemaps that way.

  • I just noticed this today while trying to update a tilemap image. I have also recently observed this exact behavior with sprites as well. :/

    Sometime restarting the application alleviates it.

  • Much appreciated! jobel You'll be able to play the demo before any of that

    Colludium Thanks a lot! I have spent most of my time on art, polish, and refinement. Great to hear it's noticeable

    Devlog Update 4-26-15

    As it stands the game is just about ready for it's demo debut. I'm just nailing down all the minor bugs, and level testing so I'm not bombarded with known bug / issues feedback, instead of quality feedback. 3/4's of the way into development, I changed directions, and as a result I put level design on hold. Seemed I was rebuilding levels to compensate for changes made to player, enemy mechanics, and/or any idea implementation. Which ate up a bunch of time.

    I am anxious to see how the game will perform on other machines. At the moment it's playable on an i3 with integrated graphics, at the games original resolution of 832 x 480 (only other machine I have been able to test) - I have been developing on 3.4GHz Xeon / 32GB / 10Krpm & SSD / 2GB 650ti setup, so it's hard to tell how well or poor it will perform on other hardware. :/

    NW.js (For those wondering about desktop exporting) :

    I have been exporting to NW 10.5 - 12 works just as well for me... BUT 12, for me, uses twice the memory and about 15% more CPU. That said, both versions when observed in comparison to actual system resources being used, are off by about 10-20%

    If I export and the game says it's using 20% of CPU - It actually correlates to about 3-5%. I'm sure there is some reason for this and perhaps it's an estimated amount that C2 displays? Either way, when I demo it I will export to both versions of NW.js, to get some comparisons from users.

    (** FPS drops due to screen capturing)

    On a side note, I'm rather excited! This is my first 'actual' game!

    I will be posting more throughout the week as I get near demo release.

  • Siiiiick!

  • Looks awesome! I need to enter one of these jams one day.. Great post-mortem read.