No announcement yet.

UDK K2 or (Kismet Squared (2))

  • Filter
  • Time
  • Show
Clear All
new posts

    UDK K2 or (Kismet Squared (2))

    Im not sure if this is total BS, or its actually true. I remember reading somewhere that Epic Games is working on a easier unreal scripting interface alot like kismet called Kismet 2 and it will be basically visual coding like kismet except its not like regular kismet, where its level based. This can code gameplay and etc.

    NOW, im not sure if this is even true i just remember hearing about it. However, for those that love Art and suck at coding abstractly what are your takes on this? I'd like an educated discussion please on this topic.

    I myself think this would be amazing but i also read traditional coding will obviously still be there. Again im not sure if this is true and i read it a month back, i just remembered it right now!

    So what are you ideas? Does this seem like a good thing for Indie devs that dont know much about coding? Will this lessen the need for traditional coders? (Im doubtful it will lessen the need)


    A Kismet-like interface will never replace proper coding/scripting. They might allow for more to be controlled via Kismet, but code will always be the better option for performance, etc.


      It's a bad idea. Why?
      -It will be very inefficient. Processing code from schemes is pretty hard on the CPU.
      -It will be very buggy. Kismet is reliable (enough) for single-player scripted sequence, but not for much more.
      -The potential for customization will decrease by a great deal. Either that, or the interface will be a horrible mess - dealing with a variables, deriving classes, etc. will be insanely unpleasant.
      -If you can develop complex schemes in a Kismet-like interface (and you'd have to), you might as well code it, with far less mental effort and less bugs.
      -It's just wrong. Think of all the coders! What would happen if there was no need for them anymore?


        Originally posted by waitwhat View Post
        . Think of all the coders! What would happen if there was no need for them anymore?
        Thats exactly what i was thinking, maybe kismet 2 will just give more freedom, or choices bu i do agree that coding should always remain traditional. Node based systems indeed are slower.


          A Kismet-like interface will never replace proper coding/scripting.
          Why do you say that? Is there any real argument for this?
          If everything doable in kismet can also be done in unrealscript, why everything doable in unrealscript couldn't be done in a kismet-like interface?
          I know there are limitations for what can actually be done in kismet but you would be right if you could demonstrate that certain things doable in unrealscript could technically never be done in anyway with a visual scripting system.
          Do you have such an example?
          It seems to me that coders don't like kismet scripting style because they think it is not "real" coding eg. boring and frustrating efforts. I don't agree with this: if you want to conceive custom kismet nodes, this is real coding. And if you want to set up a network of nodes, this is real coding too. It needs logical approach, etc... Maybe you could say it is only another global approach of coding: "coding by nodes" of something like that...
          Don't you think so?


            Everything is doable in Kismet? Who told you that?

            I really quickly encountered limitations in Kismet with stuff I wanted to do. Then I went to traditional coding and coded the Kismet stuff that lacked so that our level designers were happy, because that's just what coders do: they get a request by people who have no idea of coding and do the work to match the expectations and specifications in the preferably most efficient way available with an interface that is easy to understand by the non-coding customer.

            Coders have to do all the behind-the-scenes work, otherwise Kismet wouldn't even work the way it does. Kismet was coded with UnrealScript and C++, so how can you expect it to replace the thing it was created with and that in an equal fast manner?

            Not even talking about the workflow. It already takes weeks to write a proper complex gametype, in my case 1700 lines just for the GameInfo class. I don't even want to guess how long that would take if I had to drag some nodes around and to click through menus in order to perform the action that I want to achieve.. several months, I'd guess.

            There are references to something that could be "Kismet 2" in code, namely K2Call and similar modifiers, but other things in code point to the direction that this will be only a visual scripting interface for AI, so it's still somewhat level based I guess.


              Found this on unreal wiki, its still unannounced and also not sure if its accurate.

              "Kismet 2[confirm] or K2 is a visual programming feature. K2 is not confirmed by Epic Games yet and is therefor pure speculation from the community. K2 first popped up in the recent UDK builds starting with the K2 modifiers such as K2Call found in various classes. There are as well many new classes with the K2 prefix that are very suspect to be related to a new upcoming visual programming feature for the UDK.

              By looking at the classes it's clear that this is designed for a visual programming feature for UDK, they can be found in UDK-2010-07 and UDK-2010-08 in the Engine folder of Development\Source. Some of these classes are named K2Node_Code, K2Node_ForLoop, K2Node_Func and K2Node_IfElse."


                I've seen references to k2 in the unreal script source and figured they were working on improving kismet.

                as for the coding, coding is a concept not the action of writing something into a text file. you are still coding with kismet. its just a diferent architecture. one less flexible then a more "traditional" language. the material editor copy pastes pieces of code into a text file and forwards it to the compiler to take care of the heavy stuff, those are the nodes you see in it, premade constructs. kismet is doing something similar. code is highly redundant, so that system works. how many times have you written if(bla)? coding is not about the writting but more about the sorting of "constructs"(concepts) to achive a given task. knowing a large amount of concepts takes a while, knowing how to upload it to the computer also takes a while as well. kismet is a facility to upload code and be able to visualise it as you contruct it; its a graph. remember, before text files, programmer had to upload the program by hand, no visualisation, just literaly ticking a computer with the right rhythm. graphs are a little dificult to maintain so they have not gained much popularity in mainstream programming, but graph generators that create a graph after you code the program to visualise it do exist and are quite useful at times.

                as for graph based being wrost than "traditional". a compiler first builds a graph from the text file to translate it into machine code. coding directly into a graph will remove one step :P. I however, find it too hard for complex programs due to the mouse interface, perhaps if the keyboard was used and the nodes had a clearar order and took less space.

                To create a high level programming language such as c++ or even assembly, you need a compiler. but you need a compiler for the compiler. you can look that up in google("compiler for the compiler") to understand how this proccess works.

                Edit: well shoot, it turn out the wikipedia is as narrow as always with its focus. so uhm.. a compiler is a very complex program, as complex if not more than something like a game engine and is needed for something a simple as a "hello world" program that runs on top of an OS that runs on top of the computer architecture language that... well. nowdays c++ is considered fairly low level, this is because we keep building on top of something.


                  I'd honestly would like a more visual way to construct Unreal Script project that is more akin to Kismet. I'm more of a artistic minded guy and Kismet while a great leap forward for me, still seems pretty limited where i need more control of the game then kismet provides.

                  If Kismet 2 is Unreal Script and Kismet rolled into one complete package, I would jump on that like a fat kid on cake. Wait! I'm fat and now I want cake. If Unreal Script not but gain more control over how the game functions, I'll still jump on this like a fat kid on a cupcake.

                  Anyways, I think that coder purist are a bit narrow minded in assuming that everyone should code like they do. If you want to code in a purely text environment, feel free. but if the same job can be done in a kismet like Visual Node sort of method, who is to say that is somehow wrong or bad.

                  Coders will never be at a loss for usefulness, however what about the artist that want to cross over slowly into the Coding field of things and want to start in a way more comfortable to them?


                    a while ago, I started coding kismet nodes because unlike unrealscript, kismet can be changed without closing the editor. I creating nodes to move what I had in unrealscript into kismet. kismet originally only has "level design" related nodes with some simple constructs like for loops and the like that was too limited for what I wanted. I never thought anyone will find something like that useful so I haven't worked much on it.


                      IM sure lots of people would find it very useful, i definitely would, since im very visually oriented.


                        I would like that. I'm sure it can't do everything, but it would be nice to have something that artists could use for more simple things.

                        Kismet is already sort of like that, used to be stuff like events would have to be done with coding

                        And they have a similar system in Cryengine 2 with Flowgraphs


                          it would be a nice addition having something like this.
                          there are a few programs that have that kind of interface and it works well.
                          take native instruments reaktor for example, there was even a guy who simulated a nural network with it.
                          if its done well it wont be limited at all.


                            No... It'll have to be limited. That, or it'll be just as hard to learn as Uscript.

                            Here's why:
                            Here's the Uscript class hierarchy (Top level)
                            If you scroll down, you'll see a list of variables and enums and links to the functions, struts, and operators in that top level.

                            All of those variables would need to be in a dropdown list or something so that you could use them. If you click of the functions link, you'll get a big list of functions. These would need to be nodes that only showed up if you were scripting in that leg of classes.
                            Now, follow one of the links to a child class. Say, actor. You'll get the whole thing over again. You'd need nodes for every function and those variables added to a drop down list that only showed up when you were making a K2 script that was based lower than actor in that class hierarchy. By the time you were done, your list of nodes and variables would be very very large. Now, you need ways to work with all of these nodes (Functions). They take variables. You have a big list of pre-defined variables, and the kismet style stuff to call an object and things. Great. What happens when I need a switch, or a multi-tiered loop that cycles through a bunch of variables checking for a specific variable to be true, and then checking variables related to that variable, etc until it finds the exact match that I need and uses that as the variable in my node. That variable would then need a name so that it would appear in my variable list for valid variables while I'm coding in that class and depend upon all of the loop nodes. The loop nodes could be comparing any number of items or entire arrays of variables/objects... I don't even want to think about how confusing this would get trying to set up a halfway decent script with nodes.

                            A system could help level designers to do more and streamline stuff. But, when the level designers need anything complex, I doubt there'll be a picture version with strings that'll get it done any more than they could make a node based modeling system that models whatever a coder wants with nodes. There's just too much for that type of system.

                            Kismet is created in Uscript. Kismet will never be able to create itself. It just doesn't work that way. DLL Bind via node... <Twitch>


                              Everything is doable in Kismet? Who told you that?
                              I never wrote this.
                              I said that kismet has limitations because it was conceived with these limitations and I wondered what could be the definitive limitations of a visual scripting system.
                              I mean: what couldn't absolutely be done by visual scripting?

                              In fact, maybe the main reason why so much people want to code in kismet is the lack of complete, satisfying and progressive lessons and tutorials about unrealscript. Otherwise, I can't understand so much people (myself first) are asking so basic questions on these forums. If there were a possibility to get a real training - not just a "Read actor.uc!"), it would be cool.
                              At least, with Kismet, it's quite clear. Using nodes is not difficult. They are self-explanatory.