uFrame 1.0 is almost here!

Community Showcases
1

uFrame 1.0 is almost here!

If your Developing your Game with Unity why do you need uFrame?

Ask us at invertgamestudios@gmail.com

2

I have used MVC, MVVM and all possible variations on these doing web/app development. While I can see the benefit of a larger framework to structure development, this seems so overly complex and just made convoluted on purpose. I read all of the docs on your wiki/site, and they really do not explain what this is good for (other then that you say “this is good”, several times…)

3

Hey,
Thanks for putting you’re thoughts in. I understand it might be hard to see the benefits or seem complex and convoluted at a glance. I too said the same things when first learning such a different way of doing things. But over time and a little bit of faith in the idea, I saw that using a pattern of this nature made things a lot easier throughout the life-cycle of developing and releasing game. And once i got it, it was a lot more fun and exciting for me to develop each and every aspect of a game.

There is no denying that there is a learning curve and will take a little bit to get used to the paradigm. But even with the learning curve you still will gain that time back in the countless hours you’ll save using something like this. We’ve had more than a few less experienced developers use uFrame with similar regards at first. After taking a little time to learn and with a few questions here and there have really taken off with it and are loving how organized their project is and how confident they feel about their game in all aspects.

uFrame is a different way of thinking and I can see how it seems somewhat complex or convoluted at a glance. But if you’ve seen other projects of larger scale like I have “complex” and “convoluted” doesn’t even begin to describe them.

Here are some things I personally have concluded after using the framework for quite some time now.

  • Things are easy to change. New ideas always come up when working on a game. Why not have the structure in place to easily test out new functionality without breaking things.
  • I became a much better developer and a lot more disciplined about creating one piece at a time.
  • Using the component model for everything in a game tends to lack consistency. Trying to do everything using the component model left me pulling my hair out ( and at times yelling at my screen… :p) For example: when trying to connect a Targeting System to an AI system became very hard, confusing (especially to other people joining the project) and ultimately resulted in some elaborate hack to make it work right. Then later in the project needing to connect all of that into a HUD and ended up reworking the same thing yet again.
  • Other developers working on the game were less likely to break the game and had more room to expand on an element of a game without worrying about me crying hysterically because they broke my hack.
  • It’s a lot easier to come back a month later and jump right back into a project cause everything works in a similar fashion.
  • A team can develop in a consistent manner and can work on/understand any aspect of a game because the only have to understand the concepts of the framework.
  • Developers with less experience could edit and modify aspects of the game without having to know every part of the game in it’s entirety.
  • When I completed something in the game I would rarely have to revisit that section of the game unless I was extending upon what was already there.
  • It gives teams the ability to work on separate aspects of the game at the same time without running over each other. For instance when using a ViewModel’s for the interface a HUD designer could work in one scene without affecting the game-play scene. Connecting these two together was really easy. This increased the speed and velocity at which the games were developed as well.
  • I’m able to reuse things from game-to-game. I created a IOS HUD that was similar to a level manager. Since uFrame enforces things to be independent, I’m able to take that same HUD and connect it directly into other games as well. This can save you loads of time and really shorten the development life-cycle for any future game you may be working on.
  • A lot more but my list is getting very long :slight_smile:

Developing a game usually has some sort of process from beginning to end. It varies from company to company or developer to developer, but most successful games most likely follow a process more or less something like this. This is a minified list and different games/teams may vary but i’m sure you’ll get the idea.

  1. Define elements of the game ( HUD, Inventory, Player, Weapons, Spells…etc).
  2. Write the core logic of how these entities connect together. ( Ex: a player can have 4 weapons at a time until their rank goes up to 10 and oh i need to tell the HUD about this when it happens so the user gets a nice message letting them know).
  3. Build the basic visual side of the elements connecting it to the core logic of the game. This is where the editor and component model really comes into play.
  4. Add polishing touches such as a sweet sound track, sound, visual effects, and other small things to events that occur throughout the game.
  5. Connect menu scenes, environment scenes, loading-screens, game-play scenes and HUD together in a intuitive and user-friendly manner.
  6. Connect to services such as Facebook to make a game more engaging and connected to the outside world.
  7. Test, Test, Test
  8. Deploy the game to you’re eagerly awaiting supporters on the various different platforms you choose to support.

