Wow, Mark just reached his $1000 dollar goal!!!

Community Forums/Monkey Talk/Wow, Mark just reached his $1000 dollar goal!!!

Playniax(Posted 2017) [#1]
Way to go Monkey 2!

https://www.patreon.com/monkey2


Zethrax(Posted 2017) [#2]
Seems like a somewhat solid indicator of where Mark's focus should have probably been for the last ten or so years.


Derron(Posted 2017) [#3]
The problems I see with "1000/month will allow me to work fulltime on a 3d engine for monkey2!" and "patreon" is that income is not guaranteed for "x months/years".

So you might now stop doing whatever you do to earn a living - and in two months some patreons stop their payment and you have to look for a new job.

Dunno how to tackle that - except for having a higher initial "amount" (1500 instead of 1000) - but this is then harder to explain to the users.


Let's see what the payments bring on new games (done with m2) or modules (done for m2).


bye
Ron


RustyKristi(Posted 2017) [#4]
Good for Monkey2 supporters, seems like everything is falling into place, I hope so. But not for me.

If this is for Blitzmax I will be excited.


Richard Betson(Posted 2017) [#5]
Great news. Go Monkey 2... GO!


Blitzplotter(Posted 2017) [#6]
Good news so early into 2017 ;) Go Monkey 2 ;)


therevills(Posted 2017) [#7]
Wow that is quite a jump, the last time I looked it was only around $300 p/m... not sure how many patrons though.


skidracer(Posted 2017) [#8]
There are a few very generous contributors but I don't think that should matter.

If we want it sooner rather than later maybe Mark could consider a new stretch goal of $2K a month which would guarantee not only the project is officially on but that it is elevated to top priority or some such.


Zethrax(Posted 2017) [#9]
A modern 3D engine is probably a full time project by itself. He's probably better off looking for an open source engine that he can work with and adapting that for Monkey.


RustyKristi(Posted 2017) [#10]
That could be a big pressure to accomplish. It should keep up with modern rendering techniques like in today's game engines.

I agree, working on an existing engine would be much better off.


Yue(Posted 2017) [#11]
:D




Rick Nasher(Posted 2017) [#12]
That's good news. I'm currently out of money though so can't chip in but perhaps I can rob a bank? (kidding.. ;-)


EdzUp MkII(Posted 2017) [#13]
It's a certainly interesting time for Monkey2, one thing I will wait and see on is all the things that have been promised.

On the main homepage it spouts VR support this will take a considerable time to get sorted and if it fail or takes to long it might get canned.

For those that remember this is where max3d faltered, I hope it does happen though.


CGV(Posted 2017) [#14]
I would prefer that Mark actually finish what's already on his plate.

It seems like his old pattern of getting bored and moving on to something else.

He should get the mobile and emscripten targets finished first. Get some proper docs going, get the monetization modules done and selling, and then start contemplating a 3D engine.

And this all assumes that Monkey2's core functionality is already finished, which may not be the case!

All that this 3D engine means is a longer wait for Monkey2 to be finished.


Yue(Posted 2017) [#15]
@Rick Nasher

:D


Rick Nasher(Posted 2017) [#16]
xD


Richard Betson(Posted 2017) [#17]
I would prefer that Mark actually finish what's already on his plate.

You should read his blog here. Mark's got an office now and is in %100. Hitting the $1000 goal allows him to work fulltime on Monkey 2 and 3D. He lays it out in his blog really well I think. Monkey 2 has had a great start and with the right kind of financial support quite a lot can get done developing it.

About Monkey 2
Monkey 2 is a seed change in almost every way compared to previous BRL languages. Frankly, in my humble opinion, Monkey 2 is 'not' oriented toward previous BRL coders per-se, but instead aimed at everyone else. What I mean by that is Monkey 2 embraces modern programming techniques and support for third party libraries. This provides support and familiarity to those who code in Java or C/C++ or whatever. Embracing this larger audience is a foundational component of Monkey 2. Monkey does this with an eye on the past, allowing many of the same / similar commands and class structures that you use now. I have converted thousands of lines of code from Blitz Max to Monkey X to Monkey 2, possible because of a basic level of support for legacy syntax and structure.

I hope that the doubters look at the totality of Mark's path. Monkey 2 really shows off his experience and what he has learned from the past. His efforts on Monkey 2 have been for the most part spot on and well thought out. Monkey 2 offers you a path forward, where you have a voice in it's development. It has an open source code base that allows you to contribute and is free to use. There is a lot of potential for Monkey 2 and it exist in an environment that allows for growth, developer input and wider acceptance. I recommend giving Monkey 2 a try. I can't think of a better language project to back.


Kryzon(Posted 2017) [#18]
He's probably better off looking for an open source [3D] engine that he can work with and adapting that for Monkey.

That's not a bad idea, actually.


Wiebo(Posted 2017) [#19]
I have mixed feelings about this. Yes, new features are good, they are needed... 3D and VR is stuff I will not use so, for me personally, this plan does not add anything meaningful. But I am only one person, no biggie. Still, there are a lot of issues in M2 as it is and these need to be fixed as well. Again, docs is a mess as people have mentioned before.

And as Richard said, it is not really aimed at old Blitz users. I personally do not use any of the new language features, as I don't understand them.. Heh... To each his own.


EdzUp MkII(Posted 2017) [#20]
What I was stating in my post above was that VR has to be done properly, there can be no half measures.


Derron(Posted 2017) [#21]
Developing something with M2 surely helps fixing issues in M2 too. He comes across something "working not as expected" - and has to either circumvent it - or to fix the issue it bases on.


Next to 3D modules and the like it would be better to work on a good IDE - eg. by building a plugin for IntelliJ or so (so you do not have to build the editor but rather the language-support). And no, TED and that "TED GO" are no "IDEs" - last time (1 month ago) that TED GO put me off from even trying more with its unnatural GUI behaviour (modal dialogues). With such editors you can surely do things, but it just is not a "wow factor" for new users. And yes, there needs to be a freely available editor which does support all features the language provides (debugging, target options ...). Convenience things (assistants, intellisense, ...) could be provided by 3rd party (like jungle, blide, ...). If doing the IntelliJ-plugin-thing you get intellisense and the likes "for free".

For now you have the engine of a car but instead of a steering wheel you god some cables which you need to connect manually to steer left or right. It needs a wheel (or similar thing) to make the car "useable". Making a 3D-module is like adding air condition or a new hifi-system.

Yes, it is good to have "good audio" (or 3D-graphics) and it surely is a "USP" but the basic features have to be existing to make it a "serious" choice for new users.


Re: IntelliJ
For the language inventor it should not be that hard to write the lexer part (and what is needed in addition) so it works with such an editor as intented.
Instead of trying to get the m2-editor be able to work on all supported platforms, it should concentrate to work on the platforms a developer uses to type his code. No (current) need to have it run on a RasPI - as long as remote debugging is possible for a Mac/Win/Linux-based development.
But hey, better invent the wheel again and again (like creating a 3D engine from scratch - including having to learn how _all_ needed things work).


So I hope he does not only do a 3D-thing but:
- creating base tools for the language (editor, updater)
- create a game (to find culprits in the current implementation of the multimedia-framework-code)
- create modules while doing the game (admob, 3D...) which could be sold separately
- create contacts to "heavy users" so they might do similar things (so it creates some economy around M2)
- create social buzz (little competitions using M2, regularily posting updates, showcases, "seen on...", tutorials, "helpers/testers wanted" for specific subjects...)


bye
Ron


degac(Posted 2017) [#22]
As I said in the M forum Mark should develop/sell some games made with Monkey: the best way to demo it, know it, learn it and found new solutions/needs.

And about 3d Mark surely has different options: the *old* Max3d source code (I'm quite sure it's somewhere on git), a *wrapper* for some diffused 3d engine or write it from zero (not a great solution in terms of time and resources to be honest!)
Surely I suppose the 'physic' engine-solution should be taken from what the market offers (=write some sort of wrapper).
To be honest a 3d engine is itself a FULL work for one-man band! Just only make it working on different targets (PC/iOS/Android/Emscripten) is a big work!


EdzUp MkII(Posted 2017) [#23]
Yeah true one thing people will be expecting isn't circa 2000 games in VR but something like Leadwerks demos in VR.


Xerra(Posted 2017) [#24]
Couldn't give a stuff about 3d or VR but having a release candidate would be a milestone. By that I mean proper documentation and usable development environment. I'm concerned how $1000 a month is actually considered enough money to live on. Especially if you're renting an office as well. Surely Mark must still be working full-time and getting a pay cheque?

If I could have Blide with Monkey 2 and both working on the Mac, then I'd be sticking my nose right in and supporting the Patreon, but that's more than just Marks involvement, unless he started involving other people in the community who could be a massive help to him. Same goes for the other power users from Max who are still around. Get people like Brucey involved, although I suspect he's not interested :-(

Oh gawd, I wish I had Blide on the Mac, though. I have to boot into parallels every time I want to tinker with Max these days.


Ian Thompson(Posted 2017) [#25]
Good news about 3D, MX2 needs it to be noticed. But I have to agree with some of these posts, MX2 would be better interfacing with a decent 3D open source engine IMHO.


Playniax(Posted 2017) [#26]
I agree with some of these posts. blitz3d style 3d is nice and it will attract a new bunch of people but there are still things to be done about the foundation of Monkey2. I do like Ted2Go. I am using it for weeks now (coming from Ted) and it's really not bad. It still has some quirks to be ironed out but I enjoy using it. I consider Monkey2 a WIP for now but a really usable WIP.

I can't wait to play with 3d and create an exporter from our editor to a 3d environment.


RustyKristi(Posted 2017) [#27]
@Playniax,

Slightly off topic but I was wondering when you will be releasing your Ignition framework for Max as freebie as well, same as Pyro2? I cannot post on the original thread because it is already archived..

I will advice you not to buy IgnitionMax because soon I will make it available for free and you need some basic knowledge of BlitzMax before using it anyway. Not sure what license yet but when I know I will post it here! Shortly after the release of Pyro 2...


http://www.blitzbasic.com/Community/post.php?topic=107165&post=1326019

Thanks.


Yue(Posted 2017) [#28]
In the end, this involves a lot of work and anything can happen on the way. Like an incomplete product or something similar.

For my part I think Mono 2 throws you to another abyss away from the normal products of the old user community, but you can certainly do the transaction without problems if you have been through BlitzMax.


Steve Elliott(Posted 2017) [#29]
Looks like some generous soul just pledged $1000 for a year (post 26):

http://www.blitzbasic.com/Community/posts.php?topic=107595


Playniax(Posted 2017) [#30]
Cool!

Who can and wants to pledge $1 dollar or more per month? ;)


Playniax(Posted 2017) [#31]
@RustyKristi

Can't say right now. I am working on an update so that it can support our Pyro tools like the upcoming particle editor and scene editor. Sorry!


ImaginaryHuman(Posted 2017) [#32]
Someone said up there "but instead aimed at everyone else. What I mean by that is Monkey 2 embraces modern programming techniques and support for third party libraries." ....

Really? You think that 'everyone else' wants to actually write source code programs in order to develop games? Times have moved on big time.

The glaring gaping hole in the Blitz toolset now is the fact is does not have a visual, easy-to-use, time-saving editor. It's got nothing to do with what the language does or how its written or whether it supports libraries or whatever. Being the right programming language is not the way to go. Game development isn't about writing lots of code anymore.

Go look at almost all of the competition, Game Maker, Game Salad, Construct, MultiMedia Fusion, and also Unity3D, Unreal engine etc. Look at what is involved in making a modern game of decent quality. It's not all about programming. You've got art assets to manage. You've got levels to design. You've got tons of objects to play in the environment. You've got physics to assemble. You've got 3D stuff going on all over the place. You've got modern screen effects and shaders happening effortlessly. And then when you can't do something that the editor provides, you've got third party add-ons that provide extra workflows. And then if you exhaust those, THEN you can dip into some 'scripting', which is typically slow, painful, complicated and advanced.

But the fact is, programming now, compared to using a visual editor, is a huge pain. It takes an extraordinary amount of time and effort. A visual editor isn't just there to give you a different way to make games it's there to AUTOMATE tons of tasks and to give you a much easier time saving way of iterating creatively, experimenting, polishing etc. Do you really want to try to do that in source code? You want to go back to source code in order to implement a complicated 3D animation? You want to go to sourcecode to build your basic AI or collision detection? You want to spend weeks or months having to build either an engine or a 'tool' to try to save time?

Blitz should really focus on getting a solid backend - Monkey should be the backend, MAYBE with 3D (and maybe 3rd party 3D), and then cover this all over with a thick slab of WYSIWYG editing. So that you barely have to ever 'program' anymore. See then just how productive you become, how much time you save, how much less painful it is to put stuff together. Because really, this whole paradigm of 'programming games' is significantly limiting and holding back ALL developers who are trying to make games this way. It's archaic. This is how things were 'hot' 10 years ago. The answer is not another 'better Monkey' or whatever..... totally totally missing the point.... totally out of touch with the general game-development audience. Not going to win many fans any time soon when people can go get a visual editor that makes it EASY and saves a ton of time.

I think if BRL is so obsessed with 'making languages' then BRL should focus on making the backend systems - Monkey - the script language - and hire or partner with someone else to make a glossy user-friendly front-end. The language should not be the front end, or where all development happens. It should be a backend feature for 'advanced users' to do more complicated stuff if they really need to - i.e. if the editor isn't flexible enough to do what they want. But almost all development tasks can be automated and turned into tools and workflows that save time and effort and headaches. It's a no-brainer. Programming games in a language is going to gradually die and be replaced with tools. It's already happened.

Quite literally the 'game' has changed. Development is not about writing programs all day anymore, for the vast majority of would-be game developers. Its about the higher level tools. That's where BRL has to go, and if they don't, which they haven't, they will just continue to gasp for air in a crowded market. I love BlitzMax and Monkey seems clever but ... really... its 2017 no 2000... we need time-saving visual editors now, not more elegant ways to spend weeks on end trying to do even the 'basic' stuff that all the other engines can do in 5 minutes. Leaving 'tools' up to the user is a major fail in my opinion. Now you have to spend tons of time writing a half-baked pretty ugly tool that barely does the job, AND THEN maybe you can start saving some time. Maybe you'll make up for all the time it took to make the tool in the first place.

Higher level editing. That's what the people want. And someday we're going to be just talking to the computer and have it auto-generate the game of our dreams in a matter of minutes.


RustyKristi(Posted 2017) [#33]
This is the hilight for me..

BRL is so obsessed with 'making languages'


you got it ImaginaryHuman.. bullseye


Xaron(Posted 2017) [#34]
Hmm... actually I've been there and I've made a game using Unity. Editors can make things easier for sure but on the other hand there are almost no good ones out there. I can't count the hours I wasted with workarounds because of editor bugs in Unity, forgotten prefab links, sub particle systems that were suddenly gone and all that stuff.

When you want "time saving" editors, there are plenty out there. Do you really believe a one man show like Mark could compete with Unity, Game Maker or whatever fancy tools you've named?

Personally I prefer full control. Call me the coding guy, a relict of the past but yes, I still prefer to do everything code wise.


BlitzSupport(Posted 2017) [#35]
I prefer code too. There's no shortage of coders out there.


Playniax(Posted 2017) [#36]
I get what ImaginaryHuman is trying to say but I agree more with Xaron. Visual editors are a must in game development but not in the way most of them are implemented today.


Richard Betson(Posted 2017) [#37]
Like Unity? Then go use it. Why stay here? Why be here? Blitz Max and Monkey X/2 are not Unity and are code based.


AdamStrange(Posted 2017) [#38]
Sorta on topic.
I have an editor to create vector graphics
I have an editor to create bitmap font graphics
I have an editor to create map based systems
I have a palette editor which is unified across all other editors
(these have been integrated into my text editor)

I need to write a simple particle editor so I have these on tap to link with the above

I have a full audio editor, but this need to be trimmed and recreated to fit with the above

I have an 8bit editor for sound creation

I need to write a sequencer to link the sound stuff together

-----
You can see where all of this is going. The main thing is to have an over-reaching unified approach and concept for editors and how they all operate.

at the end of the day it is all data - but data is an incredibly difficult thing to get right


Xaron(Posted 2017) [#39]
All in all I agree that marketing IS essential and Mark actually sucks hard in it. Plus the name Monkey is awful for a language. Plus I never understood the split of the community over there to Monkey and now even a further split over there to Monkey 2...

I think Mark should concentrate of what he's best in - which is probably creating languages but he really SHOULD hire someone who's doing a bit of marketing and modern website stuff.

...but we all know this will never happen... :(


davidboy(Posted 2017) [#40]
ImaginaryHuman, your long article is very, very good.

Blitz Research spends much time on making new programming languages for a small group of game developers (these develolpers are with good programming knowledge). The size of this group of developers is too small nowadays. Therefore, Blitz Research cannot get enough income for running the company.

In the meantime, many game developers(include many newcomers who don't have any game development experiences) need easier tools to make games(or assemble games). It is because programming a whole game is too, too difficult for these people Therefore, they select to use GameMaker, Clickteam Fusion, Stencyl, GameSalad, Construct, Unity, etc.

Moreover, some game developers(although they have good programming knowledge) also don't use pure programming languages to make games any more because time is money. They also decide to change to use GameMaker, Clickteam Fusion, Stencyl, GameSalad, Construct, Unity, etc. for developing games. These game making tools can help them to finish complete games within shorter periods of time.

In fact, GameMaker, Clickteam Fusion, Stencyl, GameSalad and Construct are for 2D game development only but they still have huge numbers of users.! These tools' companies are rich now and many successful and popular games are made with these tools.

In conclusion, perhaps Blitz Research needs a very good business direction or a very good business plan. Right.?


Xaron(Posted 2017) [#41]
David, but going into the direction of GameMaker, Clickteam Fusion, Stencyl, GameSalad etc. is NOT a solution. It would be then one among the others.

As I tend to agree that copying working business models is an option, this only works IF you do BETTER than the existing ones. And this is almost an impossible thing for a lonely guy. Never underestimate the time you need to create a good editor based solution. Doing a compiler is piece of cake against that.

Plus, IF you like to use an editor based solution you already have the option to choose between all those above or what would you think Mark could do better than the existing ones?


Richard Betson(Posted 2017) [#42]
GameMaker, Clickteam Fusion, Stencyl, GameSalad etc
The bastion of unskilled coders everywhere Unity chief among them. You have to have the skills to code outside of a visual editor and just the thought of using one makes me wince. I've no issues with straight up code and pace of development, I find it easy to manage and flexible. To each his own I guess.

Monkey 2 is not going the visual editor path and we (Monkey 2 coders) are happy about that.


Danilo(Posted 2017) [#43]
I hope so, Richard Betson! Mark is creating great languages that can be extended and are
cross-platform, not only for desktop. Who does not have an iPad or Android tablet,
and a smartphone today? Only few 70+ years old people.

In my opinion, Mark Sibly concentrates a little bit too much on the games thingy,
while tablets and phones don't mean 'games only'.
The gaming world is only a small part of the whole thing. Applications and Communication Platforms
are more important, in my opinion.
Personally, I don't and wouldn't use my precious lifetime to play games every day.

Including the sqlite database and zip files, for example, is the right direction for MX2.
The connected world is not only about games. The whole commercial world is connected,
and the new world is about connecting all kind of things - not about playing games only.

IoT - Internet of Things.


AdamStrange(Posted 2017) [#44]
it's also a case of tools are not always visual (point and click, no code). but there to help you achieve something.

OK. heres a simple example.
lets say we have a single row image atlas (which can be viewed in the editor):


and in the code we reference the icons from 0.
Without starting from the first image and counting, what is the number of the lambda and cog icons?

The answer is 11 and 16.
In fact, getting the reference of any icon becomes a challenge as you really have to start counting from 0 each time - and then double-check to make sure.

How about if there were 100 icons. it suddenly isn't quite so easy.

But this is:


It's a very simple tool. it doesn't do anything. but it means you can instantly check any icon number just by looking at the icon and the number.

Here is the in-editor shot of the standard png file:


and the show as icons toggle on:


it's certainly NOT a visual editor, but it is a visual tool to make your life simpler and quicker.

---

Regardless of the status of any new 3d module for monkey2. it should be at least be able to read in other formats and give the programmer a visual clue as to what is going on.


Richard Betson(Posted 2017) [#45]
Mark Sibly concentrates a little bit too much on the games thingy

I think gaming is a great base to breakout from and one Mark is familiar with. With the 3D module on track Monkey 2 will have a good starting point to attract other mainstream (not Unity) coders. Gaming is big business and a niche worth exploring. Additions like SQLlite and zip files help round out needed features for larger scale projects.

I'm hoping that after the 3D module is done Mark could move on multi-threading which also fits in well with game development. I think after that's done moving to support application based projects would be a good move. Things like native GUI support and such.


RemiD(Posted 2017) [#46]
one thing is sure : whether you prefer to use a visual editor or to code (or a combination of the 2), there is no advantage to complicate the language used to code/script.
hence blitzbasic>monkey imo


Danilo(Posted 2017) [#47]
The programming language is about 'expressing yourself', and the more 'complicated' the language is,
the more possibilities you have to express yourself.
The more you limit the language you can use, the more you limit the expression/outcome...

Limit the language you can use, limit the outcome...


taumel(Posted 2017) [#48]
Reading trough the threads here, i think that some of you are nuts.

a) Finally, after many years, Mark is into 3d again. On top he already got the money he was asking for. This, is the best chance for 3d support in a BRL product.

b) monkey2 is not perfect/finished but overall it's better than Max. There is active development. If you don't need one of the many things Brucey made possible for Max/MaxNG, you could check out monkey2. A active community could help bringing things together too.

c) Audio and 3d are very important. More important than implementing nerd editor heaven, no one will ever see in a final product. I would rather drive a sports car with two wires only than having a great steering wheel but without a reasonable motor experience. 3d dev is highly driven by what you can get out of an engine. If you can have both (a balanced experience), that's even better.

d) Ditching Unity, without knowing it, is stupid and so <= 2015. In most cases Unity's IDE is a big time saver. Unity combines accessibility via its editor with the flexibility coding offers in order to make things easier and faster. If Mark had the resources, he would go for such an approach too. Unity suffers from its bugs, size and ancient mono-core/garbage collector but is highly optimised in many aspects where BRL products don't even offer a bad solution.

e) @Simon Armstrong: You could relax more often or not moderate a forum as you sometimes don't show the right temper/character.

f) A 3d engine is a critical part of a game engine, therefore many devs try to come up with their own solution, mixing it with middleware for certain aspects, in order to have control. It would be great if Mark could come up with something within a year or so.

g) There doesn't exist a big market for a Blitz3D like engine with bump maps and shader support (most of you probably will never touch twice). Either you stick with the BRL audience or you need to offer something more competetive (like a modern focused 3d engine, Unity light). 3d is not 2d. 3d is more about performance, up to date concepts/hardware and visual quality.

h) Ted2Go is just plain awful. It looks wrong, it feels wrong. If you're complainging about Unity's IDE, try to use this one. Actually, no, don't.

i) It's very generous of people like impixi being this involved into monkey2 and 3d. Not having to care about finances can be a big advantage if stuff just needs its time. Regardless of a lack of financial feedback, you should try to be aware of staying on track without ignoring users' needs.

j) BRL products always had an emphasis on games and you could utalise this power for other field of applications. Supporting tons of platforms as a focus on apps would overload the one man show and there is no chance that Mark would be able keeping up with all platforms. If you want cumbersome support of many platforms, see how Monkey-X failed. If you're serious about apps, you want to utalize each system's pros and go native. Weird looking outdated gui apps aren't competitive and internet apps aren't in BRL's (or its users) focus either.


Richard Betson(Posted 2017) [#49]
If Mark had the resources, he would go for such an approach too

I think not! At least I hope not. Unity blows and it is a bloated behemoth for novice coders.


AdamStrange(Posted 2017) [#50]
h) Ted2Go is just plain awful. It looks wrong, it feels wrong. If you're complainging about the Unity's IDE, try to use this one. Actually, no, don't.

Purely out of interest. What is so wrong with Ted2Go?


RustyKristi(Posted 2017) [#51]
Is that the new code editor/IDE for Monkey2? Honestly, the interface looks like it was done by a newbie programming or a UX designer. It really does not look right.

Big fonts, not too much spacing or balanced. It looks like playing one of those japanese rpg games on a handheld.

That was one big drawback for me but Blitzmax IDE looks ok.


Richard Betson(Posted 2017) [#52]
^Obviously knows nothing about how to use Ted2. You can adjust the fonts and it's a nice IDE and in development.


Xaron(Posted 2017) [#53]
Well I have to step in regarding Ted2Go and have to agree with taumel there. I totally appreciate the hard work the guys over there put into it (especially nerobot) but it's not a good IDE.

All that look and feel (and no, that's not only font size and colors) is just wrong. It's 90s. :D

Plus at least for me it simply doesn't work as stuff like CTRL+S, +N and so on doesn't work on my PC due to unknown reasons.

And call me stupid but IDEs where you can't replace tabs with spaces are a no go for me. There's a reason why the company I work for has coding guidelines which force you to use spaces instead of tabs because only that way it will ALWAYS look the same everywhere (including diff and merging tools).


Henri(Posted 2017) [#54]
There is also a reason why tab key was invented. To avoid needles tapping of space/backspace and to have consistant look on an editor. I do agree about the IDE in general. It should have basic stuff like Ctrl + S to save your text. I always use this intuitively in any editor. Ted2Go is unfamiliar to me.

-Henri


Xaron(Posted 2017) [#55]
True Henri, and that's what "replace tabs with spaces" does. No imagine one guy uses tabs and other one spaces or different tools have different tab values and so on... Awful!


Richard Betson(Posted 2017) [#56]
Ctrl+N, Ctrl+S,Ctrl+O and so on all work on my version of Ted2. Tab's for the win.


Xaron(Posted 2017) [#57]
Well again, nothing against tabs (developers in teams usually do not use them anyway) but there should be always an option to replace them. ;)

And I know that Ctrl+S and so on usually work but not on my system (where all other IDEs have no problem with these keys) so there must be something fancy going on under the hood of Ted.


taumel(Posted 2017) [#58]
@Richard Betson
From the last time i used monkey2 (with the Tetris objects). A.o. I wanted to test the behaviour of concave (not available, so faking with springs) and convex poly collisions.

In monkey2: open monkey2, write/open a generic setup, add code for loading and offering images, look up the docs for chipmunk options -> no examples -> browsing through the official chipmunk doc-> write code to add the physics definitions for the sprites (for poly collisions you need to define a convex hull with the related vertex data, so either a) download a tool which gets such info from the images or write one on your own and copy&paste the data into your code or b) measure the pixels in a paint program and gen the vertex list with the coordinates), write code to update the simulation, write code to link the physics to the sprites and display them, write code to free memory, write movement code, compile and run a few times in order to tweak parameters and get the desired result, finish.

In Unity: open the editor, select a 2d project, drag the images into the asset area, from there drag them into the hierarchy, position the sprites properly in the scene, add 2d physic components to the sprites (collision hull is automatically generated), edit the properties, gen a script, write some c# movement code, drag it into the hierarchy, less tweaking of the parameters for getting the desired result needed (due to the wysiwyg game view in the editor), finish.

You could do this by code as well (more work).

The IDE is good for managing data, editing properties, game specific customisations, setting up/tweaking the visuals/sound ... This procedure is faster for a typical setup. Obviously procedural generation benefits less from such a workflow, except for exposing realtime parameters to the editor. The beauty is about striking the right balance. Sometimes you're more into an editor, sometimes you wanna go by code.


Derron(Posted 2017) [#59]
Editors wont help uf you load things dynamically (in my game resources are defined in customizable xml files).
So you could add helpers for traditional things like a tile editor a spritesheet editor...but if one adjusted/extended the underlaying code then the helpers might get useless.

So like with cross platform you could only add more generic tools... Color selector dialogues and the like. Else you need to make your editor aware of addons / extensions so you could create tools for youe individual framework.


Bye
Ron


taumel(Posted 2017) [#60]
They do help. An IDE with a preview helps you to grasp and setup a world in a more intuitive way, like defining and testing the parameters for physics on the fly or speaking of 3d tweaking the settings for the lighting, material definitions, post processing effects ... i'm fine with if Mark's 3d won't be able to do this but saying that this isn't helpful is wrong.


Derron(Posted 2017) [#61]
Like said: such things work only if:
- the dev only uses the provided functionality
- the dev uses 3rd party functionality which uses a predefined structure / API
- the dev uses 3rd party functionality and a 3rd party extension managing that functionality and its settings


So if there is an additional "3rd party GUI framework" then there must be either an addon adding the GUI-designer and taking care of save/load/design ... - or that framework provides an addon which only uses hooks provided by the Editor: GetCanvasContent:TPixmap(x,y,w,h) and the likes.
BTW I suggested something similar for MaxIDE already - addons would be written in LUA and would get access to the source code files of a project (in the case of multiple opened projects - some should be not visible for the "eyes" of the addon - business projects or so).


bye
Ron


taumel(Posted 2017) [#62]
Apart from the workload I don't see why #1 should be an issue as it would be integral part of an engine. A third party developer could be a solution but if the dev isn't dedicated, it comes with the risk that there could be problems between the engine and the extension. You don't want problems with such data. Hmm, 3dpi was an amazing tool for its time.


Derron(Posted 2017) [#63]
#1 is not possible with the current frameworks provided with monkey/m2 and blitzmax. Talking about ingame-gui, resource-management-via-configuration-files (xml or so), sprites, sprite-atlases, versatile text formatting (block text, hyphenation, mixing bold/italic/embossed/gradient...whatever you like and [b]bold[/] and [/italic] in one sentence) ...
Nowerdays developers want many things - and you will have to provide them all this right from start. This is not possible that fast - which is why I suggested an extension/addon-system for the editor. And once you think about such things, you might end up using eclipse/atom/intelij for already providing such systems (at least I think so).

If the language exposes properties correctly - so the editor is able to tell what options to provide to a user, then these things could be presented to the coder in a dialogue box - but I do not know if M2 is capable of doing this (yet).


Nonetheless: Of course an editor providing features for all the "basically provided things" would be a nice thing. You want to play a sound? "Menu -> Add -> Simple -> PlayMusic", Dialogue opens and provides a dropdown of already loaded music-URIs and also a file browser. Now the coder selects an existing file and only the "PlayMusic(existingVariable)" is suggested (might still fail if the user intentionally renamed/refilled the variable content). If the user selected a new file (via file browser) then it is also the file-loading-code appended to the sourcecode.

But these things only work if you have centralized "onStart" or "InitResources()" hooks. Things in which the music file could get added to get loaded. Without that - read it is totally up to the coder when and where he loads resources - such helpers are not able to take off that much work load from the coder.

So you will have to place some "rails" for the projects to traverse on - and as long as they follow that "rails" the tools will be able to help.

For everything else you have to fall back to real basic helpers (font-choosers with font previews, image previews, sound previews, color choosers).


I would be interested to see how many (commercial) games were made with BlitzMax and the default framework - not utilizing custom framework code (TEntity, TParticle, TSprite, ...). There might be some, but the more complex the gameplay gets, the harder I think a "click-your-game"-solution would be for a "visual editor". Same for staying within the "predefined-framework-code".


bye
Ron


taumel(Posted 2017) [#64]
I think the best tool and Mark's biggest chances exist when going with focused but well designed ted2/engines for less platforms. I don't want it to be complex and bloated. There is something about staying slim whilst offering the right aspects. People are happy when their worlds are clearly arranged. Unity tries to offer everything, that's not where Mark should try to go. More Sublime, less Eclipse. Mark already started offering some data preview (images and sounds) in ted2. More integration and additional options wouldn't hurt.

Many of the IDE-nay-sayers fail to see, that it's not about to replace coding in the first place. It's about a reasonable shift where to use code and where something more appropriate, like using an editor, makes sense. Normally you don't want to paint your textures by code, you use an image editor because you want to experience what you paint, you want to use a wacom, you want instant feedback, you want it to be flexible. Same goes for a composing music, you use an instrument, a tracker or whatever but you don't limit yourself by editing bytes in an array. This might be nice for a demo compo but not how it works best for most use cases.

And the same is valid for certain further tasks in game development (or 3d/2d media). It makes no sense editing your lighting when you can't see it. It's mostly cumbersome defining a 3d world (i know that ray marching with distance fields is cool) by code and you can't imagine how materials look like without realtime feedback. Somehow this goes back to the C64 when it took a night to render out a fractal. The more direct and intuitive you can edit a project and receive feedback, the better.

The editor in Unity and the access to the engines offer one way of shifting some of the (meta) data away from code in order to making it easier (also causing less errors) and faster setting up things. Live representation of code is cool too and also helps making you less blind. Fast compilation times help as well. There are multiple ways to enhance the situation.

Ultimately you want results and you head for the workflow which offers the best experience. If a mouse driven OS is better than DOS then there is no reason to stay with DOS.


skidracer(Posted 2017) [#65]
If the BSP support included Maplet integrated Ted2Go that would be nice.


Derron(Posted 2017) [#66]
Like said - this is only possible with a predefined behaviour or fixed "API/calling-scheme".

If you have a dynamically created world (created upon whatever the player does) you cannot preview it "simply" in a preview window - except you predefine all these things (Mockup data).

So yes: if you only use what the "monkey2 world" offers, then these helper tools will assist the developer. But once you leave that "monkey2 world" you are on your own - and only benefit from a good working editor (find, replace, autocomplete, intellisense, maybe auto adding "imports" once you use a given command, ...)


bye
Ron


taumel(Posted 2017) [#67]
In most cases the content isn't purely dynamically generated and if it is, you still benefit from exposing parameters to the editor.