nav2

Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Saturday, October 20, 2018

Adding a sound effects editor/generator to Gdevelop

I've been a fan of Gdevelop since before even knowing any programming languages. There is something wonderful about the design of the editor and especially the event sheet- which allows non-programmers to quickly create their own game prototypes.

Because of that, you can see now that ever since I acquired some programming experience, I have been contributing to it's editor at github. After doing some work to integrate Piskel - this allowed pixel art creation/authoring straight in the game editor. This is something I've wanted to have in it for a long time, but never imagined I would add to the editor myself.
In this last week I made another commit- that adds a sound effects editor to Gdevelop - straight inside the IDE. 
My goal with this is to make Gdevelop a stronger tool for rapid prototyping and game jam events - put it in the hands of artists in the team. Something as trivial as finding good basic sound effects and putting them inside your game might take 30 minutes or more - with this addition there will be no need to search for it, download,import and so on. You can even tweak the effects.

The library I initially chose was https://github.com/loov/jsfxhttps://github.com/4ian/GDevelop/pull/695
After using it for a longer period and some further research and feedback, I decided to replace it with

Jfxr: https://github.com/ttencate/jfxr   https://github.com/4ian/GDevelop/pull/716

This is how it looks like now:
While being at it, I made the external editor embedding code more reusable and solid- something that should help for adding other editors to gdevelop in the future.

The idea for this came from remembering being on a gamejam- where we had 1 artist (me), one musician, one generalist and 2 programmers. My friend- the musician spent time on the music, but had to stop working on it on the second day- in order to look for basic sound effects. He lost some time also setting the software for making music (renoise). I thought- if we knew about this generator back then- it would have given him more time for the game music. A lot of games at that event didn't have good basic sound effects because they ran out of time, but those that did- the sound effects made a big difference on their play 'feeling'.

The event sheet in Gdevelop encourages artists without programming knowledge to try to make games, the pixelart and music editors should invite them to use Gdevelop even more. The IDE will give them a complete and very intuitive dev environment that is both effective and fun to use - like a fantasy console,but without limitations.

All of this of course would never be  possible without the incredible work done by Gdevelop, jsfx, jfxr and piskel's creators. My role in this was only in making them work seamlessly under one IDE- together and deliver a good user experience.

Friday, July 13, 2018

Porting Yarn to Electron and adding some cool features to it

Yarn is a tiny wonderful open source editor for non linear dialogue in games. It is written in html5 and exports the data in json file format- to be used with another library called 'Yarn spinner' in Untity3d games. Alternatively it can be used in html5 games with another dialogue file interpret library called 'bondage.js'. Yarn has had a stale development over the last two years- with a handful updates from it's community. More of the updates seem to have gone to yarn spinner. What attracted me initially to it is a kickstarter game that I backed a couple of years ago- called 'Night in the Woods'. Yarn and Yarn spinner were used to create it. Yarn itself is very sleek and user friendly- really clean interface, but it lacks some usability features that make it a little harder for new users to learn.
After looking at it's source code I decided that I want to try and incorporate it inside gdevelop - in the same way I embedded piskel earlier this year. It would really empower gdevelop 5's newIde for easy creation of story based games - rpg games, adventure games, visual novels- all that jazz. Gdevelop5 in that case would actually have an advantage over unity3d- as yarn itself and the library to parse yarn story files (bondage.js) can be integrated with the gdevelop5 and work out of the box in a very user friendly way.

In order for that to happen however, Yarn needs to be updated to use electron and get some usability improvements. This time I had to actually change the software I am embedding myself! Luckily it's source code was fairly easy to understand and nicely structured enough for me to dig in. It took me only a couple of hours to port it to electron. The main parts that needed porting were really file i/o and the way some libraries are used. The port to electron also fixed some old issues- such as the inability to have two instances of yarn open.

I really wanted the official yarn git to approve my port and make it the main development branch, so I submitted my port to them. The maintainer approved it but is for now keeping it a separate branch
and here is my Pull Request:

