Forum Replies Created
-
AuthorPosts
-
This stupid thread should just be flat out deleted
people need to stop complaining about the language and features. these same arguments happened when Mark released bmx and many of the b3d users didn’t want to embrace oo. and I really don’t understand the issue at all with lambdas. They are critical to any new language… once you really start using them I highly doubt you’ll stop. maybe it’s the keyword lambda… if it was just “function” nobody would have noticed.
October 17, 2017 at 6:57 pm in reply to: Is Mark pulling the plug on Monkey2? Worrying comments on Twitter #11149AND: i never read anything about Monkey 2, the first time was 2 days ago…
where and what did you hear?
The website really does need wrok… super slow, gloomy, broken in parts. that said, don’t waste your time or money changing that just yet… take a tiny break by following your road map… concentrate on making a game to sell. let that direct changes to monkey2.
at the same time talk more! tell us what you’re doing more often even if it goes no where. your you tube videos need to be better… again, talk… make sure they have sound! tell us what you did and why…. how you got to that part. same with blogs… at least once a month post something. the more you talk (about good things) the more other people talk.
any don’t worry about many of the features you already coded… that’s water under the bridge… look to the future… and again write a game with the purpose to sell it on steam for some cash.. have those requirements dictate your next compiler/environment changes.
you need to engage… for that matter I believe all of life is best when one engages people.
Yeah, that was me and yeah, that was a long long time ago. I’m getting old!
@nerobot, My pleasure… great job with the fork!
I disagree… 3 then 2. and obviously, the 2 engine won’t have the same feature set.
I’m for combination of ‘more chars’ and ‘..’. I think Danilo pretty much nailed it.
Roadmaps are not as hard as people think! all it needs to be is a list of
– what you were working on
– what you are currently working on
– what you will be working on next
– what you would like to work on in the futureMark used to have a roadmap on this site and it was fine. the only issue was that when he finished something he removed the item. that wrong…. you just mark it “done”. and for things you aren’t going to do anymore, mark “abandoned”. simple
exactly the same way you would now.. the only thing that is actually different is the selector window stays open, docked… when there is nothing to complete it’s just empty. when populated the top hit fills inline in the editor with your cursor at the last char typed and the remaining letters following in like a greyed out color style (this is your auto complete indicator) actually if remember xcode does that part. tab/return completes and cursor keys (only when the autocomplete docked list has items in it) move up and down the complete list as normal.
you know what would be a cool option… docking the complete window. I once wrote for an autocomplete for an bmx editor I never finished, what it did was to keep the complete window opened and docked on the right so that it never obscured the actual code you were working on. In addition, it inserted inline the top hit dimmed and keeping the cursor in the same place of course. Worked great and you didn’t get this window flashing on and off all the time as you typed.
also… in these editors you should allow a workflow that can see external changes and update… so those app seem integrated as well in you ide. for instance, I like Aseprite for bitmap editing so if I have a bitmap ‘object’ in your ide and I make a change using aseprite, it would be nice to have your app recognize and automatically update all the assets.
I’m making the assumption here that the primary purpose of your editors are for creation and assembly of game objects with creation and modification of the base assets being secondary? (since there are really awesome apps out there like Aseprite)
nice… and this should integrate with your bitmap editor to create collision polys for bitmap objects as well.
then of course since you seem to be flying through this stuff… build a scene graph bitmap animation editor on top of both of these!
or mine…
ditto everything wiebow said though I did write an save optimizer that removed all duplicate points out. so multiple segments would turn into a polygon if colors and position are the same. the layering idea you mentioned is actually important as you usually want at least 2 polys per object… the visible and the collision which is generally much less complex.
my library had lighting as well… I would calculate the segment’s distance and angle from each light source and apply color changes as needed. that worked pretty nice… I even started to add keyframe animation moving each point through easing. though I never put that in a game.
building stuff like this is fun! I miss it
http://ooeyug.com/images/vecedit3.png
wait why can’t you just ignore statement enders while inside () and []? maybe I haven’t thought this through but don’t those always imply the same statement? The nice thing about this is then you don’t need to worry about any others like commas, right?
what about ‘+’ for string formulations?
-
AuthorPosts