uFrame 1.0 is almost here!

uFrame 1.0 is almost here!

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

Ask us at invertgamestudios@gmail.com

 

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...)

 

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.. ) 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

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 . 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 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!

 

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.

 

micahoz123,

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

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.

 

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

We have some great things we are working on.

 

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.

 

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.

 

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?

 

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 ) 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

 

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

Thanks for all the thoughts guys we highly value them!

 

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.

 

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

 

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?

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!

 

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.

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.

 

Good one

@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.

 

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.

 

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!

 

@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 ) 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

 

@micahoz123 Your idea sounds great! As for my names, they were just suggestions to get the ball rolling. But glad it was helpful! 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)!

 

I bought uFrame fairly soon after it's release. It has some unique features which do make it worthwhile. When looking through the docs I came across the scene loading and how it seems several scenes can be loaded, I didn't dig into to any great detail, but from what I remember it is possible to load a main level scene and and mini-game scenes in preparation as well. I'm open to correction about that as I'm not using the framework at the moment. Instead of going on about MVC blah blah, highlight these features because these will sell it. Unity is all about ease of use and everyone that posted on this thread did so because they were looking for a reason to buy, they weren't attacking the asset itself. Instead of going on about views etc draw attention to the practical features that will help developers. I've bought quite large assets because it had one thing I wanted and my attention was drawn to that one thing. I'm not going to pass comments about the asset itself and it's place in the Unity way of doing things as I don't see how that serves any purpose and I personally will get use out of it but you are doing a bad job selling what is in effect a very good framework. Possibly you should keep in mind that everything you write here reflects on your character and no-one else's. Telling fholm he possibly doesn't understand uFrame tells me nothing about him but does tell me a lot about you.

 

Huh? fholm said there was a lack of explanation as to what uFrame is good for and Micah replied with a rather large list of great reasons. Seems perfectly acceptable to me...

I have read through all posts in this thread. Regarding shaderop getting hurt feelings, what is wrong with the analogy? He is obviously a programmer, and had to explain to a non-programmer at one stage what programming is, seems like an analogy he could relate to.

Regarding the explanation of uFrame...
I personally think he has done an decent job. Watching his videos made me want to use it and could see the value in the product almost immediately. It is a rather complex topic, not something a lot of people will instantly grasp and not something easily demonstrated or explained. The main feature is it almost forces you to write clean, extensible code with clear separation of data, logic and display, creating a solid foundation to work from. This is a huge deal for any serious game. With the release of 1.0 with uBehaviours it will be even better.

 

I believe he was joking and referring to me as I had mentioned I would be buying the plugin a few posts back .

@gameboy - excellent naming suggestions, they help understand the different elements.

@micah I like the video series you have planned and looking forward to seeing it. I would suggest renaming a few words and using as many lay words as possible (as opposed to words like dependency injection). Also, one thing that would really help you reach a larger community of developers is to use analogies when creating the videos (For example when creating each step it would really help the viewer to see how that step differs from a normal workflow - so basically you would have the same scene when done normally (without using a particular framework) and then using your framework - I know this is extra work but it will really help you get the message across).

 

OHHHHHH!!!!! Oops well to correct it
@IAMSAM I'm REALLY sorry if I indeed offended you in any way. Braad hit the nail on the head with

in the sense that i was trying to relate to him; being programmers and all. But i definitely should be more careful as to how i come across with what i say because on a forum you can't see the emphasis or character on how i'm saying it. I can hear it in my head a certain way but it doesn't mean it will be read the same way.

I completely agree. "More of here's what most do now. But here's what it can be approach." Maybe even take some kind of example that out there and convert it into uFrame as an example.

This does indeed take a lot of time especially with working on uBehaviours and uFrame 1.0 out the door. But as soon as i get those out (should be in the next week or two) the series will be my #1 priority. I've been kind of waiting till uFrame has grown at least to 1.0 because theres alot of new stuff and i'd end up having to redo the series anyways. So hopefully it won't be too long before i can create the series and hopefully draw some people back into it.

Again thank you ALL for taking the time to help me out with you're thoughts and opinions it helps more than you guys know. I really haven't had much outsider input on it yet. And i think that's my own fault for waiting so long to get onto the Unity Forums. So if you think of anything else and have the time please keep it coming

 

I'm still trying to wrap my head around the pattern, but I was wondering if this plays well with a lot of dynamic code since I've had trouble finding an example that uses file data. We load most of the data for game objects via XML (e.g. enemies and their health, equipment, AI behavior, etc.) instead of using the inspector, and hook them up to prefabs by adding components.

 

I'm so sorry you thought I was referring to you. I assure you that that was not the case and I was referring to myself.

Though I would rather not comment as to whether I was joking or not

 

I would love to explain what's wrong with it to you, but I kind feel overwhelmed because it would be like trying to explain apathy to a psychopath.

 

If you haven't already follow us on twitter for the latest news.

https://twitter.com/invertstudios

 

I assume you mean empathy, not apathy.

With that assumption, I understand where you are coming from, but given the context it was obvious (to me anyway) he was trying convey the shortcomings in his ability to explain something, not an attack on your ability as a programmer.

The joys of communicating with text...

 

Alright guys. This one is for you @GameBoy !!!!
uFrame is becoming a very visually/editor integrated product.. Just a small preview of what is coming in 1.0.

There's a lot going on here but if you want to know more ask away

Here's a link to the attached image for a larger view.
http://forum.unity3d.com/attachment.php?attachmentid=94891&d=1396922421

 

Looking good, I really like the idea of the scaffolding.

I don't quite follow the idea behind the partial class, do you mean it gets generated as a partial then you remove the partial once it's complete?

Will you be able to load up more than one ViewModel up at a time, like a class diagram in VS? If so it might give my whiteboard a rest.

 

