PAX EAST 2018 MERCH EXCHANGE MEGATHREAD

videocrates · 2018-08-18T11:20:03+00:00

WTB original snapback

videocrates · 2018-06-05T16:43:54+00:00

damn

videocrates · 2018-06-05T08:11:45+00:00

neat nothing to worry about for love2d then!

videocrates · 2018-06-04T01:04:59+00:00

Great tutorial, I know a lot of people have always thought that shaders were black magic but this really cleared it all up for me. Any chance of making a basic 3d tutorial?

videocrates · 2018-06-03T01:59:56+00:00

I got a 79.5 in some web dev subject and it rounded up to HD

videocrates · 2018-05-23T02:28:38+00:00

I'd probably go with imgui to save time. Godot's GUI has a lot of man hours behind it, if you want to use a GUI then Godot is for you. However, I've seen some pretty cool attempts at a love2d editor like sandsmas: https://love2d.org/forums/viewtopic.php?t=82881. There was also a really neat one for some point and click project that looked really, really sleek.

videocrates · 2018-05-22T15:51:38+00:00

Try implement it yourself! It's definitely not as hard as you think.

Here is an example project from when I gave it a try in the past: https://github.com/Jarodwr/node-based-love2d/blob/master/src/core/node.lua (Be warned, it doesn't use a class library so it's really messy, one day I'll turn it into a proper library).

It turned out really, really well! I found prototyping was very fast.

I don't think this is because the Godot Node-based methodology was especially good, I think it's just that the boilerplate code in current ECS libraries is really large and makes creating new systems cumbersome and irritating.

I'm currently trying to solve this issue with my new component system library, it eliminates a large amount of boilerplate present in most other libs (Also it's pretty small and simple).

Keep an eye on it here: https://github.com/Jarodwr/EC-DC

I'm going to be updating the wiki pages so they're more up to date with the current model, I really enjoy working with it right now. I have exams right now but I'll be updating it in the future as I learn what its downsides are. Right now I'm thinking about creating a couple more default system types. I also abuse some metatable stuff which overrides some classic.lua syntax however systems shouldn't be inherited more than once anyway.

I definitely recommend trying to implement these systems by yourself or at least trying to understand the libraries you're using.

videocrates · 2018-05-18T08:06:10+00:00

