The dream is just beginning. This is the first ever Love in Verses podcast. For each episode, we're gonna talk to Eskil about the game, bugs, new ideas, and random fun poking :)
You can subscribe in iTunes or manually subscribe to the podcast feed with alternative podcasting applications..
Optionally, you can either download it directly or listen to it right here:
This episode stars Samakon, Feneer, Genubon and of course Eskil and lasts for a whopping 51 minutes. More episodes are to come, and don't forget to leave a comment with your feedback.
Credit: goes to Samakon for the mad editing skillz and Rastabon for super awesome leveling and technical website stuff.
Intro music: Queen - Play the Game
- Login or register to post comments
- Download the MP3
Good music choice! (Queen is
Good music choice! (Queen is wonderful).
My only criticisms are:
1.) The podcast seems a bit to unfocused and in-jokey at times. While I know my fellow Love players as a really friendly bunch, we seem a bit too focused on the monitor lizards to be accessible to timid newbies without potentially confusing or intimidating the shit out of them. ;P
2.) I'm incredibly surprised that Eskil doesn't really have the mining combination system more throughly thought out. I'm not saying that having a Love design "bible" written should be a needed step, but it's probably not wise to just say "You can mine these minerals and mixing these minerals would have cool effects, which I haven't really thought out at all" and then start coding the mixing system and the potential minerals to mine and mix. Ideally, one should probably play around with the properties of potential combinations before going through the trouble of implementing the system of mixing them.
As a suggestion though, I'd say that mineral combinations should probably yield a material that, while it has properties directly traceable to its composition's percieved properties, it doesn't get fixed properties directly from the minerals comprising the combo. I'll word it another way just in case I worded it weirdly or confusingly: the materials themselves have no intrinsic properties to pass onto any combinations made with it. That way, you can tweak the outcomes of the mixing individually instead of relying on the minerals themselves to carry the properties (and nip in the bud the potential of having to manage a combinatronic explosion).
(Oh gawd, words. I really don't know how to word that simply)
It is interesting listening
It is interesting listening to this in comparison to the Dwarf Fortress podcasts.
I agree that the podcast feels a little unfocused, and perhaps you were a little distracted from playing Love at the same time. It was nice to get an idea of where Eskil is heading with the upgrade system though.
Regarding the Love World Viewer
- It doesn't actually use 7zip/LZMA. I've checked it out a couple of times, but the .Net libraries for it are slow and crashy. I could switch to a normal dll, but I wouldn't be able use it with the web version (and would need to purchase a Unity Pro license). Instead I'm using plain zip compression.
- To get a system going where the world is updated regularly on a website, it would be a matter of:
* Eskil creating a commandline argument for Love that causes it to simply grab the state of a server and write out the world files.
* Me creating a commandline utility to convert it to *.lwf format
* Uploading that *.lwf file to a server alongside the web viewer.
* Someone automating this process and hosting the web viewer
lwf files are ~15-25MB depending on world complexity at the moment.
- While I probably couldn't use the 300KB definition to simply render the world, that metadata would be useful for identifying structures and such. At the moment I can't add artillery range display or similar gadgets because I can't identify artillery tokens without writing some sort of image recognition AI.
Of course, that metadata is probably subject to a bit of change over time, while obj files are just obj files. I don't really want to have to release a new version of the viewer every time Eskil updates the client (although I still do when the world texture changes).
It would be nice if the mesh information could be exported as a binary file of some type, rather (or in addition to) obj - would be smaller to start with, and quicker to load.