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.


Messages - darkhog

Pages: 1
1
Proposals / Re: Improving room/level editor
« on: May 25, 2014, 04:26:28 PM »
Yeah, I know it, as I said in new visual scripting proposal, I've tried to implement it myself for over a week. In the end I've gave up since I know jack shit about coding node-like structure (multiple inputs, multiple outputs and not predefined amount at that), but maybe others will be able follow with it. Currently I'm making graphics for friend's game (I am quite good pixelartist actually), but maybe after that I'll be able to try my hand at this.

But thanks for the link, maybe someone who knows how to code it better will be able to do so before I get the chance.

//edit: Also how hard would be to set up LGM's sources for NetBeans? While I've used Eclipse for my node scripting try, I much prefer NetBeans over it.

2
Proposals / Re: Improving room/level editor
« on: May 24, 2014, 03:54:38 AM »
Hm... Then maybe there is another programmer good with writing level editors willing to try? Anyway, I may give it go as well.

3
Proposals / Re: Improving room/level editor
« on: May 23, 2014, 10:02:42 AM »
No, I'm referring to painting tiles like e.g. in RPG Maker (or any sane 2d tile-based level editor for that matter). Objects can be placed like they currently are

 And while I agree that autotiles can be achieved via scripting, you'll still in editor have some dummy tiles that serve how tiles have to be placed and to see how exactly level does look like, I'll have to run the game. Not to mention coding autotiles is hard.

4
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.

5
Works in Progress / Re: Project Mario
« on: May 23, 2014, 07:58:43 AM »
Pretty cool! Actually this is first fan-made 3D Mario game that I've seen (not counting those silly first person mario projects). Can someone make video of it? Also how is gameplay? It is good?

6
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.

7
Proposals / Re: Better visual scripting
« on: May 23, 2014, 03:25:24 AM »
You can't stand VS in GM, because it is inferior in comparison to other tools like Clickteam's products, Construct, Game Develop. Hell, even Stencyl. In those tools VS is realized much better than in any version of GM.

GM visual scripting is just shitty, that's just fact.

As for my proposal, I spent ,last week or so trying to implement it myself, but I failed miserably. Hence posting here.

8
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