Sign in to follow this  

Unity Unity vs. a more "lean" game engine

This topic is 671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, it's been a while since I've posted.

 

I'm looking to start a new game project. I've been developing software for a long time, and I recently started learning some 3d game programming (through a university class) with jMonkeyEngine. It's going great! I'm getting more and more comfortable with 3d programming. I still have a ton to learn, but after spending just a few days playing around with jMonkeyEngine, I'm getting the feel for it.

 

The person I'm collaborating with is an artist (2d, 3d, textures, models, level design, etc.). We're trying to find the right tools for our first project, which will be a 3d game with some simple mechanics. He's played around with Unity in the past, and suggested that I check it out. I'm on the fence, to be honest. I'm a software developer at my day job. I like things to be lean, clean, and minimal. I code in vim mostly. I avoid IDEs like the plague, except in the case of Java, which makes my fingers hurt if I don't have some good code completion. ;) jMonkeyEngine appeals to me because I can just start writing code. Every time I've tried to dig into Unity in the past, I never could grok what is going on; it just seems like a lot of magic. It seems bloated and verbose, and the everything seems very tightly coupled together: level design, game objects, and game "scripts" all just thrown into one massive GUI. I found it noisy and unreadable. Despite all of the good things people say about Unity, I honestly just don't have a good first impression of it.

 

On the other hand, because everything is integrated, there's no need to figure out how to handle asset pipelines, level design/building, etc. (With JME, for example, I would have to figure all of that stuff out for myself, and maybe even build custom tools just to put everything together.) So already I can see some tradeoffs. In Unity, I/we could build our levels by basically just dragging things around in the graphical editor. With JME, I'd have to either a) find a secondary tool to help me model the levels, b) write my own editor (not ideal), or c) just do everything in code (also not ideal).

 

So finally to my questions: To those who have experience with Unity, is my initial impression at all accurate? To the veteran programmers out there, what's your opinion of Unity, especially in terms of its programming approach? If I go the "leaner" route (even with a "batteries include" engine like JME), am I going to have to end up writing all of the stuff that's "missing" (which Unity already has)?

 

I understand that the use of tools and the approach different people take is highly subjective. I'm really interested to hear peoples' experiences and opinions on this.

 

Sorry for the long-winded post. I appreciate any feedback! =)

 

Cheers,

-Lars

Share this post


Link to post
Share on other sites

Unity handles lower level stuff for you (Importing animations, cutting spreadsheets, importing sound) allowing you to focus on your game.

 

You can either use Unity, and focus on your game, or use another program, and have something more tailored to your needs.

Share this post


Link to post
Share on other sites

I've used unity since version 2, so I'm pretty familiar with it. I'd say your first impression is correct, but possibly you may be missing alot of its perks.

 

Overall, I like unity, but as I've become a more advanced programmer, I find it more constraining. I was mostly drawn to it because I started as an artist with some programming skills. It really enables you to get art assets working quickly. You can have a functional 'game' working with a handfull of assets and simple scripts. However, if you do anything that goes "against the grain" and you're trying to do something unity wasn't designed to do, it becomes more of a hassle to deal with.

 

If you're doing anything suffeciently advanced or against the grain, unity ends up being a bloated IDE with auto re-targeting. It's hard to say whether that will be the case with any given game though, unless you know Unity's capabilities and constraints.

 

If you decide to opt-out of using unity's phyics, level-design pipeline, animation, and rendering/materials, then you're better off using something else. If you're only ignoring 1 or 2 of those, it's probably better to stick with unity.

Share this post


Link to post
Share on other sites

I've used unity since version 2, so I'm pretty familiar with it. I'd say your first impression is correct, but possibly you may be missing alot of its perks.

 

Overall, I like unity, but as I've become a more advanced programmer, I find it more constraining. I was mostly drawn to it because I started as an artist with some programming skills. It really enables you to get art assets working quickly. You can have a functional 'game' working with a handfull of assets and simple scripts. However, if you do anything that goes "against the grain" and you're trying to do something unity wasn't designed to do, it becomes more of a hassle to deal with.

 

