Oh, and following up: If you wanted to be really bad about it, you could change the source to be modular, say, based on a plugin system for texture streaming or lighting as an example, and then add the changes to the project. Then you could code proprietary plugins if you really wanted to protect your graphics coding. If you really cared.
However, software code doesn’t sell a game so much as art assets. No one goes, “Hey man I bought Doom 4 because it has id Tech 6!! I can’t wait to show my friends all this proprietary code!” No, what sells a game is the game experience and all the art and music behind it. Protecting your lighting or texture streaming code isn’t necessary unless you actually want to license that code to other people. If you simply want to make and sell games, then the software below the art assets means nothing other than how well it performs, and if you’re developing strictly games, then you shouldn’t really give a shit about that unless you also want to make money off your engine, like EPIC Games.
Aaaaaaand, I’ve gone way off topic here, lol.
@Mindmaster I still haven’t seen a reply about how well Unity performs compared to other engines. Is it good at doing things the other engines do, such as large open worlds or large non-linear levels? How well is the lighting performance, texture streaming, and so on? Of course this won’t mean too much for a fighter since you’re usually on a fixed plane, but I’m just curious about the over all performance as I’m getting interested in this topic again now that you’ve brought it up, lol.
I think you misunderstood me. I know that art assets attributed to a game using an OS engine are not licensed under the GPL, I even said that. And I know people can make money off of something licensed under GNU. I’m saying, they don’t actually own the rights to it, therefore someone else can take it and put it up for free, and any of the assets that are not under GNU, can be replaced. Therefore, building something on an OS engine is very risky.
You probably have a point about using plugins though. That sounds like a clever way around it.
GPL source code HAS to be available to the end user, and that end user has a right to modify it however he wants. HOWEVER, if he distributes anything he modifies, he HAS to make his source available as well.
There’s only a slight circumvention to this in forking, but any code retained from the fork is STILL under GPL license.
If you want to have a quasi-open source license that you can still profit off of, IIRC you should be looking at the BSD license.
Perfect example is the main user of GPL though: Linux.
Anybody can distribute a Linux distribution. However, ALL PROGRAMS and the kernel itself MUST have the source code available to the end user. HOWEVER, any optimizations and added functionality that the maintainers of the distribution make can be closed sourced and sold for a profit. So if, say, the SUSE dev team created a new package management/binary system that they didn’t want another distribution using, they could close that off and even sell their distribution with that killer app in tow. Even if it was built using GTK+, an open source GUI container, they can still close source their code, so long as GTK itself has its source available.
Of course, there’s other variables that distros use to make paywalls, such as tech support, but that is a possibility.
Of course, it doesn’t sit well with GNU itself, but how many people really take Richard Stallman seriously, anyway?
I actually would insist you do that research yourself, as anything related to that somehow would sound bias (mainly because UFE is a Unity tool) and would probably generate more questions with no proper value to the conversation =)
I think if we want to discuss Open vs. Closed Source vs. Monetization any further, we should just start a new thread dedicated to that, so that this thread isn’t completely derailed and this toolkit gets overshadowed.
I don’t quite understand this. If I build a game with an OS engine, then no one else has the rights to take the game I made and put it up for free with simple asset swaps. I own all the rights to the game. They can’t even just replace the art assets, because they’d have to do everything the same way I did in the engine. If I use an engine and make a side scroller, no one else gets to have access to the template I built to make that side scroller. They get access to the source code of the engine and they can try to do it their self, but they can’t take what I’ve built and slap shit on it and call it a day.
They can try to make a clone, and if I make a game they try to clone, I can’t stop that.
I actually wouldn’t mind a biased perspective, since you’re a happy user of Unity I want to know why you like it and how it performs in your eyes. I get the cross platform out of the box, but besides that, any other benefits, in your opinion?
Well as far as my work goes, the performance is great. I can’t really tell how well it does against other tools, but the reason I picked this tool, as a programmer, is its amazing asset store, vast compilation options and probably the most complete tool to make games to this date. I can’t exactly answer you on “how it performance in relation to other engines” cause honestly I never felt any difference, and as a programmer, its mostly my job to have a working prototype with good performance anyways.
Sorry guys its partially my fault for not giving much more information than just a few videos. As soon as I finish writing the documentation it should show you guys just how much depth there is to it. From block stun to frame advantage, the engine has it all, and its all very chewed down in easy to use visual menus. Check out the post from Unity forum I posted in this thread, read through it and you will see more screenshots and details.
That’s what I’m saying. And if you used an open source engine for a side scroller, any modifications you make to the engine are under GPL. I’m no lawyer, I can’t tell you what exceptions there might be to that, but that’s the basic principle of the GNU license.
Side scroller camera settings is just a set of coordinates you tell the camera to use. It has nothing to do with the source. If everything to make a game I want to do is possible in the source, then there is nothing no one can do to steal my work other than do the same work their self to clone what I do. I’m perfectly ok with that since nearly every game is in some form or another, a clone of something else. It’s how genres are born. If they do all the same work I do, then more power to them.
The same is true of proprietary engines. If I use Unity to make a side scroller, there is nothing stopping someone else from trying to do exactly what I did, down to the perspective and zoom and all that.
@Mistermind Great, that all sounds pretty fantastic and user friendly. I’m definitely going to have a look into Unity sometime in the near future. Especially if the asset store makes things even easier.
you don’t have to use spheres or boxes. why not polygons, so you always have the flexibility to make your hitboxes match your animations exactly.
and $200 for the version with source… ehhhhhhh. at least you get it early but the other versions seem very arbitrarily limited. What is “move link?” and camera move system, I believe that would be dynamic camera motions for ultras and stuff? would you need source version if you wanted to implement just defend and pushblock instead of parry?
Spheres, boxes, they are just visual cues. The real code uses Pythagoras theorems to detect collision. Like d3v said, its just a way to visualize and edit your data. You shouldn’t really worry about that =)
Pushblock and parry will be a part of the Pro version, which is $149. The $199 version is a full source file so you can literally change anything you want.
Move link (or move chain) is the ability to cancel a move into another move. Basically the “animation cancel” system. Things like “c. LP cancel into DP” can be done by adjusting the frame link of c.LP to the proper configurations and listing Dragon Punch as one of the possible linkable moves. There are several names for this, and each website and narrator calls it differently. I opted for “link”, but if you guys prefer another name I can change it.
Camera Move system has recently changed to “Cinematic” and you are right, its the camera motion for ultras “and stuff” =D
The source version has the exact same features as the Pro version. The only difference is that the code is completely open, meaning unlimited customization.
Sorry for the high price for these features. A fighting game engine doesn’t sell as well as an FPS or RPG engine, so I must account for the time spent developing and its lower demand.
If demand increases, I’ll definitely reconsider these prices.
you think of them in boxes because they have always been done in boxes, even if that is not the best way to do things. which it isn’t
sounds like a cancel.
if you go from normal punches into stronger punches or kicks those are called chains. so c.lp c.mp s.fp with the move recoveries all removed, so it just goes startup frames -> active frames, startup frames -> active frames, startup frames -> active frames.
what you described, with c.lp -> dragon punch going from startup frames -> active frames of c.lp then startup -> active of a special move is a cancel
being able to separate hitboxes from your animations can be useful for balance reasons too. could you give a visual example of how a hitbox is derived from the spheres? I see your editor and how the spheres look but you suggest these spheres would be connected together by your code, how does that work?
Because at the end of the day, they “feel” right for a 2D fighting game. Remember that SFIV’s alpha builds didnt’ use traditional hitboxes and many playtesters said that the game felt off. It was only when they switched to traditional 2d hitboxes that the game suddenly “clicked” in many players heads.
How are you dealing with Unity’s Input class updates being tied to the frame rate? I just spent a week prototyping a port of my engine in Unity and found a solution using 3rd party libraries, but you lose portability.
In UFE they can be considered the same. Here is a screenshot:
In Required Moves you can select which move has to have happened in order for this new move to be triggered
In Move Links you set which moves can be “canceled into”, and rather or not it is on hit.
A “one frame link” move can be adjusted by setting your frame link just one frame after the active frame ends for example.
Say you want to code an FADC. You can create a special focus move that consumes 2 meters and tell any move that can be FADC canceled to be linkable into the focus move during the active frames and only on hit.
Then in this special Focus you say that it can be canceled, from frame 1 to last frame, into another move: Dash.
Just for the sake of it, here is a screenshot of the active frames options:
The hitboxes ARE connected to the animations =) The physics and hitboxes work in a 2D perspective, while the animations run in a 3D environment.
I want to know why you like it and how it performs in your eyes. I get the cross platform out of the box, but besides that, any other benefits, in your opinion?