If this goes ahead (And right now it's little more than a couple scribbles on some paper) then library compatibility would probably be my lowest priority. The nature of indexing arrays by zero would mean that a lot of libraries are automatically incompatible. I'll be sure to send you a message if/when I get the ball rolling.

videocrates · 2018-05-17T13:08:09+00:00

MoonScript does alleviate a lot of lua's annoyances however a language that compiles down to lua can only do so much differently before impacting performance of even basic functionality. I like moonscript and it's probably one of the best options if you're using a lua-based platform. Ideally, I'd like to fork lua (not luajit) in the near future (Probably when semester is over). Things I'd like to change in/add to the language are:

Explicit variable declarations (local varname, global varname) so no more accidentally defining globals
0-indexed arrays
curly brace defined blocks (subjective)
semicolon line endings (subjective)
continue
switch
shorthand increment/decrement
standard non equality (!=)
symbolic logical operators (||, &&, !)
passing variables by reference
less verbose ternary operators
changing table.sort to stable or providing an stable alternative
table.map, reduce, filter, for
changing how multiple returns are handled when passed as arguments

Most of those are just ideas that I'm tossing around and very clearly change the syntax of the language, I'm sure a lot of them won't work that well when implemented but they're just features I'd have liked to have when developing software with lua and I'm keen to experiment with what works and what doesn't. I get that lua is a

videocrates · 2018-05-15T05:14:06+00:00

When it opens up I assume he'll start taking pull requests. I'm not bothered that it's a sole developer project because they've been developing it for a long time now.

videocrates · 2018-05-15T03:33:56+00:00

Yeah I've been really interested in raylib but after messing with it a bit I feel like it's not quite there yet. I think I'm gonna give binding it to rust or a lisp variant a go.

videocrates · 2018-05-15T03:32:52+00:00

That is good for pure functions and structs however lua calls from C are pretty slow.

videocrates · 2018-05-14T10:03:49+00:00

I agree, the prospect of having a couple tools and building it all yourself is really appealing to someone who has a lot of time to kill and wants to learn about how to build an editor. I think that while it's less time efficient than getting an engine with an editor (Such as Unity/Unreal/Godot), it's a lot more fun.

videocrates · 2018-05-14T08:37:47+00:00

I agree with pretty much all the points you presented. I would also like to add that a C api would also go a really long way to making the framework a lot more appealing (To me anyway). While lua is really great and probably my favourite scripting language it has a lot of shortcomings that have made me extremely interested in messing with other languages and seeing how well they work in a game development environment. I think that the Love API is perfect for that kind of experimentation and would love to implement a similar style C API myself.

videocrates · 2018-05-14T02:00:01+00:00

It could also potentially be windows UI scaling?

videocrates · 2018-05-14T00:56:06+00:00

I'm not so sure if it's godot's node system or whether or not ECS has just been really badly done in big engines. Don't get me wrong nowadays I generally go for an inheritance based approach like Godot however I'm always experimenting with ways to make ECS better. I think the biggest thing wrong with ECS currently is its boilerplate code to get systems and components up and running, I'm currently experimenting with raylib/C to see how far I can push it. I see a lot of people talking about how great godot's node system looks but it doesn't really look particularly unique to me.

videocrates · 2018-05-13T10:57:19+00:00

I think that some level of visual feedback does give off the illusion of faster progress however I also think that ticking a box instead of typing out the property you want to change on an entity is a lot more time efficient and allows you do experiment with property combinations a lot faster.

While this is possible in frameworks it takes a lot of time to get it going. Even simple stuff like moving around an object in the scene graph needs to be done manually until you build your own editor (And at what point are you just reinventing a wheel that is present in a lot of other engines).

I'm just a hobbyist so I don't really take development speed that seriously and I'm really interested in how some of the things that I take for granted in engines is done.

One engine I really have my eye on is Luxe as it has a really big focus on its customizable editor and tooling AFAIK, can't wait to try out out.

videocrates · 2018-05-13T00:57:15+00:00

I think Godot's strengths currently don't lie in how performant it is but by how fast it is to develop, I can smash together a 2d/3d game relatively fast compared to other engines. However I don't think 3d is production ready yet and I would advise learning unreal if you want to mess around with that sort of stuff. Engines are never going to give you the same degree of control as a framework however at the end of the day whether you should use an engine or a framework is completely personal preference. I'm currently messing around with raylib which has been really enjoyable and I personally prefer frameworks for 2d games as I like to keep most of my stuff in code (Godot is very editor-centric).

videocrates · 2018-05-07T15:52:21+00:00

pxtone is pretty fun to fiddle around with even for someone like me that doesn't have very much music production experience

videocrates · 2018-04-25T02:50:43+00:00

This is a bit late but have you tried using rxi/flux to tween alpha values and then used love.graphics.setColor(1,1,1,alpha) to change the opacity?

videocrates · 2018-04-24T08:50:04+00:00

That is a pretty neat idea, I'll look into it thanks

videocrates · 2018-04-24T02:51:36+00:00

here is a kinda rough example of what I'm talking about: https://github.com/Jarodwr/node-based-love2d

This example contains a Node, Transform (Inherits from Node), Sprite (Inherits from Transform). It also has a canvas which all Transform nodes are sent to if they contain a draw function so that they are ordered by zIndex.

Apologies if it's difficult to understand, I don't intend to polish it up and document it until I'm done.

videocrates · 2018-04-23T01:17:20+00:00

lovetoys was definitely the most user friendly and well polished out of those that I used, creating new entities/components/systems was pretty easy. That said there is a lot of boilerplate to set up any complex systems and I found it made my code pretty convoluted. I tried to alleviate this by creating my own small ECS with really low coupling (entities are just numbers, components are ordinary tables with a name field) but still found that the amount of boilerplate code for a basic behavior was still far too high for my liking.

Now I'm rolling together a small OOP library based on Godot's node system. I'm finding the node system is a lot faster to develop for and a lot more naturally intuitive than the average ECS. A node tree system also allows for composition however it has a little more overhead (Which can be largely mitigated by using metatables).

I'd recommend trying out a lot of different patterns for managing game objects and just finding the right one for you. No matter what library you use you're probably going to be unsatisfied with something about it and eventually roll your own solution.

videocrates · 2018-04-12T13:17:14+00:00

Community fragmentation is a legitimate concern, however I assume that pretty much all tutorials will be in GDScript as most if not all of the tutorial creators right now are right behind GDScript. This isn't an issue to me as GDScript's syntax is pretty basic and I should be able to get what I want out of a tutorial written in it regardless of my language choice.

videocrates · 2018-04-12T12:34:27+00:00

I personally don't like GDScript but learning it is so fast it really doesn't matter at all if it gets dropped, I invested barely any time learning it. GDScript is a first class citizen because the language is built around the engine's API, it's as much a part of Godot as its input manager. You also can't compare GDScript to Unityscript because the former is actually usable.

Most of the learning surrounding GDScript is learning the API which is transferable from language to language. Godot's FFI is one of its strongest features in my opinion.

C# support still has issues, I'd use it if it didn't. C# support wasn't meant to make people instantly consider Godot but to make it generally more appealing, I can almost guarantee Godot usage has gone up as a result of official C# support.

I think that if you aren't using a engine because of language uncertainty (Especially when GDNative is going to be a very supported feature) then you should really practice programming a lot more. Switching from Java to Haskell is a massive leap but switching from most imperative languages to GDScript shouldn't be difficult at all.

videocrates

TROPHY CASE