I also took the time to add a number of features that were requested before and I thought would really make it much more user friendly!

  • Ability to easily create links to other existing nodes via a new helper menu:(addressing #34)

  • Ability to test dialogue via e new "Run" menu (using bondage.js and with support to render bbcode)(addressing #29)

  • file drag and drop (including support for dropping multiple files)(addressing #32)

  • Automatically create New Nodes from [[new]] and [[new|choice]] - if no nodes exist for them (addressing #27)

  • Ability to run more than one instance of Yarn (addressing #59 )
  • Lots of fixes and new key bindings 
Since my pull request was approved, its electron port has seen fixes from a few other users- this makes me feel confident about the future of Yarn.
For that reason the next stage for me now is to look into integrating it into gdevelop 5. That begins with writing an extension for gdevelop that exposes the functionality on bondage.js to the event sheet. From there on putting yarn itself in gdevelop would be very easy. I already have that sorted for another personal project that is using electron.

In any case, if I succeed in getting these two to work as one and get it merged into gdevelop5, expect to see another post with a demo example game and a tutorial on how to use gdevelop to create non linear dialogue type interactions in your html5 games. :)

Wednesday, May 23, 2018

Getting two open source projects to work as one - Gdevelop + Piskel = Awesome!!!

In recent months I have been highly interested in javascript for a number of different reasons.
First of all my current day to day job requires a lot of repetitive data entry and data checking activity. I quickly found out that alot of it can easily be automated by writing different web crawler functions.

This is when I first started to reverse engineer websites in order to teach my macros how to extract information from them that it would then use to decide on how to proceed with it's data entry process. Web browsers are awesome in terms of their debuggers- in a way that many game engines arent. They let you dig through a web page, see how all elements are organized in it and how to programmatically instruct your web browser to click on buttons and fetch data. This is the definition of a web crawler.

This newly acquired experience motivated me to start digging more into javascript- as it is the scripting language of the web. Coming from a python background, going through web courses from scratch kind of felt like a boring route. So instead I went ahead and started playing with different game engines - such as Three.js and Phaser- both awesome engines btw.

Finally when I found out that Gdevelop's new IDE is written in javascript-  that made me excited- because for the first time I had an opportunity to change how it works.

To give you some background - before knowing any programming languages at all - I used to be 100% invested in engines like construct2 and clickteam fusion. But those two lacked something very near and dear to me- they weren't open source, thus not really owned by their  community of users. At that time I found Gdevelop- a great event sheet based programming engine that had almost everything I wanted. But its editor frustrated me when compared to  the other two- with a lot of small quirks and one big one - it wouldn't allow the user to author any pixel art. You would have to have pixel art prepared in advance to start prototyping anything. And prototyping is not as fun and personal imo if you are not moving your own stick man :)

This bugged me for years. Gdevelop being awesome, but not having a pixel editor like clickteam fusion and construct2. So fast forward to several years later - I suddenly have the real opportunity to change that! Gdevelop is open source, its editor is in javascript- which I have some experience with. There are multiple html5 based pixel editors that are also open source! Holly crap! Piskel is awesome - and its a perfect match. Can we do this? Can we?

Hell yeah we can! :P
https://github.com/4ian/GD/pull/493

Granted I am not as experienced as @4ian, the main developer of Gdevelop - he did do some refactoring on the code and helped me along the way. So did Piskel's author (the async function especially) - but what I made a pull request with was a fully functional prototype of the two applications working as one:

To do it I had to learn a bit on how both of them work!

So how does this implementation do it and why is javascript so awesome? Basically both Piskel and Gdevelop are html5 based apps. While Gdevelop was already running inside electron, I had to make piskel also run with it. That was simple enough- just create another electron window instance that will load and house piskel. In the process I learned a lot about electron's api - how to initiate, control and send signals between window instances. I had to tell gdevelop to send to piskel a list of paths where the image sequence pictures are.
Gdevelop is sending that signal to my own intermediate index file that contains the instructions of how the two should communicate. Inside it I had to load the image sequences from the paths and turn them into base64 strings. Didn't even know about base64 strings before this :)
Then finally parse that to the embedded electron window. And voala- loads them up!

But we have to keep track of the files- which frames come from gdevelop and which were made in Piskel? For that part I was just amazed at the fact that I could just attach new variables to piskel objects through my intermediate index file. Without touching piskel's source code I attached the imported image paths as a new variable to every frame object. I also hid piskel's  'New file' button and in it's place injected two new custom buttons. The main one - to save back to gdevelop overwrites any frames with original paths and create new paths for frames that were made inside piskel. When complete- it sends a list of paths back to gdevelop to load, where gdevelop reloads the list of sprites.

With all that done, Gdevelop now has pixel editing capabilities - which are actually more advanced than what you would find in construct2 and construct3 for example. Piskel has some very powerful pixel art tools!
Much thanks to both Florian Rival (Gdevelop developer) and  Julian Descottes (Piskel developer) For the patience and support along the way.

After  getting it merged, I also added:
https://github.com/4ian/GD/pull/522  and https://github.com/4ian/GD/pull/543


Piskel is now a part of Gdevelop!
If you want to play with it, please go ahead and grab a copy of the latest release:
https://github.com/4ian/GD/releases

It's free, fun and even if you aren't a programmer you can use it to create your own games and in the process learn a bit about programming  =)

Apart of  the addition of pixel editing, the newIde has an impressive number of new features almost every week and is being rapidly developed at the moment. You feedback and support will be appreciated!

Sunday, January 28, 2018

Metasnap - a screenshot+note+palette app written in AHK


This was a little pet project that took a couple of weeks to implement in my free time. I wrote it in the autohotkey scripting language with the goal of pushing its gui capabilities.

I needed some sort a screenshot app that remembers the area I want to take a snap of and lets me leave notes in the metadata of the actual image files. While developing it I realized that I can encode other types of data inside the image files, such as color codes - so the tool mutated into a color palette editor and basic note taker on top of a screenshot app.

Before it was called "Metasnap" - I named it snapgrab. In any case, if you have cool ideas of data that can be encoded into screenshots,please let me know:)

You can download a copy from bellow:

Features:
- Take screenshots of the entire screen or a set area. The tool remembers the area between sccreenshots
- Pick colors and store them inside the screenshots you took. Picked colors are stored as both rgb and html color codes that can be easily copied to clipboard. Ideal for web developers and artists. The color palette is stored as metadata inside the screenshot file
- Leave notes about screenshots you took - inside the screenshot files metadata
- Tiny image selector with support for bookmarks


Thursday, January 25, 2018

Godot 2.1 - 1$ gesture recognition plugin

Some time ago I encountered a little charming google doodle game that uses the player's scribbles for input:


You can play it here:
http://www.google.com/doodles/halloween-2016

That mechanic inspired me so much that I decided to try and implement it in Godot. Luckily I didnt have to start from scratch. The basic 1$ algorithm was ported to gdscript, but its bare bones implementation was not ready for gamedev. It was only a function that can be crashed. I added some commits to it. Fixed some game crashing bugs in common corner cases and added a bunch of cool features.

After porting it into a plugin, I added the ability to teach it new gestures and record them in a json file.
Added some extra optional features:
 The developer can set limited ink - to limit the size of shapes that can be drawn Upon recognizing a shape, it also emits a signal of what shape it is and how much ink was left when it was completed If the ink left is > 0, it will create a collision shape from the drawing, that can be used to interact with other parts of the game You can limit how many collision shapes can be drawn optionally.
Optional particle effect and ability to set line thickness and color Ability to set the allowed drawing area and change the mouse cursor to a pencil then it is over it

Here is a demo video:

It can recognize the following shapes out of the box (in the json file):
  • carret
  • v
  • pigtail
  • lineH
  • lineV
  • heart
  • circle
If you like the plugin, feel free to get a copy from itch.io (maybe even leave a tip in the jar ;) ):
https://blurymind.itch.io/1-gesture-recognition-addon-for-godot

