Zenity's Forum Posts

  • 7 posts

  • >

    > If your goal is to make a complete game by yourself, then Unity will probably get you there faster (not as fast as Construct 2). If your goal is to become a competent game developer with a specific focus, UE4 is probably the most promising tool to learn right now.

    >

    >

    Just curious, what makes UE4 take longer? I've watched some tutorials and played with both Unity+Playmaker and UE4, and it seems like UE4 has a lot of tools out of the box that help get things going. I'm still watching the tutorials of course, so I haven't looked at every aspect.

    The sheer size of it. Like you say, there are a LOT of tools. And all of them are pretty complex by themselves, so it's most suitable for cooperation. Projects also tend to be big and heavy, which leads to slow compilation times, downloads, etc. Maintaining builds can be more complicated as well.

    There isn't a huge difference between the two (they are still the closest thing to each other), but all in all I would say that UE4 is more user friendly with specific tools or tasks and Unity is more user friendly with regards to setting up and maintaining a complete project by yourself.

  • I'm not sure if they even build laptops still that wouldn't be sufficient for this job. Just pick any recent budget model that appeals to you. Integrated intel graphics are perfectly fine (I have that on my laptop, which is an Asus VivoBook).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 3D is a toss up, UE4 is more professional and considered as such while Unity has a reputation for being more indie friendly, as in, when you become really skilled with C+, UE4 will allow you to achieve much better visuals easier.

    My take on that (although my Unity experience is limited) is that UE4 has a lot of features which make life easier (Blueprints being one of them, but also the fantastic integrated networking support, and a lot more), but due to its sheer size and complexity it is much harder to get a grip on everything that you need to know as a solo developer or small team. So Unity is a bit more tailored towards those, while UE4 has its strengths with somewhat larger teams with specialised developers.

    If your goal is to make a complete game by yourself, then Unity will probably get you there faster (not as fast as Construct 2). If your goal is to become a competent game developer with a specific focus, UE4 is probably the most promising tool to learn right now.

    I wouldn't focus much on what kind of visuals the engines can achieve though. Indies cannot compete on graphical prowess alone, so being able to implement your vision efficiently and quickly is far more important. This is a bonus for UE4 mainly because it makes the engine feasible for AAA games, which means that your skills will be highly relevant if you seek employment in this sector.

  • You really don't need to worry about Blueprint performance, its impact on overall performance is minimal. You'd have to do something pretty extreme for Blueprint performance even to be a factor.

    Optimizing this by converting to C++ will be cool, but hardly necessary.

    You cannot compare this to the speed of JavaScript in C2 either, since in C2 the entire engine is written in JavaScript so it has a much bigger impact.

    The main reason to use C++ with Blueprints is better flexibility. You can make complete games in Blueprint, but it will always be limited compared to what you can do with C++.

    There is no point discussing which is better though, ideally you know what you need for your game and then pick the right tool for the job. Unreal Engine is much heavier and that makes it less suitable for certain game projects. I would pick Construct over Unreal for 2D prototyping and for 2D games which should be as accessible as possible (e.g. web based and light weight).

    HTML5 games have a very interesting future and while Unreal and Unity can convert to it, Construct uses it natively. That does make it a lot easier for example to integrate with other web based frameworks.

    I also appreciate that Construct loads up super fast on any laptop, which makes it ideal for prototyping or working on smaller games on the go.

    There is no one tool to rule them all, and I don't think there will ever be. The important thing is to be aware of the strengths and weaknesses and take the most possible advantage of it. That's why I find it pointless to ask for 3D or native exports in Construct, just like it would be pointless to ask for Unreal to be significantly simpler.

  • Everytime when I see post like that instantly I'm seeing UE4 blueprints in my head. There is really no point to compare epic to scirra (hundreds of hands vs only few couples) but they have nice system with object blueprints and level blueprints working together.

    So maybe this is a thing worth do some tests. Not only to make events more clear - you could have object events on objects only and everything else on level events, but maybe level events could work on 1 cpu and objects on another etc.

    And on the other side this kind of system have more sense, at least from my point of view. Even for beginners who tends to make one huge and messy event sheet with everything on it. "Double click on sprite to add some logic to it" feels more natural and most engines are using similar approach. You don't make just one text file full of code for entire game to compile.

    But I'm just a user, so I'm just saying what I see xD

    Maybe that makes sense, given that Blueprints also evolved like that. The Kismet predecessor only had global level scripts, then the system was extended to be (optionally) object oriented with Blueprint.

    Maybe it wouldn't need anything complex even to make this useful. Simply being able to assign event sheets to objects could be helpful already, with no major difference other than defaulting to "pick all instances of this object" for all events in such a sheet. Allow sheets to be assigned to more than one object and you even have reusable sheets that work on different object types, which would not be far off from adding behaviours. Perhaps also add an abstract object type to hold data and/or events only, so Sprite doesn't have to be abused for this.

    Another thing I'd like to see is an evolution of the Function object, perhaps by creating a function behaviour that can be assigned to objects to create "member" functions. So we could do something like MyObject.Function.Call("MyFunction"), which triggers MyObject.Function.OnFunction.

    The only issue with that (and Function in general IMO) is that the syntax is really cumbersome, so why not make Function a first class feature of the editor, with its methods exposed by each object? Then you could just write Call("MyFunction") or MyObject.Call("MyFunction") instead of Function.Call("MyFunction") and MyObject.Function.Call("MyFunction") respectively.

    I don't believe those changes would make the editor significantly more complex if you don't need those features, but provide a pretty significant quality of life improvement for more complex development.

  • As a freelancer my honest opinion is that no, it's not likely to pay off. If you have a lot of money to spend and experience in the field combined with a fantastic and unique concept, then yes, the investment can pay off. Chances are much higher though that you will make nothing in return.

    If you don't know exactly what you are doing (and by your own admission you don't), then I would only recommend hiring a freelancer if the project is one of passion and you are ready to see your investment lost for the sake of simply completing the game.

    Online features are always more complicated then it seems, so it wouldn't be cheap. Cautiously I would expect costs in the high four digits, if not more. Unless you get a novice developer, which will reduce your chances of success even more.

    Most likely you'll be better off doing it by yourself (reducing the scope if necessary) and consider it a learning experience. If you want to get into the business of financing games, then of course you can also take the investment as a learning experience. Just be prepared for it to be an expensive one.

    An alternative would be to find another less experienced but talented developer to complete the project on revenue share basis. Of course the challenge with this is to convince a talented dev that your project is worth it. On the other hand, if you can't do that, it's also very unlikely to be a commercial success to begin with.

    If however you want this to be a portfolio piece, so you only need a dev to implement the most basic online features to make it a working game demo, then there's nothing wrong with hiring a freelancer for the task (and it will be much more affordable). I would forget about the freemium part in that case though.

  • As a "real programmer", I believe the sweet spot for a game making tool is one that makes the simple things as simple as possible, and in the rare case that this is not sufficient, provides unrestricted access to a powerful programming language.

    My favourite tools in this regard at the moment are Unreal Engine 4 and Construct2, which both strike that balance perfectly IMO. The Blueprint system in UE4 is extremely intuitive and efficient, while being able to extend it with C++ guarantees that there are literally no limits to what can be done with it. The only downside of UE4 is that it's too complex and heavy for some kinds of games.

    That's why I've chosen Construct2 as an alternative for lightweight games, as the event system and smart UI are fantastic for quick prototyping and game logic, while JavaScript is a solid language under the hood (especially since the export is always HTML5, so no extra glue is required).

    GameMaker didn't appeal to me at all, because its drag and drop UI is not very well thought out (nor powerful), and the scripting language is nothing to write home about either. It works, but that's about it. I don't use C2 because it's "good enough", but because I genuinely believe that for a certain type of game it is a best of breed tool. I cannot say that about GameMaker.

    Even if you don't know how to program in C++ or JavaScript (yet), you can always hire somebody to fill in missing pieces if required. In the long run, I'd say it's more fruitful to have a tool that makes the 90% of your workload as easy as possible, especially if you don't intend to specialise on being a programmer.

    HTML5 may be a limitation on mobile at the moment, but it seems to be improving rapidly and should be a non-issue fairly soon. Especially for the kind of games that Construct2 excels at, and for anything with more complex requirements (and/or three dimensions), I would recommend Unreal Engine 4 anyway.

  • 7 posts