Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - darkhog

Pages: 1
1
General ENIGMA / Enigma - first steps (programming)
« on: May 23, 2014, 08:08:11 AM »
I've never been good friends with C/C++ (click to see why).

But I'm okay with c-like languages (has been programming in Java and C# for last 5 years). Could you give me some EDL-focused tutorials? I could use GM tutorials, but workflow and syntax is bit different and I'd like to avoid banging my head against wall over something that is correct in GML, but not in EDL.

Of course such tutorials should be beginner-friendly, but without basic concepts like variables, loops, etc, focusing on using EDL's library instead.

2
Proposals / Improving room/level editor
« on: May 23, 2014, 07:50:23 AM »
Another thing that original GM is bad at is level editor. Especially when using tiles. I think great example how level editor should be done is Stencyl and RPG Maker. For placing tiles there should be various tools like pencil, rectangle, ellipse, etc. Also support for autotiles would be superb.

Now, when I want e.g. draw platform or part of the overworld, I need to do this tile-by-tile. I can't just drag as if I'd be using pencil tool in graphic software.

Also, in tile selector, multiple tiles (rectangle) should be able to be selected when placing larger than 1x1 tile objects that don't need coding and as such using for them objects/sprites would be waste of resources.

3
Proposals / Better visual scripting
« on: May 22, 2014, 07:23:32 PM »
This is more for LGM/RadialGM.

One of the sore points of GM is that visual scripting capability is seriously limited, compared to tools like those by Clickteam or Game Develop. I know about GML/EDL but what I'm saying is that users should have a choice whether they want to use visual or textual scripting. Without any proper VS solution, the choice is virtually non-existent.

What I'm proposing is to base visual scripting on node-like structure (if anyone of you had ever used Jeskola Buzz, Psycle or SunVox should roughly know what I mean). Separate "modules" (aside of few built-in ones) could be coded in EDL and would come in two varietes:

- Events - basically work like "if" instruction and execute any action nodes (see below) that are connected to it when conditions are met. Event modules can be negated to make the condition they are supposed to evaluate be opposite (like adding ! in front of boolean expression)
- Actions - what to do when it is executed by event block.

There will also be some special "event" blocks that will be in always present in every visual script. Such as:

FrameStart - fires at start of every frame
FrameEnd - fires at end of each frame
Continuous - fires as fast as it can (no synch to framerate).
RoomStart - fires when room starts
RoomEnd - fires when room ends.

Ok. So how it would be processed?

Let suppose we have this simple workflow ([EV] means event block, [AC] means action block)

Code: [Select]
[EV]FrameStart->[EV]Player presses space && Mario can jump-> [AC]Mario.jump ->[EV]Mario is in water (negated)->[AC]Mario.allowjump==false
Yes I know handling input in synch with framerate is bad idea. Shut up, this is an example.

What happens here is that at start of frame activation signal is send to event block that checks if Mario can jump and if player presses space.  If it is met, Mario jumps. Then, AFTER jump action is executed, signal goes to event block that checks if Mario is in water(where he can jump infinitely) and if Mario isn't in water (as condition is negated), allowJump property for Mario is set to false (this is property that is evaluated "under the hood" for Mario can Jump module) so he can't do multiple jumps.

Of course you can link event module to multiple action/event modules:

Code: [Select]
                   [AC]Play music
[EV]RoomStart  ->  [AC]Put player at start
                   [EV]Player collide with enemy -> [AC]Remove any colliding enemy at start so player won't get insta-death
In such case all connected blocks/modules will be executed at once (or so fast that it would seem like at once).
If we have such setup:
Code: [Select]
[EV]Some event   \
                   ->[AC]Some Action
[EV]Some event 2 /

"Some Action" will be executed if either of events will be true.

Of course modules will be able to be shared between users.

During compilation, visual code will be compiled into EDL.

Pages: 1