With that stated, I found that Unity really only provided an easy way to work on step 3 and somewhat of step 4. It’s really easy to get lost in the other steps of the process. So we wanted to provide a solution to better support this kind of workflow. uFrame is built around this approach of developing a game and has taken each step into consideration.

Maybe it would make sense to put this list on the front page and explain how uFrame is involved in each step of the process. Or even do some video tutorials that walk you through each step of this process. What do you think?

A lot of developers spend a lot of time developing something similar for their projects even if they don’t realize they are doing it. This can be time consuming and ultimately take time away from the point: “To get the game out there”. So we felt if we released it indies could spend a little less time focusing on the structure and more time building the game, minus a short learning curve for first-time users.

I did a site search on “this is good” and couldn’t find it anywhere LOL :p. But maybe you missed the “Introduction to MVCVM” article on the wiki page. It goes more in depth of each part of uFrame and explains the why’s and hows. If you have any idea on how to improve this as well I have 100% open ears to your opinions and I’m almost always available with email and Skype.

Here is a link to it.
http://invertgamestudios.com/wiki/doku.php?id=mvcvm_explained

Thanks for taking the time to read my novel :stuck_out_tongue: and I hope I’ve addressed the question properly!

Let me know if you have any other questions! I’d be more than happy to go more in depth over Skype or any other means of communication that best suits you.

Cheers!

4

Another Great Review:

Amazing
by Brad Turvey, 30 Mar 2014
I have been using uFrame for a few days now and I can honestly say it has changed the way I use Unity. After the initial learning curve I have not slowed down once, I’ve just been churning out code. I don’t have to stop and worry about creating spaghetti as as long as I follow the conventions, everything just wires up and works. I had to do a few small refactors at the start when I was getting used to the workflow but apart from that it has been smooth sailing.

It is amazing how simple, previously complex tasks become. It is a great iterative process that actually feels like you are creating something.

Looking forward to see what you guys do in the future.

We want to thank everyone who is using uFrame.

5

micahoz123,

I am a complete novice in this way of development, yet it looks like you have something quite useful here. :smile:

I was wondering if it would be possible to “encapsulate” uFrame’s method of application development into some kind of “visual tool” front-end (perhaps something like plyGame’s Blox system or Playmaker’s visual editor, or the discontinued Brain Builder’s snap-together block method - something where the user can stick the references to their game assets into the appropriate “form”, and yet be flexible enough to specify unique game play logic so everybody’s games don’t all play the same.

Maybe I’m asking for “pie in the sky” here, but I am wondering if you have any plans for moving uFrame in this sort of direction. If you do, I think you’ll have a larger audience of designers and developers buying your product.

But it looks fantastic so far.

6

Do me a favor and email this question to:
invertgamestudios@gmail.com

We have some great things we are working on.

7

Hey GameBoy,
I apologize for the delayed response apparently i wasn’t set up to get notifications on this forum yet. None the less I am now :).

We’ve actually been working on something right along the lines of what you are talking about. It’s on our web site and will soon be released with uFrame.

You can get a more in-depth view of this on our site at
http://invertgamestudios.com/ubehaviours

I can’t be exact on the day it’s going to be released but I can say it is within the next couple of weeks. This is just the start of tools for uFrame there will be much more to come in the future.

8

I’m sorry to say that I kind of agree with this opinion. Yes, IoC is good, messaging is good, MVVM has its uses. But all of those can already be done without needing a monolithic framework and the cognitive overhead it adds. It’s not clear to me what uFrame is bringing to the table.

I’m sure it’s just a combination of me being a little slow today and the documentation needing a bit more work.

It’s still an impressive effort. I with you guys (and gals) the best of luck.

9

I too would agree that it is quite difficult to see what the plugin provides, since those following the MVVM framework already write their code in a similar fashion. I do not see the point of purchasing uFrame as one can easily implement this in their project by simply following a framework (MVVM) that has been around for a long time and has been well documented.

I am however intrigued by uBehaviours, it seems like a very nice implementation of the framework and something that would be useful to developers. Will uBehaviours be packaged with uFrame or will they be separate plugins? In case you are planning on selling them separately, have you decided on the price of uBehaviours and would one need uFrame for running uBehaviours?

