Eufloria > Eufloria Classic
Future
Alex:
--- Quote from: annikk.exe on August 04, 2011, 01:53:52 AM ---Ok, actually... I have a few questions about modding in the new version...
Will it be possible to make custom levels in the new version? (however basic they may be)
Will levels still be written in lua?
Can you give some examples of commands that are unlikely to be supported? Will DrawSprite still work? What about Asteroid:MoveTo and MoveBy?
Though you did say you don't want to spend the rest of your days adding modding features, do you have any plans to eventually add commands that level designers can use? Or is that it - what comes in the final release is all we'll ever have?
Just to reiterate that I want to make levels for the latest version of Eufloria, pretty much regardless of any restrictions. The open source idea sounds cool but I am mainly interested in making levels for the version of the game that will be played by thousands of people. :>
--- End quote ---
> Will it be possible to make custom levels in the new version? (however basic they may be)
Yes.
> Will levels still be written in lua?
Yep.
> Can you give some examples of commands that are unlikely to be supported? Will DrawSprite still work? What about Asteroid:MoveTo and MoveBy?
Currently anything that's in the basic campaign works. Pretty much everything else is unsupported. Whether or not things end up being supported is up for discussion as it will take time to do that (bear in mind that it would also take some time to clean up, strip down and release Eufloria Classic or whatever it would end up being called).
> Though you did say you don't want to spend the rest of your days adding modding features, do you have any plans to eventually add commands that level designers can use? Or is that it - what comes in the final release is all we'll ever have?
No, the game will doubtless need patch after bloody patch to support people who have esoteric or even common hardware configurations and fix bugs. Extra features could get worked into these patches. I am happy to come back and add features, but I don't want to be doing it to the point where I'm, say, spending a day a week on it. I wanted to get the game roughly to the point where all existing levels would run (if not by simply loading them, then by modifying the syntax appropriately).
My thinking was that there's a lot of stuff people want to do that I'd never have time to do. And if the game were modifiable in a more open sense (i.e. source code available) then people could do that independently of me. Additionally there's an existing version of the game in which all these levels currently work.
I totally see your point about working in the current version and actually I think that's a really important issue both for you guys and for us. In the long term it will probably be better to have a reasonably modifiable version out and ditch the idea of the free classic version.
Pilchard123:
How about keeping the moddable version as a free download (possibly only for those that have bought the game), until either a set time runs out or you have copied all/most of the Lua commands to the new one.
Y'know, I'm fairly sure that we'd write the bindings if you gave us a rough guide to how to do them - I'm almost certain that I would. This community has plenty of people with too much time on their hands a love for this game and who would be willing to help.
annikk.exe:
--- Quote ---> Will it be possible to make custom levels in the new version? (however basic they may be)
Yes.
> Will levels still be written in lua?
Yep.
--- End quote ---
w00t !
--- Quote ---> Can you give some examples of commands that are unlikely to be supported? Will DrawSprite still work? What about Asteroid:MoveTo and MoveBy?
Currently anything that's in the basic campaign works. Pretty much everything else is unsupported. Whether or not things end up being supported is up for discussion as it will take time to do that (bear in mind that it would also take some time to clean up, strip down and release Eufloria Classic or whatever it would end up being called).
--- End quote ---
I'm totally stoked that you're up for discussing what gets implemented. :> I am of course eager to get started! When/where should this discussion take place? Would it be helpful if we level designers create a prioritised list of things we most want implemented, so that you can see easily what people are trying to do? Is there anything else we can do to help?
Though I shall greatly look forward to the patches, I will also begin creating content the moment the new version is released. I will aim to have a new level out the same day the new version of the game is released on PC. :>
--- Quote ---> Though you did say you don't want to spend the rest of your days adding modding features, do you have any plans to eventually add commands that level designers can use? Or is that it - what comes in the final release is all we'll ever have?
No, the game will doubtless need patch after bloody patch to support people who have esoteric or even common hardware configurations and fix bugs. Extra features could get worked into these patches. I am happy to come back and add features, but I don't want to be doing it to the point where I'm, say, spending a day a week on it. I wanted to get the game roughly to the point where all existing levels would run (if not by simply loading them, then by modifying the syntax appropriately).
--- End quote ---
I am totally fine with modifying old levels and engines to fit whatever the new syntax is. :> When you say you want to get to the point where all existing levels would run, do you mean all the existing levels that have been created by the level designers, or the levels for the original game?
--- Quote ---My thinking was that there's a lot of stuff people want to do that I'd never have time to do. And if the game were modifiable in a more open sense (i.e. source code available) then people could do that independently of me. Additionally there's an existing version of the game in which all these levels currently work.
--- End quote ---
The thing is, that would involve splitting your time between two Eufloria projects instead of just focusing on one. Sure, there are restrictions with what we can do, and it might be possible to change those things if it were open source.... but who would change the code? Who would play the resulting maps? I guess I'm just skeptical about how much an open source version would be advertised, downloaded, and played. It's not as exciting an arena to work in if it's not actively being played by thousands of people all over the world..
For me, coding is only half the pleasure... the other half is seeing the download counter tick up, and reading the feedback from people who have played it. People are much more likely to play the latest and greatest version, so that is where I want to be. :>
Besides, there really haven't been that many requests for new commands. Some of the previous requests are no longer relevant because we have found workarounds for them, or discovered undocumented commands that have the functionality we were looking for. Personally, when I ask about the existence (or not) of a particular command, I am just asking because I am curious if it exists... it's not intended to be read as "implement this command for me!". The only unfulfilled request I can remember is for the ability to draw sprites behind asteroids as well as in front of them, but that's hardly a huge issue because there is a workaround for it (albeit an inefficient one).
--- Quote ---I totally see your point about working in the current version and actually I think that's a really important issue both for you guys and for us. In the long term it will probably be better to have a reasonably modifiable version out and ditch the idea of the free classic version.
--- End quote ---
I hope you decide to do this.. :> I think it's the best option for us Level Designers, for you guys, and for the people that play the game. I love the look of the new version, it's totally stunning and I can't wait to play it. :> heh, I'm totally bubbling over with enthusiasm right now... though I'm conscious of not wanting to crowd you after your epic coding session over these past months.
Pilchard123:
This looks like a fairly good binding thing, and it seems fairly simple to implement, too. It also looks a lot easier to use than the stuff you posted a while back.
http://code.google.com/p/slb/
http://code.google.com/p/slb/source/browse/SLB_101.wiki?repo=wiki
http://code.google.com/p/slb/source/browse/examples/
EDIT: I don't think the levels would need rewriting after all.
Aino:
I hope it's not hard to add features D:
If it is, it must be like slavery for you, unless you wanna add it yourself :P
Maybe we can make a list over functions that won't be able to be used, so we see what we loses, and probably it can be added one by one later(Alex told that mostly the things in the campaign will work, but is the campaign exactly the same + some features?) :)
(or is that idea just dumb?)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version