If you're doing anything suffeciently advanced or against the grain, unity ends up being a bloated IDE with auto re-targeting. It's hard to say whether that will be the case with any given game though, unless you know Unity's capabilities and constraints.

 

If you decide to opt-out of using unity's phyics, level-design pipeline, animation, and rendering/materials, then you're better off using something else. If you're only ignoring 1 or 2 of those, it's probably better to stick with unity.

Gonna take over OP's thread for a second (Sorry!).

What would be an example of "something else"?

Share this post


Link to post
Share on other sites
There are many game engines other than Unity. Some are little-more than frameworks that try to give you some extra game-centered features, others are full-blown engines that are ready to run at the beginning.

All of them offer tradeoffs. You use their system and do things according to their patterns. This comes with the consequences that their patterns may not be the best fit for your game, and pairs nicely with "not invented here" syndrome.

Bigger systems tend to come with more features. Many of those features are powerful tools or emerging technologies, or valuable to different size teams, which you may or many not use. If you use it, you call it a feature. If you don't use it, you call it bloat.

Using an engine means you save yourself many work-years of work for building and debugging and integrating the features. That is, unless it is a feature that you don't use, then you consider it a waste and bloat and useless to you.

You also get an ecosystem of experienced developers who can help you, although the size of that ecosystem varies by system.

Share this post


Link to post
Share on other sites

I do most of my hobby game dev in C++, ranging from writing low level engine stuff to using existing engines. The first time I started up Unity I was like dude...? Where the hell is my main? Where do I start typing!? After a short while I got the hang of it and now it's my go to game engine when I need to whip out a game in a few days for a competition or something similar. It's nice for things I don't what to think about much, but I'm also a stickler for control so I only use it for small time stuff.

 

I wouldn't worry too much about your first impression. There's an easy way for you too find out: just make a simple game in Unity, finish it and then look back and reflect. It doesn't have to take long, you could probably do it in a weekend.

Share this post


Link to post
Share on other sites


Gonna take over OP's thread for a second (Sorry!).
What would be an example of "something else"?

 

I'd say either Unreal, or one of the other open source "engines" (libraries) that are available. If you've got the skills, I guess you could do some sort of custom engine too, although it seems unnecessecary to reinvent the wheel. It would probably be better to start out with a game-centric library and expand upon it.

 

I think that unless you're doing something very high-end, or something really strange, unity is workable. The exception here might be if you're doing something that requires a specific type of system that unity doesn't have - such as dynamic-ish water effects or wind or some other physics-related sytem. Even then, it may be possible to modify unity to work with a seperate physics system.

Share this post


Link to post
Share on other sites

Unreal

I don't think Unreal is going to be any less alien than Unity, to be honest.

You trade the "Unity way of doing things" for the "Unreal way of doing things", which is equally arcane on first acquaintance, and I'd say Unreal has a steeper learning curve.

Share this post


Link to post
Share on other sites

I am also a long time developer working in business software programming in my day job.

 

I started with Unity in its Version 3.5 days. I absolutely hated it at first, the editor was overly complex for me, and the engine itself was really subpar back in these days (it still is compared to others, but its catching up IMO). I took 1.5 years off Unity and started using a different engine. While this engine was giving me much better results graphically, the editor was just unusable. Old school crap that made it hard to even place a single object. How anyone would go through the ordeal to create a full level in this editor is a mystery to me.

I really tried to like the engine and create something in it... but after the 1.5 years, I went back to Unity, and it did click with me.

 

Its the editor. It really allows you to be productive, once you "get it". I then started to use C# instead of Unityscript, and somehow the C# API also clicked with me. Don't get me wrong, there are just as many things that seemed counterintuitive or downright crap in the API to me. Sometimes you have to work with stupid workarounds to achieve a result because the engine does not support it.