Github page here:https://github.com/blurymind/1dollar_gesture_recogniser/tree/master/addons/1dollar

If there is enough interest in it, I will port it over to Godot 3..
Might make a little game with it when I get the time :)

Wednesday, March 16, 2016

Construct2 and Fusion 2.5 review, Learning Python and applying it to Gdscript (Godot)

I recently started learning Python. A lot of people say that it is a good first language to learn. The truth is that in the past I have used visual programming tools such as Clickteam Fusion and Construct 2. You still do programming in them - you execute functions, deal with gotchas that come from programming, write expressions and learn some syntax. But they aid you along the way - offering an easily accessible list of conditions and actions you can use. Behaviours and types of objects you can attach - each brining ready functions to use in your game. All paired with a nice level editor.

But having used them for a while, I quickly found out the disadvantages:

Fusion - It's a really nice application. Having used it for years now and even halfway created a stealth game in it - I like their engine. I am even selling some stuff at their store.The biggest disadvantage of using it is truly how bad it is at code reusal and instancing. It is so bad that people serious about making a game in it write their own level editor for the thing.
Functions in it are called 'fastloops' and you can not pass any arguments or return a value. You can not nest conditions in any way. You do a lot of copy and paste of conditions and actions. It is designed from the ground up to be good at copy and pasting, but not good at any instancing.
The level editor can not give unique values to different instances of an active object. You can do it via code during runtime, but not in the level editor. As a result you do a lot of copy and paste of an object in order to create variations of it. when you change the logic of one copy, it only changes in that one copy. This gets even worse when you consider using it on different levels - called 'frames' in fusion. All of your logic is attached to rooms. If you change a piece of logic in one room, the same piece will not change in all the other rooms. So imagine coding your game's inventory and hud. Later on you find a bug, and you fix it in one frame, then manually copy and pasting the logic too all the 150 other frames.
Fusion has a global event sheet , but the issue with it is that it can not use any 'qualifiers' (the way they call tags). This as a result locks you out of the opportunity to use a piece of logic globally on objects with the same tag. So it doesnt solve the problem with instances of an enemy not having the ability to vary in variables.
Fusion's editor has some bizarre hardcoded logic into it. You can not create your own qualifiers, just use the ones that come with the engine. The animation editor does not let you erase,reorder or rename the first 5-6 animation clips. Some clips are hardcodedly marked to have one properties, others have a different set of properties.
Exporters are fusion's biggest weakness at the moment - this is where people who write plugins for the engine must rewrite their plugin for each exporter. As a result a lot of features are supported under one platform and not available on the other platforms. A thing as simple as loading a json file and parsing it is not available as a built in feature.

