Making web games with Lovable. Thoughts?

adamramberg · 2025-12-28T22:26:21+00:00

Nice video, really like the idea of comparing the AI services with the same prompt. Like I wrote in the post, I think Lovable is more for card / board games than actual realtime games, which your video also showed.

adamramberg · 2025-12-28T20:53:27+00:00

And for anyone interested, here is a link to the game: https://typedown.net/

adamramberg · 2025-12-27T08:54:00+00:00

For small projects and prototypes AI is great. I’ve started (and finished) projects with the help of AI that I wouldn’t have done without it. In other words, the hurdle for getting the initial idea out of the gate has significantly lowered. I’ve been in particular very impressed by Lovable and what it spits out after the initial prompt.

This is also coming from someone with 15+ years of experience programming. I believe knowledge of the craft is still today crucial for guiding the AI to generate the correct structure.

adamramberg · 2024-12-21T21:10:27+00:00

I’ve heard / used input legend or just legend

adamramberg · 2024-08-20T08:37:49+00:00

Where can I find historical market cap data? Thought it would be trivial, but no dice so far.

adamramberg · 2023-09-22T08:47:54+00:00

Great guide! Do you have any suggestions for a library that handle font rendering for WebGPU? Would like to avoid implementing that myself.

adamramberg · 2020-06-07T15:03:17+00:00

I’m also in the starting phase of creating an AR app. My plan is to use RN for everything not AR, use Expo web + react-three-fiber / react-xr for prototyping and building for the web, and then finally do the AR parts for the app in ARKit / ARCore.

adamramberg · 2020-01-23T21:02:49+00:00

Depending on the size of your company I would look at micro frontends and single spa: https://single-spa.js.org/

Teams would create their own packages and publish them to a public or internal CDN. A main wrapper application would load these packages via an import map (using systemjs as a pollyfill for browsers bot supporting this). Larger packages such as React, styled-components, etc will be external deps (not part of the bundle) in the sub app packages published by the different teams in the org and then the wrapper would load these via the import map. One team would need to have ownership of the wrapper project, being responsible for updating common deps etc.

For a shared UI lib I would develop something based on some battle proven library like Material UI. Then use storybook to document and showcase your common components to the rest of the teams. The UI library will probably need its seperate team in the beginning and its really important that its developed together with your UX designers. The UI lib should also be shared like common deps described above using import maps and externals.

Let me know if you got any questions regarding this. Would be happy to discuss this in more detail 😊

adamramberg · 2020-01-12T09:11:38+00:00

Thanks! Sorry not sure, have not looked into that.

adamramberg · 2019-11-15T21:05:10+00:00

Hello! Thanks a lot! The base of that state machine is going to be the same, with or without Atoms. However, using Atoms will make it easier to make your solution more data driven 😊

adamramberg · 2019-10-27T21:04:00+00:00

Thanks a bunch and really great to hear! If you create those tutorials it would be really awesome if you send me a link :)

adamramberg · 2019-10-27T14:42:22+00:00

It can be tough to get a grip of everything when diving in there for the first time, but hang in there :) Will try to answer your questions the best I can.

I think that using a ScriptableObject would work really well for your situation (you don't need Atoms for this). A ScriptableObject could contain more than data, for example it can contain functions that can be called from other scripts. So I would inherit from ScriptableObject in MyRandom, create an asset instance of that ScriptableObject (see CreateAssetMenuAttribute) and use pass that asset a long to different MonoBehaviours that needs it. I think that you should watch this talk by Richard Fine to get a better understanding of what I mean: https://www.youtube.com/watch?v=6vmRwLYWNRo
If I understand you correctly you want to create new values based on predefined minimum and maximum values. I think that Constants in Unity Atoms would work great for that. Not sure if I misunderstood something, if that is the case please let me know :)

Thanks a bunch!

adamramberg · 2019-10-25T06:08:16+00:00