But compared to other engines on the market, its still the better choice. If only for an editor that actually steps out of your way when you try to be productive in it once you learn how to use it.

 

 

I have now started using Unreal engine 4 for a new project. And while I again like the results achievable better than what I was able to achieve with Unity out of the box... things are just so different in it than in Unity.

Again, for me, the main adjective I would give to working in Unreal is "uproductive"... that might be me still being an Unreal newb getting to grips with the engine, or because what Unity did was actually make the work in the editor easier but neglecting other, more important parts of the engine...

 

Still, you are able to throw together a prototype in Unity and code the behaviour scripts necessary in hours, if you already have all the assets and a good plan. I couldn't think of a way to do that in Unreal. Everything seems to be so much more involved. The GameObjects in Unity are pretty much drag and drop, while the Blueprint System in Unreal seems much clunkier in comparison (again, could be me just not "getting it").

You can create many things in the Unity editor that need outside tools in Unreal (best example is cubemaps... without the PS plugin or the ATI/AMD Tools to create DDS files, not possible in Unreal. In Unity, just provide 6 images, and let the editor do the work).

 

 

But of course YMMV. I found that for me as a programmer, programming seldom is the time sink. I can program relatively fast in any environment, and I find it quite easy to adapt to most languages. I find the other aspects much more involved, setting up stuff in the editor, creating assets where necessary. Most probably because I don't have the years of expierience and a degree in it.

 

Still, that means for me number one priority in an engine is to make the assets and leveldesign part as easy as possible, with being able to program productively a distant second place. If programming gets more involved , so be it (in which case C++ in Unreal is much worse IMO. Unity lets you get away with much less code than Unreal IMO)... I am reasonably fast with programming either way. That means engines like CryEngine, that have like an ANCIENT, almost unusable editor fall to the wayside for me. I don't have a whole studio of guys that can try to come up with a pipeline and write the tools to "replace" the unproductive editor with something else.

 

 

So yeah, maybe try to step outside your own shoes and think about what would make your artist friend more productive. Chances are he will have MUCH more work to do than you as a programmer, depends on the project you are working on of course. But with the engine taking away lots of the low level plumbing, if the game is actually reasonable simple, the code might not be so hard to do anyway, while the amount of assets and level design needed might still be quite overwhelming.

If he is able to work faster in Unity, and you just "don't like it because the code looks unclean", but can work in it, maybe you should give in and let him have his way.

 

I can tell you, I have written A LOT of C# code for my last Unity project. Worked like a charm. There are times you need to get inventive with stupid workarounds as the engine just will not let you do what you need to do, but I gess you get these moments with all engines (or you start to waste time re-coding parts of the low level code of the engine, which is also not very productive).

And the normal work in Unity, once you get the hang of the component paradigm of it, is quite smooth. You can even combine it with normal OO if you are clever about it.

Share this post


Link to post
Share on other sites

I also bounced off Unity several times at first, especially coming from more code-centric frameworks like XNA.  Eventually you get used to it, and it's really not that bad.  It's really easy to write bad unity code, so you do have to be careful to keep things clean.  But that's not all that different than your own code.

 

And you'll definitely butt heads against certain portions of Unity.  Like it's physics, or wonky garbage collection.  But it's pretty nice for a designer or artist to be able to drop in art, and then go and tweak settings on scripts without having to modify the script.  And Unity's heavily used, so it's very easy to come across a blocker, and find the solution via a very quick websearch. 

Share this post


Link to post
Share on other sites

You will find that every engine/framework will have their little quirks and nothing will ever give you the 100% solution. With that in mind, its probably going to boil down to how much hoops you are willing to jump through to get your project off the ground. Try a few of the engine recommended in the previous post with a small project ( if you have the time ) and see how each work for you. Everyone workflow is going to be different, so what suits me may not suit you, so don't expect to get a wholehearted answer saying the engine is the be all to end all. Also, I like how the phrase re-inventing the wheel get tossed around, sometimes its more than that, maybe the wheel had flat spots and make for a bumpy ride. Unity didn't just magically appeared out of nowhere? Game engines existed at the time Unity was started, so imagine if the developers of Unity didn't 'reinvent the wheel'.