To give them some credit - at least you can compile native code to different platforms - if you have bought the (expensive - hidden cost) exporters.

Construct2 - Scirra's tool is like a successor of fusion in terms of vis programming and it solves all the problems of code reusal. All of them. As a result it's community is much bigger and there are a lot more addons and features created by the community. The one big advantage of C2 is really also it's strength focused development. It compiles only to html5. That lets you port your game to all mobile and desktop platforms for free - you don't have to buy any expensive exporters. However that comes at a development cost - your game is basically loaded in a stripped down web browser - that adds about 100mb to it's download size and also there is some noticeable performance cost - especially on older mobile devices.

Then Godot caught my eye and I immediately fell in love with it.It excels at code reusal, comes with a huge amount of very useful functions. It compiles native code to all mobile and desktop platforms. Unlike the above two - it is both free and can be used to also create 3D games! The biggest advantage however I found out to be the open source nature and the community that has formed around it. Godot's community is wonderful, vibrant and very responsive. You have an issue? Post it on their fb group and in 5 minutes someone helps you out. If it's missing and it makes sense to have it - someone implements it the next day or puts it on the roadmap.

The engine has wonderful design, but it comes at some cost. You have to actually sit down and this time learn programming for real! No clicky visual stuff.
So I did and found out that gdscript is very similar to python. it can't have two iterators in FOR loops among other things, and some of the syntax and method names are different, but otherwise it's almost python.
Added that Blender, Inkscape and some of the other tools (Maya) that I love are written or use python for custom addons - it was an obvious choice for me to learn it. And someone from the Godot community had the perfect timing to point me to the Coursera courses!

so far I completed 2 of the 4 courses. I found them to be very good and they did enable me to do much more advance stuff with Godot and not have to ask stupid questions. The first course teaches about programming flow. The different types of loops, variable scopes, order of command execution, functions for code reusal and so on.

 The second course teaches about data structures in Python. How to load data from a text file and scan through it. Cut it, change it, load it into different structures (dictionary,lists,tuples) and use it to classify it's contents. This course is very key if you need to write an application (and most do) that saves data to the user's hard disk. When they save their game for example. This is where flow becomes a key to processing that information.