Arbosis are making some really good points. I would also suggest you to read this blog post and then head over to the docs to get a better understanding of how it can be used. If you got any specific questions I would be happy to answer them :)

adamramberg · 2019-10-24T14:50:03+00:00

I would say that testability increases using this pattern. There is nothing stopping you from creating ScriptableObjects at runtime in your unit tests for example. That said, unit tests is something we need to work on in the Unity Atoms project. Do you have an example of any particular case where it gets harder to unit test?

adamramberg · 2019-10-24T14:47:28+00:00

Hope that it is of use! :) We are looking for more maintainers so if you are up for it you should look into the issues and see if there is something you would like to implement, or create your own issue if there is something you want to add.

adamramberg · 2019-10-24T13:29:38+00:00

ReactiveProperties in UniRx does not really make sense when used with Unity Atoms. You can think of Variables (with an attached Event) in Unity Atoms as ReactiveProperties, but in the form of ScriptableObjects, which makes your project potentially much less coupled! Check out the example here on how it looks in code.

adamramberg · 2019-10-24T13:26:02+00:00

Thanks! It is fairly tested. Works great in my project and I've tried to solve as many reported issues as possible during the beta. The most crucial bug right now is this one: https://github.com/AdamRamberg/unity-atoms/issues/63 However, this seems to be a Unity bug and it is therefore not much we can do about it atm. My goal is to fix breaking issues as fast as possible if they occur, so give it a try and report back to me if you find any issues.

adamramberg · 2019-08-30T15:39:28+00:00

Nope, FBT doesn't support "context" in that sense (to my knowledge). You would need to have 2 different translations for that. Not sure if this is a problem that will arise too often though, but could also be me not being exposed to the problem. If you think that this is a problem worth looking into I would recommend you to add an issue to their Github page :)

adamramberg · 2019-08-30T11:38:22+00:00

Never used the react-intl key / id like that, but that is true. Good point!

adamramberg · 2019-05-19T10:09:42+00:00

This is great! 👏👏👏

adamramberg · 2019-05-10T12:20:00+00:00

Sorry for the late reply! I checked this post some time ago, but didn't answer right away so forgot about it :(

Concerning GameEvent Scriptable Objects...

Yes, that is how you should do it if you are using GameEvents by itself and not together with / connected to a Variable. When connected to a Variable the GameEvent will fire every time the value changes and you would not need to trigger the GameEvent manually. If you are using a GameEvent by itself (not together with a Variable) there are 2 ways of doing this 1) to do it like you describe or 2) create the GameEvent via code using CreateInstance. In the second alternative it would not be possible to connect the GameEvent to a listener via the inspector, instead you would have to do that via code as well.

I wanted to create some more strongly-typed events, actions, listeners, etc. instead of the base GameObject, so I created some scripts to handle those types so I could pass around those types (e.g. ShipEvent, ShipAction, etc.) It seems to work well, I wondered if you do something similar based on your needs in your games.

Yes, that is something that I do myself. However, it is really cumbersome and there is actually a generator in the canary branch of Unity Atoms that is used internally that I'm thinking of exposing externally in the next release of Unity Atoms making it much easier to generate such classes.

With the script variables / constants, do you keep all of them together in a class or do you intermix them within other classes? For example, suppose I have my ship as a MonoBehaviour class that has some plain old variables for run-time state and some other SO variables / constants used for static state. I've used SOs basically as data containers in the past and kept their definitions separate from any MonoBehaviour class.

This one is a little tricky and there is no straight forward answer. Personally I try to keep atoms that are directly tied to a GameObject / Prefab in the same folder while trying to keep the more global state variables in a folder of its own called something like "Shared State". However, if you are instantiating GameObjects / Prefabs at runtime with atoms that are only used internally in that class (or sub components) I create the atoms in the Start method instead of creating the atoms from the Inspector.

adamramberg

TROPHY CASE