Share this post


Link to post
Share on other sites

The good reason is it gives them more fine control. The bad reason is it makes them feel superior and smart. (I'd rather not reinvent the wheel.) The third reason is not bad and it is simply that some people can't get their heads around Unity.

Good point. I do like having not only control but also _understanding_ of what's going on. But you have to draw the line somewhere, else we would all still be writing in assembly. =)

Share this post


Link to post
Share on other sites

I've been game programming for over a decade and used Unity for three of those years. Unity is the least-of-all-evils that I've seen so far (and *everything* is evil). It's pretty good in almost every way, but there is always a little hassle hanging around every dark corner.

As far as your first impression goes, it just sounds like you're complaining because it's not doing things your way right away. But of course it isn't, because it wasn't written by you. Nothing complex lacks a learning curve, so we must constantly learn and get used to doing things in ways we think are "weird" at first. Unity is more flexible than it appears at first glance, but if you haven't bothered to try, you will never learn.

You have to start off with at least one Scene with one GameObject with one script on it, but after that you can programmatically set up everything else. Or you can build scenes right in the editor. Or mix approaches. It's up to you. You can put scripts on GameObjects like usual, and you can run a single MonoBehavior which calls into a huge pure-C# game which only uses Unity as a presentation layer, or you can go the "normal" approach of composing behavior directly with MonoBehaviors. The amount of flexibility is pretty crazy compared to other "engines" I've used which force you into one and only one way of doing things.

This is exactly the kind of advice and voice of experience I was hoping for. Thanks!

 

I also hadn't considered creating a single behavior and just dropping down into code and do everything that way. Interesting idea.

Share this post


Link to post
Share on other sites


Overall, I like unity, but as I've become a more advanced programmer, I find it more constraining.

 

In what way? Can you share an example?

 


If you decide to opt-out of using unity's phyics, level-design pipeline, animation, and rendering/materials, then you're better off using something else. If you're only ignoring 1 or 2 of those, it's probably better to stick with unity.

 

Good point. Having never really completed a game, apart from some small tests and prototypes, I think whole development pipeline (code, level design, animation, modeling, etc.) is something I have greatly underestimated, or even just didn't think about very much.

Share this post


Link to post
Share on other sites


All of them offer tradeoffs. You use their system and do things according to their patterns. This comes with the consequences that their patterns may not be the best fit for your game, and pairs nicely with "not invented here" syndrome.

 

+1 for the mention of NIH. =)

Share this post


Link to post
Share on other sites


I wouldn't worry too much about your first impression. There's an easy way for you too find out: just make a simple game in Unity, finish it and then look back and reflect. It doesn't have to take long, you could probably do it in a weekend.

 

I think this is the single best piece of advice in this thread.

Share this post


Link to post
Share on other sites


So yeah, maybe try to step outside your own shoes and think about what would make your artist friend more productive. Chances are he will have MUCH more work to do than you as a programmer, depends on the project you are working on of course. But with the engine taking away lots of the low level plumbing, if the game is actually reasonable simple, the code might not be so hard to do anyway, while the amount of assets and level design needed might still be quite overwhelming.
If he is able to work faster in Unity, and you just "don't like it because the code looks unclean", but can work in it, maybe you should give in and let him have his way.

 

This is good advice. When we first discussed using Unity, by my reaction he was pretty sure I was going to say no. We've talked about since then and have decided to give it a try, but in a few months after my game development course is over. [I don't really have the mental bandwidth to learn two game engines at once, go to school, and work 100%. =) ] But we are going to give Unity a try.

 

In the meantime, we're going to work on something together using Blender and jMonkeyEngine. He's already done not only modeling but entire level design (relatively simple stuff) purely in blender, so we'll see how it goes. I'm going to be alert to the pains of the modeling/level design/art pipeline which are likely to come up, and then I'll probably have more of an appreciation for Unity. =)

