Fimbul's Forum Posts

  • Bachelor’s degree in Computer Engineering OR technical diploma in Computer Engineering Technology OR Graphic Design/Media Production and Design OR Game Art and Animation

    Any country restrictions? I mean not only for applicants themselves but for the bachelor's degree as well...

    Must have strong artistic sense. Please provide an art portfolio

    Art is usually contracted separately (as in, done by someone else). It's going to be hard to find a single person who can design, program and draw at the same time.

    Since this is a contract position, please submit your hourly rate expectations (private messages please).

    Could we get more details, an expected range, a budget, timeline or anything else?

    It's very hard to commit to a price if we don't have any idea what the project is about (looks like a platformer?). I understand you don't want to reveal your project here, but details such as expected quantity of work, contract length, team size, stakeholder availability and similar are required before providing a quote.

    In addition, since you expect applicants to have a Bachelor's degree in computer engineering, as well as artistic skills, for hourly work it would come out to around $50/hr. Like I said, you can probably get better rates if you provide more details.

  • It doesn't make sense to "sort" a dictionary, since all keys are named. What you actually want to do is sort the array stored inside the dictionary, but since it's not a primitive, you end up having to copy it out into an array, sort it, and copy it back.

    The problem stems from the fact that you're "hammering in" an array as dictionary keys. This is not your fault, it's just the way construct's webstore works, due to the fact that the dictionary object can only store numbers or strings.

    In my opinion, we need Construct 2 to do two things:

    Start treating arrays (and dictionaries but that's another point) as primitives instead of as an object.

    Have a proper JSON parser where we can access deeply nested structures using javascript notation.

  • Here's an example I put together. All in 13 events, so you could work this into a game even with the free edition. Also I was wrong, you apparently do need the last platform ID (unless you want more maths).

    Press "enter" to change the angle (but wait a few seconds before you do that)

    Scrolling is a bit bonkers but you should be able to fix it with some maths or creativity.

    Sorry for the scary math. It's probably possible to get rid of it all and replace it with something easy.

  • I don't think you need the ID of the last placed pole at all. In most infinite scrollers you don't even need to scroll - it's an illusion.

    Is the character always "climbing" up and to the right, in the same angle, or are there sections where the player can go down and to the right, or horizontally to the right?

    Are we supposed to answer the games that inspire us as gamers or as developers?

    As a gamer, I'd have to say:

    Fallout 1&2 (branching dialogue and moral consequences. My first truly mature game.)

    Minecraft (soooo much freedom! Bought back the joys of my childhood playing with legos)

    As a developer:

    Dwarf Fortress (embrace complexity/a full indie lifestyle is possible)

    Ultima Online (MMOs can be very deep)

    Continuum (made me think a lot about netcode)

    But lately:

    FTL (management overload)

    Factorio (automate everything!)

  • full time doing database consulting

    would love nothing more than to make my dream games all day

    keep the girlfriend happy

    Are you me?

    I'm a BI Analyst and DBA. We should talk some day

  • What? When I apologize for being insistent, I don't mean I'm demanding the feature, but rather that I am sorry that I keep bringing it up. It's implied that Ashley can do whatever he wants and I have no power over it. This is just a request.

  • good games don't always make tons of cash-money

    bad games don't always make tons of cash-money

    sometimes good games make tons of money

    sometimes bad games make tons of money

    Bad games are easier to make than good games.

    Therefore, the logical conclusion is that you should make bad games.

    But we all know it's not so simple, right? Well apparently not, since like OP said, most beginners ask how to integrate IAP before they ask how to make a player jump.

    I don't know what to say. I agree with OP.

  • special code in the editor

    Could we get rid of this, please? Sorry for being insistent, but this sort of thing is the antithesis of the modularity afforded by plugins.

    It would be unthinkable if the platformer object used "special code in the editor", even if it were to solve many problems. If this goes on much longer, a ton of plugins will start getting "special code in the editor", and developers will lose autonomy, having to rely on you to produce any plugin/behavior more complicated than trivial stuff.

    This lack of integration with the editor should be solved via the SDK, not via "special code".

    Again, sorry for being so insistent.

  • This is exactly why an IDE SDK would make sense...

  • Its true for every single industry.

    Actually no. That's only true for the creative industry:

    • Musicians
    • Writers
    • Filmmakers/Directors
    • Dancers
    • Actors
    • Graphic Designers (Painters, Illustrators, GFX, VFX)
    • Sound Designers (AKA SFX)
    • Game Designers
    • Game Programmers

    If you're a corporate lawyer, database analyst, backend programmer, management consultant or things like that, you're (crisis aside) pretty safe from poverty.

    This used to mean you should only get into game design if you're really passionate about it, because there will be months where you won't be able to afford groceries. The risk lies entirely with the developer, who has to create a product from scratch and hope people like it enough to pay for it. Players on the other hand have no risk: they can try a demo, watch a let's play, read a review or even pirate the game. If you go with a publisher (that means you're no longer indie, you're just small), you can transfer some of that risk to the publisher, but lose some creative control (some publishers are great, though, don't let the stories scare you).

    Kickstarter recently changed the way the industry works, now ideas can be evaluated upfront and so some of the risk in indie development is transferred from designers to players, who may never get a product (or get a much inferior product) in the end due to complications with development.

    In the end, though, these are pretty much your only options:

    • Working with a publisher, you get decent money and don't have to starve, but you'll be making the games THEY want (which probably means bejeweled clones), and that sucks the life out of any indie dev pretty quickly. Go this route if you like games in general (instead of a specific game/genre) and feels confortable working with the current trends in the industry (as of this writing, we're talking about mobile physics-based puzzles with IAP. A few years ago it used to be social games, but that trend has died down).
    • Going full indie, you can make the game you always wanted. This takes a lot of time, and you'll find little to no support. Don't expect people to team up with you, and you'll have to pay out of pocket for people to do things you're not good at (sound, music, art, programming, writing, etc). Your first games will not have commercial success and it's a ton of work, for a very long time, for very little pay. If you manage to hit it big, though, the earnings can set you up for life.
    • Hobbyists have a full time job that they drain funds from to fuel their passion. This means you have a boring 9-to-5 job and during the rest of the day (and weekends) you can work on your game. This allows you to make the game you always wanted, and you don't have to starve. There is also more room for mistakes since you can always restart (you're not against a ticking clock). The problems are that development slows down to a glacial pace, there's nothing and no one pressuring you (which means you need tons of willpower), and feature creep can become a serious problem.
    • Crowdfunding. This changes the whole picture, because it allows you to sell your game "upfront", even before you actually code anything. The problem is that you need to somehow acquire the funds, and your prediction must be pretty spot on, if you run out of funds you're not off the hook. Also, if your game fails (read: you were unable to complete it), your reputation is doomed. Unfortunately, kickstarter is only available in the USA, and it's extremely impractical to work with it if you live anywhere else (with possible exceptions for Canada and the UK).

    I've tried all the alternatives above, and from my experience the hobbyist approach is the only one that affords you a worry-free possibility to make the game you want. Everything else is either immensely stressful or leaves you making crappy-bird clones until the cows come home.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Music should be much more than just a quick tailored placeholder, just so that it isn't so quiet. You would wonder how much more success your game had if using explicitly composed music instead of well konwn loops.

    Exactly. I think people are misunderstanding you.

    Subscribe to Construct videos now

    is what you mean by "loops", right?

    Whereas

    Subscribe to Construct videos now

    is a remix. Even though it is done using "loops", they are two different things.

  • So with all that feedback taken into account, my new concept would be this:

    ...snip...

    How do you like that?

    ...snip...

    I have been working on a custom head generator for female faces.

    Sounds exactly right

    Here are some tips:

    • Make sure to precompile *some* character+weapon+animations (for those that don't have spriter/spine and/or don't have an engine capable of animating skeletons) - doesn't matter really if the final file size ends up being 2 Gb.
    • Try to make a spriter version as well or you're severely limiting your target audience

    > He's missing exactly what you're offering

    >

    What exactly do you mean?

    He doesn't have any animated characters for a platformer/sidescroller/fighting game, even though he has platforms and backgrounds for those kinds of games. His animated charaters are for a top-down RPG.

    Now, that being said, keep in mind I'm not the target audience for your project, since I'm not interested ATM in an undead type game (maybe if you asked me a few years ago . Now I'm more interested in futuristic tile-based games). I advise you to look around at the kinds of games the community as a whole likes to make and work on them. The Zombies+variations (lich, undead sheriff, etc) are cool, but they are enough I think. You probably need a knight, an archer, orcs , ninjas, normal pirates, vampires - not to mention normal people with normal clothes. Those would see a lot more use than, say, this guy.

    Some other misc tips:

    • The sorceress/witch looks a bit too much like a vampire (was that intentional?)
    • Steam can distribute your package, even though you're not a software or a game (that kickstarter you linked to will be on steam)
    • If you ask for suggestion in gamedev forums, you'll probably get more publicity than saying "here's my kickstarter back pls" (dramatized for effect). Go for programmer-heavy forums, artists are not your costumers.
    • Create accounts and participate in the forums (even if only on the open-topic section) a bit before advertising, this should make moderators less wary of you. You may even get a pass (if you ask first) at posting to the more public parts of the forum.
    • Might make sense to split into precompiled per-character packages and sell them separately on sites such as graphicriver
    • Since you're using spriter/spine, it makes more sense to focus on faces/clothes/armor/decorations. You may be able to reuse the same body for different monsters.

  • I now have loads of prototypes I can use in making one bigger rpg game.

    That's my problem as well. I have a ton of cool stuff lying around and no easy way to integrate them into a big game. When you try to group all those prototypes into one big game, your code starts looking like spaghetti.

    Chuck in Constructor84's deluxe RPG inventory system!

    Exactly! If we could gather all those prototypes and make a module/widget out of them, and sell them in Scirra's asset store to boot, we'd have a TON of cool stuff. Tom?

    How many times do we need an inventory, dialogue tree, options screen, dropdown menu, equipping items, destructible terrain, infinite scroller... and the community wastes time reimplementing those one by one. If we had modularity, we'd be halfway there to solve big games (the other half would be the IDE SDK which solves middleware integration and project management all in one go).

  • Okay, I agree with you and I thank you for your feedback.

    However there are some things to consider:

    As the characters differ in size, bone length and other things, people would have to adjust the parts first to match the animations.

    Most animation packages already offer said customization easily.

    Let's take the example of the wizard girl holding the axe instead of the staff, the glow effect of the axe would have to be repositioned onto the axe, as the axe is a lot shorter.

    You can pin the effect to the axe. In fact, most effects can be done better with OpenGL/DirectX directly in the game engine instead of baked animations, so pinning the effect becomes even more desirable than precompiling.

    What would a character pack consist of? Only the precompiled sprites together with the source files of the skeleton and the animations? So you would have to purchase another character that wears an eyepatch if you want your toon to wear one? Or would a complete character consist of all possible parts applicable to him, already resized and worked into the source data?

    The character pack would consist of the skeleton, animations and parts in the form of spriter/spine source files, as well as precompiled sprites, each on a folder, in PNG format.

    If you want to mix and match characters, you have no choice but to use spriter/spine source files and resize/position them yourself. This shouldn't be hard for a game developer - programmers' difficulty lies in actually drawing the parts in the first place. Of course you'll need to put some effort into making sure parts are universally cross-compatible (ex: all hats should fit all characters).

    (Of course the would have to be various different attack animations for each toon, as you cannot stab with an axe, compared to a dagger,...)

    I discovered a kickstarter project named "Indie Graphics Builder #2":

    The characters can only be composed of different parts because they have all the same basic doll with the same shapes and sizes.

    There's nothing stopping you from using the same "doll" in your project as well - in the form of a base sekeleton. This way you can include animations for stabbing and swinging to the basic skeleton and apply said animation to all models.

    If you want bigger and smaller characters you can do that too, so long as you keep the proportions the same. Some animation packages are smart enough to apply animations to skeletons with different limb sizes, you should probably look into that.

    (Also I'm a backer on the kickstarter you mentioned. He's missing exactly what you're offering).

    I really love the idea of heavily customizable characters, I just don't see how this could be done for high-res sprites of that kind.

    I don't see how resolution is an issue.