Fimbul's Recent Forum Activity

  • Using open libraries would make it easier to port from Win to Lin. It's not about "omgomg linux support" it's about a people's platform. We're spending thousands on computers, more on software, so it's nice to know there is a free operating system that allows people who can't afford Windows (or simply don't want to use it, or can't use it, etc) to be able to get work done. It's everywhere. It's already in most consumer electronics for its ease of use for developers (and extremely low cost of $0.00, that's USD) and it's what powers Android.

    C2 may be the best software out there for designing HTML5 games, but all the others (except Game Maker) have a Linux version.

    For me it's not a question of price, but of openness and pervasiveness. I'd gladly pay $500 for a version of linux as powerful as windows in all regards - the only reason I haven't switched is because

    • linux can be a bit funky requiring you to use the shell for some tasks (configuring X being one of them). Ubuntu is definitely making things better in this front, but not fast enough.
    • The software available isn't up to par. I miss adobe's Photoshop/Illustrator/InDesign/AfterEffects as well as Microsoft's Office suite. I also hate that none of my game dev tools are available for linux (not just C2, but also articy:draft).

    I wish I could change to linux. I'd never look back.

  • However that would limit the usage of the characters to the people owning such a tool.

    Provide the files in a variety of formats, and also precompiled sprites for those who don't have the tools.

    And it would be like giving out the source code of a program.

    And? There are prefab animations included with most packages. The "meat" of your kickstarter are the characters, not the animations.

    If people could simply replicate the characters if you gave them the source files, they wouldn't be needing you in the first place.

    As an analogue, the source code for Angry Birds is worthless, every two-bit programmer knows how to code something like that.

  • If anybody comes up with a better solution to create customized characters out of a selection of premade body parts on your own, please let me know.

    ...Spriter? Spine?

    How were you making animations before?

  • I must say that there were a lot of unhelpful answers in this thread.

    I think he's missing the point.

    It would be better to look at recent successful games, one by one, and ask yourself "can this game be cloned in construct 2?".

    You'll find that the answer is yes in most cases.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I love the idea, but the characters seem to only be suitable for an undead game. Also, prerendered images are a bit bad for that style: I bet people would rather have you break them into components to use with 2D animation packages, instead of having to rely on your own animations.

    For instance what if I want the girl holding the axe while wearing the eyepatch?

  • It's kind of an odd question to ask on the official C2 forums, but after browsing a bit, I'm kinda scarred.

    I am a 48h game jam developer and ,'till now, I worked using my own set of tools. While this is cool, because I have a complete control and understanding of what I do, I feel like loosing time and being limited especially since I can only compile to Linux, OSX and Windows.

    You'll definitely like it here, especially since you can code. The editor can be a bit quirky sometimes, and you'll often find yourself pushing it's limits, but Ashley is always adding features, and you can always crack open the SDK if you want to get your hands into some javascript.

    Is the android/iOS export working? I saw countless posts stating they had problems and since I do games with very limited time constraint, I can't afford to loose half a day on a specific platform problem

    Yeah it works. The problem is mobiles are always 1~3 years behind the desktop feature-wise, and about 5 years behind performance-wise, so people complain. Right now, physics is possible (whereas a few months ago it used to kill the phone). WebGL still degrades things a bit too much from what I hear, so it's only usable in newer phones (not exactly top-of-the-line, think 2 years old maximum).

    I saw like a weekly war going on about "you should go native", well I'm coming from native and I don't think it's the best idea for hobbyist. Is performances that bad? From my test, it looked more than ok for a wysiwyg game editor.

    Like I said above, performance is great, unless we're talking about mobiles. Still, seeing as how you're a game jam dev, I would familiarize myself with the engine first, given that the performance issues that occur in mobiles are nearly always caused by the same things (excess physics, WebGL, big textures). Since you're familiar with code, you'll probably be aware of what those problems are, since they happen everywhere.

    With native, you spend most of your time dealing with low-level routines for drawing, collision checking and dealing with bugs - Construct 2 takes care of that for you, so you can have a pretty good game up and running in a few hours, and games that would take months to make from scratch in native should take you weeks at most (think super meat boy, braid, spelunky, binding of isaac).

    On the other hand, as your project gets bigger (think RTS games, simulations, RPGs), the event system starts to become a bit unwieldy. You can postpone this if you're clever and think outside the box, adopting frameworks, sane variable names, comments, groups and so on.

    There's definitely a point where your code becomes spaghetti, and that for me is the biggest problem right now. It shouldn't bother you, though, unless you want to make an epic feature-packed game.

    The easy to use shaders is one of the strongest point of C2 to me, allowing quickly done effects. On the same idea, I often use some very basic 3D for effects, is it possible to display 3D textured objects? No animation or anything, just basic 3D rotation and display?

    No. People will come up with hacks, but there's definitely no 3D: anyone who says otherwise is deluded. We have basic billboard mode-7 like stuff, achieved through basic trig, but there aren't any rotating objects or anything like that. At best, you can display a 3D planet rotating.

    How is the tool progressing : it seems like updates are coming out often, but as users, do you feel there is progress?

    Fast progress all around. Ashley is great. May not always have the features you want right away, but the updates never stop.

    Also we're not talking about itty bitty patches-disguised-as-updates here either: we actually have full length features being added to the product all the time.

    We recently had a debugger (complete with breakpoints and stepping) and the current "big thing" is the multiplayer (with UDP support!) plugin.

    Our "patches" frequently add cool stuff as well, such as the recent ejecta wrapper.

    And finally : are you happy with your purchase?

    Definitely.

    Here are some problems you'll face:

    • There are few ways to collaborate - two people cannot edit the same project at the same time.
    • Code gets messy if you want to do complex games
    • Code reuse is poor, due to lack of modularization. Either reuse entire engines or make new engines from scratch.
    • Some times, browser vendors do weird things that break the engine, and you have to wait for new versions to come out (such as chrome's decision to disable hardware acceleration in windows XP and vista).
    • Some things are impossible to do until browser vendors agree to support it (the biggest problem was multiplayer, but that's now being fixed).
    • You cannot "code" directly in the engine. If you want to touch the javascript, you have to create a plugin/behavior with the SDK. It's a painless process, though.
    • Integration with 3rd party tools is a pain, unless said tools are officially sanctioned by Scirra (such as spriter or tiled). If you want articy:draft or similar, you have to do it manually (and there are no means to automate the integration either).

    Here are some problems you WILL NOT face:

    • Stuttering caused by javascript's garbage collector: Ashley has done a great job working around the gc, so this type of pause is rare.
    • Display/Behavior inconsistencies: games work mostly the same across platforms. You may find some discrepancies in jump heights, small distortions in effects and differences in physics evaluation, but nothing major. Things work like you expect them to.
    • Showstopper bugs: The engine is pretty stable, and you only run into bugs if you dig deep inside the engine. Most bugs have workarounds, and are fixed pretty fast.
    • Project corruption: pretty rare. When it does happen, it's often because the developer deleted something he wasn't supposed to. Also it's often possible to recover such "corrupted" projects.
    • Hidden "gotchas": stuff works as documented, but for the most part you don't even need to read the documentation. Functions are self-explanatory and work how you expect them to work.
  • Also currently the engine stops running when it goes in to the background to save CPU and battery, so it would probably only be able to alert when you're already looking at it.

    Can we prevent this somehow? Especially with the new multiplayer features, it seems that the game will go wildly out of sync if you switch to another tab. This applies even in the desktop, I think, where the game goes to 1fps in the background.

    Can you imagine if league of legends booted you if you alt-tabbed? Ugh.

  • It sounds like a ton of buzzwords and zero technical info. A hype-machine at best.

    As an engineer, I see all those photos of happy people with first names (all common ones, not even one weird name - it's as if they invented those names) written below them and think "istockphotos.com" instead of "happy customers".

    Edit: Just like I thought: http://www.rgbstock.com/bigphoto/2di5nt ... p+Kenson+2

    I see "deploy on the desktop/mobile/web" together with "HTML5,CSS,PHP,MySQL" and think "do these guys even know the difference between front-end and back-end?". Looks like they did a google search for "web technologies" and put all the names they found as bullet points on their page.

    Most of their "platforms" are variations on a theme:

    • 4 versions of windows
    • 4 versions of OSX
    • 2 versions of iOS
    • 2 versions of Linux

    Gee, well guess I can't import that to my debian/slackware/chromebook/windows phone then, can I?

    "Native vs HTML5" is a polarizing debate. Let's stop it. Your approach shouldn't be driven by the technologies available, but the requirements of your business. What you need is a dynamic partner that has the flexibility to support you, regardless of the approach you choose.

    Management-speak without real substance.

  • Not sure about the other case, but an in-game "sub-layout" view would be a lot more efficient than a whole new instance of the engine in an iframe. That could be quite a lot of work though, so I'm not sure we could do that soon...

    I'd love to see this, especially if it means we can code inventories/option menus and other complicated things in separate layouts. Would also help greatly with split-screen multiplayer (where most of the logic can be in the "main" frame, and the player's views can be kept in two sub-layouts).

    I know you have a lot of stuff on your plate, but +1 to that feature

  • It would probably be very slow, not because there's anything particularly inefficient about iframes, but just from the fact a typical game will use up a fair bit of CPU/GPU/memory, and running several at once will use a multiple of the system resources. Desktops might get by but I'd imagine it'd choke mobile devices.

    What are you trying to do? Why are you asking the question? If you want to make a menu in an iframe, it's a very inefficient way to go about it since you get the overhead of an entire game engine just for the menu by itself. It'd be better just to design it in-game itself. However if you're making some kind of arcade, it would of course be better just to run one game at a time!

    I have an use-case for you: I'm designing a space game which has two "views": in the first, you control a character and can move around in a tile-based world. In the second, you control a ship in a arcade shooter style. You can freely switch between modes, since you can (and should) walk around in your ship during combat. However, both modes are so dissimilar that programming them is making my layout be a bit of a mess. Separating them in different layouts would be better, but switching between them during the gameplay causes noticeable delays. Also, both "modes" must run at the same time (since they must be kept in sync), even if only one is visible at a time.

    Currently my approach is to code two engines and keep them in sync via shared variables, hiding one game and showing the other when appropriate. Is there a better way?

    Keep in mind this is a desktop-only thing.

  • I haven't read the entire thing or watched the videos, but from the looks of it, it seems like a tool to build desktop apps using web technology without the DOM and CSS (e.g. the worst parts of the web).

    If that's the case, it could open the door to customizable tools. I'm going to go ahead and say that I would love to see the construct 2 IDE built on top of something like that. Imagine building editor plugins in javascript instead of C++? For light tools (that means everything but image/3D/video editing and data analysis), this looks like the way of the future.

    We'd get mac/linux versions automatically, Ashley would only need to maintain one language (unless the exporter is kept in c++) and performance wouldn't ever be an issue because who the hell needs beefy computers to run construct 2?

    The only thing I'd miss is to be able to use prebuilt UI components like jQueryUI.

  • Things I like:

    • Plugins written in javascript
    • Can interface with page elements
    • Sub-events
    • ForEach / Ordered ForEach
    • Breakpoints, stepping and the debugger in general
    • Multiple/stacked/layered WebGL effects
    • Rotatable layers
    • "Including" event sheets, and the separation of event sheets and layouts
    • Global/Local variables
    • Check collision at offset (without having to move the object or create a "detector")
Fimbul's avatar

Fimbul

Member since 12 Aug, 2011

None one is following Fimbul yet!

Trophy Case

  • 13-Year Club
  • Email Verified

Progress

14/44
How to earn trophies