10

uFrame does favor some MVVM concepts. BUT!!! It’s NOT MVVM, and this may be our fault for throwing that acronym around to many times. It’s a mixture of MVC and MVVM that we felt better fit the game development paradigm.

Yes you’re totally correct that can be done. But i can’t imagine Microsoft (the inventor of MVVM) telling all of their millions of developers (far exceeding Unity’s user-base) that they need to just do it on their own without providing any sort of framework for them. Also in my opinion this would be a poor business decision. It would take someone 6 months to get to the point where uFrame is at least, not to mention the additional time for continued maintenance. This time only costs you money in some form or fashion. And if you calculate the man hours it far exceeds the $95 price tag of uFrame. It has also already been tested in different environments. When developing a games before creating uFrame i spent countless hours just getting things to work with the 100’s of nuances for compiling to iOS and Android that it became a project in and of itself. With uFrame this headaches have been done for you.

There is next to no overhead. And to be frank, there’s much less overhead because when things are consistent you’re less likely to hack things to make them work together. When you hack things you’re usually suffering some sort of performance or maintenance penalty. You would otherwise have to redesign half of the work you’ve already done to make it work without the penalty. And even then there’s the question “What new hacks will arise once it’s changed and as the project moves forward” thus creating a vicious never-ending cycle that drives you insane and much harder to complete and understand a game. Have you ever seen a large game that isn’t following a similar model? I have and man that is what you call cognitive overhead. In uFrame all you need to grasp is a few key concepts that really aren’t that hard to understand when given a true chance. You’ll see that there are so many new opportunities and directions for a game that arise simply because you see how easily they can be done. This can only come from truly giving it a chance and trying it.

uFrame does the exact opposite of add a cognitive overhead. The only alternative is a million (exaggeration :p) different separate subsystems that simply do not work well when put piecing them together. But! I can see why you might think that, simply because its such a new concept.

MVCVM or MVVM is very hard to explain to people that have never used it before because it’s a new concept. We somewhat understood this when building uFrame and knew it would be challenging to get Unity developers up to speed on the subject. We just didn’t know that there were so many game developers not familiar with such concepts. But at Invert we swear by it. That may not be enough for some right now but there are already 35 - 40 games being developed that are using it and not a single refund has been requested. We keep tabs on our customers and over time you’ll start to see how developers are drastically benefiting from it. Especially as we begin to start showcasing games that use it and develop tools that compliment the system. Then you won’t just have to take our word alone from it.

uFrame is there to give a more step-by-step iterative process to developing a game and I am in the process of creating a very detailed video and presentation of the MVCVM process and how it can actually drastically improve your experience and process when developing a game. We feel a lot of Unity developers are looking for something like this but are a very weary about trying something so new. With time we feel this will change.

I agree and disagree at the same time about the monolithic framework part. It must be really encompassing simply because games are complex in nature and this is no easy task. You’re literally playing god and creating you’re own world when creating game.

This is why when designing uFrame we studied and created frameworks for both MVC and MVVM verbatim. These were quickly thrown away because they just didn’t fit into the games paradigm. But there were key concepts from both that were extremely helpful. This is where MVCVM was born. It wasn’t just thrown together in a night and released. Its the result of over a year of intense research and testing on the subject ( with already having over 10+ years using, studying, and researching methods of developing software/games/ and web ). We are continually working on better representing/explaining the product and have many ways of doing so in the works.

Its kind of like this. And pardon my example but i think it’ll help maybe. If someone tells you a drug is good or bad it’s easy to quickly build a perception and believe that you already know if its good or bad. But you’ll never actually know until you try it for yourself.

So I highly encourage anyone to study how they can benefit from these paradigms with more of an open mind (even if its not uFrame) towards it and to not be quick to mark a big X in you’re mind. I promise with enough effort and study you’ll be thanking me for years to come :stuck_out_tongue:

11

Packages will look like this.

uBehaviours (Single Package not requiring uframe). We are going to start out at $45 as an introductory price. (Subject to change)
uFrame + uBehaviours (Single Package) uFrame will come with uBehaviours and some extensions for it. Anyone who already has uFrame will simply update to get the newly included uBehaviours. We feel this will give the $95 price tag a little more justification for those who don’t understand it yet.