Share this post


Link to post
Share on other sites

I share "love-hate" relationship with Unity smile.png I'm engine/tech developer. With the rise of modern big game engines, my role became less significant for game dev companies. Why to make own tech, when you can save lots of time taking what's easy to use and already pretty advanced. For small companies time is money, and money doesn't grow on trees. But on the other hand I observe and use Unity for research work. It gave me plenty of ideas for my own tech. Also I must admit - I really like Unity editor and I even considered it to make it "editor of choice" for my tech. Like most of people, at first I just bounced back from it, but the more I've been using it, the better I found it. Also easy portability, nice scripting language ( which is an actual programming language! ), the way it manages assets etc. It has lots of limitation though cause by being a general purpose product. This is the price you have to pay. So as much as I dislike Unity, there's part of me liking and appreciating it.

 

It was mentioned before that it's very important to consider what artists and designers will like to use. What would make their job more comfortable. It's not a secret that over last years there was a shift in the industry and it's now little less programmers-oriented and lot more artists-oriented. Of course, without programmers artists wouldn't be able to do much, but 90% of today games are about their content - graphics, animations, sounds, story, scripts, overall UI experience ( which programmers usually are very bad at designing it ). Game contains number of DLLs, main executable and tons, gigatons of resources. We may like it or not, but this is today's games industry. Unity makes it easy. As far as I remember even famous "The Room" ( not the film, although it's also very famous ;) ) was made just by artists and designers with use of Unity. I mean - no actual professional programmers got harmed in the process of making the game, because there were none involved smile.png

 

As tech developer I prefer to make my own engines but also I am totally aware that if it comes to make a commercial product this may not be an option (unless I have lots of money to sink). I think in the past I pasted on this forum few pictures from my remake of the "Desert Strike" game which was my attempt to "befriend" with Unity. It failed but not because of Unity. I could make it from very beginning to the end. What failed was my attitude of engine rather than game developer. I just don't find it exciting to work on actual game, but I like to see when the game builds on all the fundamental blocks delivered by the tech.

 

So as final note, Unity is and isn't great smile.png

Edited by j_uk_dev

Share this post


Link to post
Share on other sites


I just don't find it exciting to work on actual game, but I like to see when the game builds on all the fundamental blocks delivered by the tech.

 

I can really relate to this, actually.

Share this post


Link to post
Share on other sites

 


Overall, I like unity, but as I've become a more advanced programmer, I find it more constraining.

 

In what way? Can you share an example?

 

 

There are alot of examples, but I'll use my most recent. I'm trying to seemlessly blend 2 sprite animations ( say, move from "walk-cycle with gun frame 5" to "walk-cycle with sword frame 6" ) so the movements match up. Unity forces animations to restart when jumping from one to another. If unity was open source, it would probably just be a matter of tweaking the source. However, it's not and my choice are:

 

1) write a custom machine-state script that offsets the following animation based on where the previous one ends. However, I'm already using unity's animation-events, so that will upset the order (if a script runs on frame-1, jumping to frame 6 will ignore the frame-1 event until the cycle restarts) If unity allowed it, i could offset the events too, but it's not possible.

 

2) write my own sprite animation system. - which would take forever and i'd lose all of the great benefits of their current animation system.

 

3) suck it up and seperate the legs and torso so they can animate independently - which means reworking all of my sprites.

 

So in the end, #3 is the best solution because it's the quickest, but it's going to introduce its own problems. Primarily layers and a constraint on how I design the sprites. 

The reason this kind of thing becomes a problem as a I become a better coder, is often when facing an 'unknown', especially one that seems really simple and like a non-issue, I'll go ahead as planned and hope to find a coding solution. 90% of the time, I can find a solution. However, occasionally, I'll run into a situation when unity simply says "NO", and there's absolutely nothing I can do except either spend a month writing my own elaboriate custom solution (because of some tiny annoyance with unity) or just give in and follow the 'intended' workflow.

 

