I’m In – Since 2009 – New API

Posted by
August 15th, 2015 5:49 pm

Goodbye Retro Flow API

Love Bomber - The Cult Simulator Click here to play.

Click here to play.

Click here to player & rate. KEYBOARD + MOUSE W,A,S,D - Move Click - Use Tool Mouse Scroll - Change Tool

Click here to play.

Tiny Civilization with colour

Click here to play.

 

 

 

 

 

 

 

I developed Retro Flow API in AS3 in 2009 specifically for Ludum Dare.  Once Flash was officially depricated it was time to move on.

Hello Super Flow SDK

The past few weeks I’ve been developing a fresh new Javascript Software Development Kit tentatively named “Super Flow”.

I figured it was time to make my “Dream API” for Game Jams and Ludum Dare, something that had a few specific requirements:

  • Convenient programming.
  • Deployable to the web without plugins
  • One programming language for everything.

I came up with a concept I call directives-based programming.

In practice it’s a modular server/client API.  In reality it’s a bit of a paradigm shift in the way you write multi-runtime software.

Directives may or may not be a new concept, I do not know but they will definitely require a tutorial for me to adequately demonstrate their power.  I feel that once you understand the concept its power will be very evident.

Technically speaking directives allow you to define data and entry points for multi-runtime software in any execution order without repeating code using one language.

Why that’s useful comes down to convenience.  It’s an extremely convenient way to write complicated software for the web such as web games.

// in one file...
_.server()
_.remote("do_something",function(arg1,arg2){
trace("a client called this function with arg1 =" + arg1 + " and arg2 = " + arg2 )
})

_.client()
_.ready(function(){
send("do_something", 0, 0 )
})

This doesn’t give it justice at all.   Like I say, some tutorials will clear up how powerful this concept really is in the near future.

Super Flow Prototype 3

Althought I’m developing a complete SDK (software development kit),  complete a powerful IDE (integrated development environment),  I’ll be using Super Flow Prototype 3 this Ludum Dare.

This was the first solid prototype that really took advantage of directives.  It resembles very closely the final design of the API.

Click here (25.2 kb ZIP) – download Super Flow Prototype 3 w/ Net Tank Source Code.

Requires NodeJS,

type “node sf.js server” to run.

Browse to http://localhost:8080 to play the game.

Docs

Sorry, there are no docs yet.

 