If you have any more questions let me know :slight_smile:

Thanks for all the thoughts guys we highly value them!

12

Thank you for taking the time to reply in such detail and for being open to feedback.

You bring the example of Microsoft’s own frameworks that use MVVM. I’m only familiar with MVVM as it’s done in the ASP.NET MVC framework, and the benefits using it there were rather obvious. Sure, they did the leg work of explaining the benefits, but for me I only had to look at one example for it to click in my head and for its usefulness to become instantly apparent.

This isn’t happening here. It’s not apparent why this is useful. And your whole reply amounts to saying that I need to take a leap of faith and believe that the benefits will reveal themselves to me down the road.

Again, I’m sure these are all communication and documentation issues that can be addressed.

13

Thanks Michael for the info, the prices make much more sense with the the included plugins, definitely going to purchase this by tomorrow.

14

MVVM isn’t in ASP.NET. It’s in Silverlight and windows presentation foundation (WPF). It’s the model they’ve pushed for just about everything windows now.

I guess i’m just not sure what you’re not seeing. Its hard for me to explain the benefits simply because i understand it already and i’m not exactly sure where it’s going wrong. I kind of feel overwhelmed at the questions cause it’s like a friend that doesn’t know anything about programming asking you how to write programs. Where do you begin? lol

I guess if i knew where you where getting lost or things just weren’t clicking i’d get a better idea of how to answer the question.

There seems to be a lot of people that get it and a lot that don’t. But i lack any knowledge of why some aren’t getting it. It’s such a complex thing to just have one short and simple answer for. But if i give a long answer people get lost and can’t see the picture. Can you help me out here? :slight_smile:

How is ASP.NET explaining it so differently that makes it click? I just want to know so we can do a better job at it documenting and displaying it. Any insight as to what we can do differently would help!!

And did you read the first long reply i wrote? To me i felt like it summed it up pretty good. But i may be wrong.

Thanks Guys!

15

Actually it is there, the VM part at least. Every time you do a return View(model) from a controller you’re using the VM part.

That’s not a kind analogy to apply to a programmer who was a potential customer two posts ago. :slight_smile:

I think it’s unfair of you to ask me to explain it to your satisfaction when there was, by you own admission, a lot of people who felt the same and yet couldn’t communicate their issues to you.

Anyways, I’m done here. Good luck to you and to your many satisfied customers.

16

Good one :stuck_out_tongue:

@Micah - I think the best way to get people to understand the framework would be to have as many example videos as possible on your website. I would recommend not to post any more videos explaining the MVCVM but rather its application (in as many ways as possible) in how it will improve your code as well as reduce programming time in the future - I think this is extremely difficult to see based on the current videos.

If I was someone who did not know MVVM to begin with I would have a very hard time figuring how this framework would help me especially because it would have required me to spend time learning it and that is what makes a huge difference for developers, they don’t mind spending time learning if they have an idea what the outcome will be (which in this case is difficult to see). I would suggest making videos of a simple task and then adding more functionality slowly to that task to show the viewers how easy it will be to add new tasks using the framework. I understand that this is not as simple as explaining how to use visual tools such as playmaker or behavior trees, however if you take the same approach they did the viewer will soon forget the complexities of the framework and appreciate the possibilities it provides (some developers may not even know what states mean in terms of the framework in which FSM works, however they know that a state has some actions and it changes states when some condition changes and they go from there). You thus would need to remove the fear of complex coding by showing multiple videos that systematically explain how a simple task can be improved upon by only a few lines of code so that they appreciate what the plugin does rather than only focusing on what it is built upon.

17

I have to agree with iamsam. A more gradual introduction (or a description of things working from a more general higher-level viewpoint to a more detailed lower-level viewpoint) would be helpful.

I think what might be happening is that the uFrame developers are too close to the implementation code in the level of their tutorials, describing everything from a developer point of view, keeping many (e.g. about half of us guess from some of the comments made above) from seeing the forest because the tutorials tend to lose us in the lower-level code “plumbing” trees. I think the names of things reflect this. For example, instead of calling the major uFrame entities GameManager, GameType, Controller, ViewModel, and View, perhaps use the names GameManager (OK, that name is alright), SceneContainer or ElementContainer for GameType, ElementInitializer for Controller, ElementBehaviorLogic for ViewModel, and ElementVisualizer or ElementView for View. Or some other names that more effectively describe what it is these uFrame entities do, not jargon lifted from an implementation of how they do it.