The further exacerbate the problem, if I opted to write my own animation system that interfaced with unity's editor, I'd more than likely run into big issues there too. I've gone down this path before, and it's a consistant problem. Their code for the editor scripting isn't as well-developed as the rest of their program. So, really, if i STILL wanted to do my own animation system, It would be better to write my own animation-maker external tool, then write more code to load the generated files into unity to get them to run correctly. At that point the question becomes "why don't i just use a more primitive library and design it all from the ground up?"

 

So if you want control and want things to work in a specific way, you often end up getting brick-walled by unity due to minor annoyances that end up with giving you the choice of comprimising and giving in to unity's workflow or writing you own system within unity - which is even harder than if u were using something more primitive.

 

So right now my relationship with unity is like one with an old girlfriend i've grown to dislike. I want to leave and have some independence and control, but it's not worth it to lose the many existing perks of the relationship. So, in the end, I often just say "yes dear" and do what unity tells me to do because fighting it ends up just being a headache.

Share this post


Link to post
Share on other sites

 

The good reason is it gives them more fine control. The bad reason is it makes them feel superior and smart. (I'd rather not reinvent the wheel.) The third reason is not bad and it is simply that some people can't get their heads around Unity.

Good point. I do like having not only control but also _understanding_ of what's going on. But you have to draw the line somewhere, else we would all still be writing in assembly. =)

 

 

The more I've progressed in my career and the more games I've released at work I've cared less and less of what is going on under the hood.  Getting results done faster and with (usually) less hassle is more important then being able to fiddle with all the knobs.  And thus Unity has become more and more my go to tool.  But when you want to do something that Unity wasn't built for then it is a massive pain because there are no knobs.  The native extension system for Unity is pretty good even on Windows and Mac if you need to do things Unity wasn't made for.  You can't change the physics system that Unity uses but if you need fluids or something you can write that in C++ to run fast in native land and pipe the results to your scripts.  Community support is super as well.  Nearly every question I've ever had has already been answered on Unity Answers.

 

One huge gripe I have is you are going to have a bad day if multiple people need to make updates to the same scene.  You can negate a lot of this by prefabing everything out but it sucks to go commit your change and see that somebody else has committed it first.  Scenes are saved as YAML so you can merge them by hand but it is a pain.  The other big thing is if you have a good sized project with a few hundred or more scripts Unity seems to like to recompile all of them if you make a code change so it can take several seconds to get Unity responsive again.

Share this post


Link to post
Share on other sites

This topic is 671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628724
    • Total Posts
      2984405
  • Similar Content

    • By INTwindwolf
      THE PROJECT

      INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War.
      Please note that all of our current positions are remote work. You will not be required to travel.
      Talent Needed
       
      Unity Engine Programmer
      Website Administrator
      3D Animator
      We have made great strides in the year 2017! INT has received a comprehensive face-lift compared to the start of the year. We look forward to a productive, fruitful year 2018!
      Revenue-Share
      This is the perfect opportunity to get into the game development industry. Being an Indie team we do not have the creative restrictions often imposed by publishers or other third parties. We are extremely conscientious of our work and continuously uphold a high level of quality throughout our project.
      We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the year 2018. Your understanding is dearly appreciated.
       
      Thank you for your time! We look forward to hearing from you!
       
      John Shen
      HR Lead
      Starboard Games LLC
    • By Apollo Cabrera
      Energy particles being harnessed by collection multi-hedron energy matrix. Whuuuttt?
      Love it :)
    • By AndySv
        Total Music Collection (http://u3d.as/Pxo)   THE COLLECTION CONTAINS:   Mega Game Music Collection   Universal Music Collection   Huge library of high quality music for any project! All at an incredibly low price!   - 2,5GB of high quality audio - 100+ different music tracks - Loop and short versions   Action, fantasy, casual, horror, puzzle, epic, dramatic, romantic, positive, inspiring, motivational and more!
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
  • Popular Now