Thank you Unity for making uFrame a Staff Pick.

 

Yes it will be a complete ViewModel designer where you can have all of you're view models.

Partials allows you to have the same class in separate files. So if you wanted to add some of you're own stuff to the ViewModel you could add it another file while allowing the ViewModel designer to still be used and generate to that class without overriding anything.

Actually the idea is to use this throughout the entire process of developing a game. Not just for a one time scaffolding. Also It hides a lot of the syntax features that people might have a hard time understanding at first glance. But with a designer and something visual it makes things click easier. This will help when explaining it too. Developers have to know less about the inner workings of uFrame and more or less just how to use the tools. Unless the dev wanted to that is

 

Ah yep, that makes sense now.

One other thing, can you import existing ViewModels into the designer or will this only be for new ones?

 

Any thoughts on what I posted earlier? uFrame seems like a fantastic framework, but I want to make sure it can work smoothly with what I have in mind before seriously considering it. I can try rewording it if it sounds confusing. Thanks!

 

Hey nezabyte I apologize I must have missed your post somehow. Any way you could elaborate a little more on you're question I'm not fully sure what you mean by dynamic code. Or what exactly you are curious about.

 

Another great review Thanks Tim.

Improves workflow and cleans up code. (1 of 1 found this review helpful)
by Tim Bayer, 09 Apr 2014

 

@micahoz123: I've had to be away the past week and after looking at your update to uFrame, I'm liking what I am seeing. :O Are these changes available yet for uFrame customers?

But I think the process can be automated even further. For example, not everyone will understand that a partial class allows separation of machine-generated code from user-developed code for the same class. I'm all for hiding away as much implementation details to simplify game development; as long as good code is generated, and sufficient flexibility is possible, things should work out fine.

Maybe some kind of interactive template could be displayed, which would allow a user to
fill in names for the Element, and its behaviors (i.e. methods) and the parameters
to each behavior? Kind of like fill in the blanks, or utilize snap-together program blocks like plyGame or Stencyl (which are probably superior to connected graphs such as Playmaker, etc. as they tend to produce real spaghetti for complex procedures - unless they have some sort of automatic visual node layout display that can "untangle" the graphs).

I would have to play with uFrame to see how these changes affect game development work flow. I haven't bought uFrame yet, hence the question as to whether these latest developments are now part of uFrame if we buy from the Asset store.

One more thing: what happened to the new names for ViewModel, ViewController, and View? (e.g. ElementDefinition, ElementController, and ElementView respectively). You have the Jetbrains tools (and it looks like Visual Studio Ultimate as well with its cool Code Map feature). Refactor man! Refactor!

 

This is not a good idea considering it will break all existing user's code. I think the renaming is more of a UI thing.

 

uFrame 1.0 Coming Soon! Watch to learn more.

 

@Michael_invertgame: WOW!!!!!

I can't wait to try uFrame 1.0! It looks fantastic; $(S)old!

 

Thanks Gameboy!

Working night and day to try and get it out by the end of the month!

 

Outstanding! Excellent work, just purchased it!!! Anyone thinking about purchasing, just get it.

Wish you all the best with your efforts, you have created an amazing product here. Let me know if you need help with beta testing, will be glad to help with it since I am just about to turn one of my big projects into this framework.

 

Thank you so much!

 

Thanks a lot IAMSAM! We really excited and can not wait to get this out there.
Want to Beta Test?
If you are interested in beta testing send an email to invertgamestudios@gmail.com. We can't promise this to everyone though, we have a few already and could use only a couple more (maybe 3 or 4 at the most). To beta test send your invoice # (purchasers only), Skype Information, you're name, and potentially how you might beta test the product. Then we'll definitely consider you for beta testing. We like to keep an open relationship with all of our customers because ultimately their success will define our success. But we HAVE to speak with beta testers regularly preferably through Skype or Google hangouts. Since there isn't much documentation on the new stuff yet we'd have to walk you through it. So if you can't do that or don't have time just wait for the release.

Just as a note to anyone who has uFrame already.
We've really taken all of the comments and suggestions from the community to heart. So we've pretty much taken them and changed or added things to incorporate our vision as well as what the community wants. But we aren't leaving our current users in a rut either. It will be fairly straight forward ( while requiring some effort ). Honestly i think our current users won't mind at all considering what anyone would gain from the new release.

With that said 1.0 has some significant changes from the current released 0.9 versions (for the better). Nothing to major and we'll have a video tutorial on updating to the new version. But it's worth noting that at this point if you tried to use uFrame writing your own under the hood code for you're project you'd probably actually loose time rather than just waiting for 1.0. With the Visual Tools it literally does 90% of you're game for you. You guys will truly (I believe) be amazed when you get into the details of what it actually does for you. A 2 minute video really can't display all of the power in all of this. You'll be building games faster than you can come up with them. but we wanted something short to give people an idea of whats coming.

With 1.0 if you'll be able to just attach Element View Components to corresponding prefabs or game objects in you're scene and this will plug it right into the system. But i can certainly help give you some tips on converting you're project when the time comes.

 

We will be updating all weekend, if you haven't watched our latest video showing off whats coming in uFrame 1.0 please do.
This will be a free update with the purchased version of uFrame.

 

If you have any questions on how uFrame can help your game development email us.

 

http://i.imgur.com/4JH1wUy.png

Things are coming together quite nicely... Wrapping things up for release

 

I've sent an email to your gmail few days ago but haven't got reply yet.
Can you check your inbox?
I'm very interested in buying uFrame, just need to get something clear first.
Thanks

 

solakila we will get back with you as soon as possible, sorry for the delay. We are working at a feverish pace getting uFrame 1.0 ready for release and all the tutorials that go with it. Please accept my apologies and bare with us, thank you.