While it is nice to know that because of iOS constraints, properties have to be bound to a readonly internal variable that itself is implemented as a delegate for performance reasons, why not just have a tool that lets the game developer specify a property, and uFrame automatically generate the boilerplate code that implements the property in the correct way. Hopefully in the future uFrame will have this kind of functionality to bring greater simplicity to game development, which is what Unity strives to do.

But uFrame definitely looks to be a solid framework upon which to build games with.

18

Shaderdrop. I think you might have misinterpreted what i said. That really wasn’t directed towards you and was meant as more of a general statement. But i agree it was a stupid analogy to say. I sincerely apologize if i insulted you in anyway as that was not my intention. I haven’t had much practice at documentation and explaining things so I’ve just been frustrated at myself cause it’s been a struggle to find the right way to explain it and i guess it just came out in the wrong place. So again i’m really sorry!

You’re totally correct I was speaking more in the sense of MVVM in it’s entirety.

I wasn’t asking for it to be to my satisfaction simply just something more than “I don’t see it”.

After re-reading my post i realize i came off somewhat harsh. So again it really wasn’t towards you at all and i’m sorry. Best of luck to you as well!

19

@gameboy and @iamsam Thank you so much! This is probably the single most valuable information I’ve gotten from anyone so far about how better to explain uFrame.

I think this helps me understand where you guys are coming from. And getting a little more inside the head of most unity users.

From what you guys mentioned it gave me the idea of a video series. A series that goes through each step of the process of developing a game and at each step, what uFrame does to help it at a high-level. So the video titles might be something like this.

Each step would be a video or a series of 2 or 3.
Developing Games w/ uFrame Series
Introduction Tell a little bit about uFrame and the process most everyone takes with developing a game and how uFrame makes this better and faster.
Step 1. Defining the elements of you’re game. Walkthrough ViewModels
Step 2. Building the core. Creating and implementing controllers and breifly dependency injection.
Step 3. Bringing the scene to life. How Views work and how they are connected to the scene.
Step 4. Adding the polish How uFrame’s bindings (and soon to come ubehaviours) makes this a breeze
Step 5. Creating Menu’s Creating LoadingScreens, MainMenus, Using the gameManager and more.
Step 6. Connecting to services such as FB or twitter. Using the controllers to connect to 3rd party services.
Step 7. Final touches Talk about iOS considerations and other platform nuances that uFrame users need to know.

I personally think this would really spell things out. What do you guys think? i’m really curious to ya’lls(yes im from the south :p) opinion if i’m on the right track here. Feel free to edit or modify if you see fit.

@gameboy I really like the idea of the names you came up with. But only with small modifications.
SceneContainer is perfect it makes sense because a GameType isn’t tied to an “Element”
ElementController I like ElementInitializer but the name is somewhat limiting since this is actually where the logic goes as well.
ElementDefinition I think this more or less describes it better than ViewModel.
ElementView I really like this one. Its more descriptive and makes “Elements” feel a little more tangible if you will.

Also I’ve begun to prototype a ViewModel builder to make this process completely editor based. I really like the idea.

Again thanks for giving me such valuable input you guys! It’s really going to help me get this right! If i’ve come off as a jackass i’m really sorry :stuck_out_tongue:

20

@micahoz123 Your idea sounds great! As for my names, they were just suggestions to get the ball rolling. But glad it was helpful! :slight_smile: I am for anything that makes it easier to understand what uFrame does. Since uFrame is your own amalgam of MVC and MVVM, you might as well use names that are useful to Unity development with uFrame.

I think your proposed video plan is excellent, and will look forward to seeing them.

Another idea crossed my mind that might be helpful in this whole “explanation” issue. If you know of a good writer or tech writer, try explaining it to them and ask them to write about what you told them. Perhaps they could put things in terms that less hard-core programming specialists can grasp. Well, it’s just a thought, anyway.

EDIT: Oh, I almost forgo to mention - I can’t wait to see that ViewModel (or should I say ElementDefinition builder)!