10 Responses to “I’m In – Since 2009 – New API”

  1. g_o says:

    I’m sorry I don’t quiet understand what you did there – like what is the server client architecture here?
    Oh btw I also used “_” object to make my own jQuery thingy once haha

    • Suese says:

      Thanks for taking a few minutes to look at it.

      It’s a bit of a difficult to explain what a directive is…. It doesn’t actually matter what the architecture is as long as some mod implements it.

      In the ZIP file above there is a mods called “web_server.js” and another called “web_socket.js”. With those mods your program runs in the browser at http://localhost:8080/ by default.

      It implements _.remote() calls which let you communicate between the server and client.
      The hardest thing to understand at first is the server and client can exist in the same file.

      • g_o says:

        You still don’t get me – It’s not that I dug the code and didn’t understand an implementation – I don’t understand the concept and what does client-server architecture has to do with this?

        • Suese says:

          In short you can write a client-server program in one file in pure Javascript.

          The above code demonstrates a server with a function exposed to the client. The main advantage is that you don’t have to switch between a bunch of languages or re-implement code in different locations.

          _.client() will target only the client
          _.server() will target only the server
          _.both() will implement something the same on both the server and client
          _.target() lets you choose a custom set of targets in more complicated scenarios.

          The other important directives are
          _.class() defines a class or a modifcation to a class
          _.static() defines a static system or a modifcation to a static system
          _.event() defines an event handler
          _.require() defines that another mod is required before implementing the current module.

          Most of the directives are just shortcuts to _.event() or _.target()

          I understand it sounds really technical and doesn’t exactly explain the purpose very well. When I release the SDK I will release some tutorials, at that point directives will make a lot more sense. They aren’t a complicated, they are actually extremely convenient.

          I hope that explains it a little better.

          • Suese says:

            When you see directives, don’t think “Execute these in order”

            Think “Here is a catalog of data and entry points the program needs to implement”

            So for example…

            _.server()
            _.init(function(){
            trace(“first thing”)
            })
            _.remote(“remote_control”,function(client,arg1){
            trace(“some remote function call”)
            })

            Don’t think of this as running two functions. Think of this as a catalog with two events.

            Rather than simply running that code in order it catalogs these two directives on the server only and when all directives from every mod have been cataloged, THEN the execution environment is assembled in dependency order, the the program is started.

            Another way to think of it is like an app/game made of nothing but plugins.

            • g_o says:

              I’m so grateful for your elaboration. I do get that you use something counter-intuitive here, though my question is more simple – I need you to talk qualitivly and conceptually: what is that you are trying to achieve? Is it some sort of blocking functions? Organized multithread? I don’t get that I honestly don’t get the point in it.
              To make it easier, here are some questions worth answering imho:
              1. Are those plugins essential?
              2. How are you going to use this for you advantage in game programming?
              3. Will making this sort of architecture really help anything?
              4. Are those “directives” essential, if so what is their advantage?

              Those are the kind of questions that when making a project you should know the answer to, in my opinion. You are very vague about things so I can’t tell if this is good or just and idea yet to be finished or useful.

              • g_o says:

                Sorry for making it hard for you but as far as I can tell this can do nothing but some sort of messaging and event system between two objects. I don’t see the connection to game developing.

              • Suese says:

                Definitely.

                Convenience is the objective. That’s the answer to all the hard questions.

                Other main questions you are probably asking:

                What is it?

                A dream platform for developing games quickly for game jams. Something that takes care of all boilerplate needs.

                Why?

                Faster programming. Working in PHP + Javascript to make web games was a drag, and designing modules that can be self-contained with multi-language multi-environment mutli-runtime systems like this was nothing but a headache with code often needing to be repeated in two or more languages.

                With Super Flow API all boilerplate features are taken care of through self-contained mods that “just work” when added to a project.

                Yes this software is working today, I will be using it for LD33.

                How it does that?

                It comes with a butt-load of mods that take care of a ton of boilerplate features.

                Who am I?

                I have 20 years of game design and middle-ware design experience. Check out my game jam games and some of my past work experience at http://danmckinnon.net/

                To answer your direct questions, let me just clarify…

                I think you are confused by the term multi-runtime.

                A server is a runtime
                A client is a runtime
                There are also other runtimes such as build, package, publish, etc.

                Most of the time people are using multiple programming langauges and multiple environments to program their server/client web games. So in my case it was PHP + AS3 + Javascript, or ASP + Javascript, or even C++ + Javascript + Make + SH + etc.

                With Super Flow one can program everything in one file, one language, which is convenient.

                So onto your questions.

                1. Are those plugins essential?
                R: No mod is essential. Super Flow downloads required mods automatically.

                After cataloging, Super Flow checks for mods your software requires in your mods folder and if it’s not there, it checks the web repository and asks the user to download requires mods if necessary.

                2. How are you going to use this for you advantage in game programming?
                R: Adding common features for large and small systems is drag/drop easy without adding unwanted bloaty features. Add a mod, get its features, that simple. That’s CONVENIENT.

                There are already over 25 mods that add features such as utility functions, auto-loader, game canvas, tile drawing, tiled support, lighting fx, chat system, broadcasting tools, web server, web socket. Some mods add features seamlessly like “Auto-reconnect” is handy for developers who want to stop and start the server and client a lot for testing. Literally no extra coding is requires to activate its functionality.

                How that differs from systems that already exist is that other systems are not multi-runtime. For example if you tried to use a C++ library to implement a multi-user chat server for the web you’d be using C++ and Javascript, and the chances that the system will “just work out of the box” are slim to none.

                Super Flow eliminates those problems. The key is that mods define multi-runtime functionality as opposed to single-runtime functionality like most people are used to.

                3. Will making this sort of architecture really help anything?
                R:First, it’s already been done, I will be using Super Flow for LD #33. I’m a very fast and industrious programmer. Second, Yes, definitely. It speeds up development time on small and large projects immensely. Adding boilerplate features, even extremely complex multi-runtime boilerplate features such as game lobbies or distributed simulations extremely easy and convenient.

                4. Directives make dividing multi-runtime functionality into modular components easy, which is extremely convenient. That is their advantage.

                Without directives I wouldn’t be able to make something like a lag-compensating distributed game simulation a feature that can just be drag/drop added to a project so simply.

                Thanks for your inquiry.

  2. g_o says:

    Hmm OK I’m gonna read between the lines and hope I’m correct – are you planning to make a multiplayer game?
    I honestly don’t understand your statements – you call this an API and then you talk about an SDK and then you tell me it’s bunch of mods and then you talk about multi-runtime. I feel like the entire thing is scattered.
    Well, as far as I know there are already lots of plugins that allow php and javascript merge pretty well in one place.
    Really appreciate your response but you see, I could really care less about the prettiness of runtime-functionality made into modular components. Let PHP do what PHP does best. I don’t like forcing languages out of their natures, let each language do what it does best or you’re just making it pointless. Why not use a single-agreed upon language to everything? Because that’s a terrible idea. I do appreciate stuff like Node.js and all sorts of plugins but I guess I’m just not into the kind of stuff of twisting it too much, by the end of the day this means more vulnerability in the web. I prefer letting browsers leave HTML4 and go into the new era safely and slowly. So I guess this stuff isn’t my thing .. but I’m sure this is a cool thing I do like drag & drop features like everybody else =]
    As for its usefulness – well, I mostly see potential in client-server based games which is most of the time multiplayer / shared worlds or stats.
    All of the canvas and the boilerplate parts I guess are cool but I don’t get how they are dependent on this thing?
    Couldn’t you just program it into some native JS module or something?

    • Suese says:

      I’m making an SDK which is a software development kit. The SDK include an API which is an application programming interface. The SDK also include an IDE which is an integrated development environment.

      The purpose is convenience.

      The reason convenience is important is because it helps make games for game jams faster.

      No other JS module system allows you to define multi-run time functionality in self-contained modules.

      Again, the purpose is pure convenience. One language, no repetition of code.

      If that’s “scattered” then so-be-it. I guess that’s your definition of scattered. I’m obvs a complete n3wb that hasn’t thought any of this stuff out :p

      Honestly though, I think the under-the-hood stuff I mentioned might be confusing youu. I was just making an interesting “I’m in post” that showcases my past work and some news about the transition from my old API/Boilerplate to the new stuff.

      Everyone builds a boiler-plate now don’t they? Mine just happens to be quite advanced.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]