Making LÖVE together!

[giniu]

Hi,

We agree, then? Excellent. I was afraid you guys were going to aim for a lame fan remake of an old game, without any considerations towards what fundamental changes could improve it. I'll have to keep an eye on this, then.

There are too many ways to do things, that it's not good to remake what is already here, even if it was good there always can be something better - at least that's what I think Anyway...

True, I hadn't considered that angle. In that case, yes, it could be a decent compromise. However, there are a few more options than you may be aware of:
- Huge world, all made by hand (WoW, Morrowind) (Too much work for an indie team.)

yup, too much work - that's why I didn't mentioned it

- Small world, all made by hand (most older games) (Players may no be satisfied.)

exactly, not fun - again, that's the reason it wasn't here

- Small world with different locales, all made by hand (most games nowadays) (The method you suggest. It's a compromise between the first two.)

- Huge, procedurally-generated world (Diablo) (These tend to get boring and repetitive.)

I must say I don't like such solutions, you don't have much place for good design

Or...
- Small handmade areas on top of huge procedural world (Subversion (WIP))

I'd highly recommend considering this last method. It combines the best of each option, and modern computers have the power to pull it off. In brief, the developers make some areas by hand (say, a castle), and the game will generate everything else (the forest around the castle). The boundaries don't even need to be so clear-cut: You could put in little handmade details around in the procedural forest, like a meadow or an abandoned farm. This way you can potentially have a huge world for a lot less work than normal. Even better, procedurally-generated content won't increase the size of the game's files, since it's not stored.

I would be quite good solution too, Paul Merrell wrote PhD thesis about model synthesis (interesting read: http://www.cs.unc.edu/~pmerrell/ - procedural generation of 3D models from example artists work, he refers to some 2D solutions too and propose Blender implementation iirc). Cannot be used directly, but some ideas or references who knows. Anyway I would be worried about amount of work needed here. Artists work would be smaller, but coders work would be a LOT more complicated.

We would probably need someone dedicated for this part of project, or small team of say 2 people even. We have few people who volunteered to code, what do you think? Do we have resources to do interesting procedural wilderness from some constrains like geographical data (allowing to determine flora, fauna, terrain type, weather, etc)?

If not, we would have to stick with simpler options.

I agree also with leaving the most of the calculations to the computer, but we need to keep some, or the player will get lost and won't know how to modify his tactics. (eg: damage visualization, and maybe HP).

We will see, let's wait for focus to clear up, this is not important detail right now I think

- Small handmade areas on top of huge procedural world

I'd love to see something like this happening ... but beware! There are difficulties on this approach, too. To a degree, this is what Spelunky does (randomly generated levels that use "bigger pieces" of scenery done by hand, like temples). Some time ago Shamus Young posted how he would have used that same approach for creating Tamriel (the world in Oblivion). Then I found this other guy that I don't know (Mike Rozak) that says it is actually implemented that way (sorry, google cache, the actual page seems to be down)

Dwarf Fortress is an example of the "completely random" category, but its worlds are reasonably interesting. The cost is that you need very simple rules, but in great numbers - on that game you can literally "pierce the pancreas of an orc", so somewhere there's a group of rules specifying what happens when an orc's pancreas is pierced. With so many simple, interacting rules, interesting behaviour emerges. But it is long and tiresome to write so many!

Also, procedurally-generated worlds need a nice variety of assets in order to look good - i.e. for people you would need a big set of faces, body parts and clothes. Different kind of houses, trees, animals and floor tiles. A fine example of the sheer difficulty of creating so many assets is Dwarf Fortress itself - they overcame this problem by making it "text-mode-like".

Suggestion for creating the assets: some kind of community effort. Start with a flexible file spec, build a nice editor around it (maybe with a website), and have people contribute and rate others. Otherwise, who is going to draw 50 tsirts in 10 positions, from 4 angles?

I know, it's hard... as I understand we would use it only for wilderness that are travelled trough, most dungeons (at least those connected with quests, otherwise we can end up like Daggerfall with bunch of randomly uncompletable quests) should be premade and all assets and such should be premade. But yes, larger world means more assets to make it more interesting. I don't know. If people here will decide it's possible, we can go for it, or more exactly we will vote for it when time for question about travel view will come. If not, we should stick to smaller world or to showing only interesting parts or larger world.

[Taehl]

Also, procedurally-generated worlds need a nice variety of assets in order to look good - i.e. for people you would need a big set of faces, body parts and clothes. Different kind of houses, trees, animals and floor tiles. A fine example of the sheer difficulty of creating so many assets is Dwarf Fortress itself - they overcame this problem by making it "text-mode-like".

Suggestion for creating the assets: some kind of community effort. Start with a flexible file spec, build a nice editor around it (maybe with a website), and have people contribute and rate others. Otherwise, who is going to draw 50 tsirts in 10 positions, from 4 angles?

I'm pretty sure there are websites dedicated to gather community artwork like this, though I can't recall any names off the top of my head.

As for assets: It's not necessarily quite so bad. If you look at what Subversion is doing, you'll see that they're fractally creating their assets. So the city is generated, using generated streets growing around generated buildings, which have generated floorplans, which (will have) generated furniture... Granted, this is prolly too much for us to pull off, so we'll need something less ambitious, but I think the fractal approach, on a less grand scale, may be an option.

As for the code of procedurally generating terrain, don't worry overmuch, such things aren't extremely hard to do. For example, this is the code I use to generate procedural terrain in PPT:

Code: Select all

-- Returns the closest multiple of size (defaulting to game.grid)
math.grid = function(n, size) size = size or game.grid return math.round(n/size)*size end
-- Randomly returns either -1 or 1
math.rsign = function() return math.random(0,1)*2-1 end

function love.load()
	math.randomseed(31337)									-- This number changes the randomization of the world
	local edge = 1200										-- The size of the empty border, in pixels
	game.grid, game.x, game.y = 30, 3600+edge, 3600+edge			-- 3600 is pretty big.

	local function grow(x, y, limit, iteration)
		iteration = (iteration or 0) + 1
		addtile(x, y)
		if math.rsign() == 1 then x = x + math.rsign()*game.grid
		else y = y + math.rsign()*game.grid end
		if iteration < limit then grow(x, y, limit, iteration) end		-- Yay recursion!
	end

	for i = 1, 320 do
		local x = math.grid(math.random(edge,game.x-edge))
		local y = math.grid(math.random(edge,game.y-edge))
		grow(x, y, 10)										-- 320*10 = up to 3200 tiles
	end
end

-- Adds a static tile.
function addtile( x, y )
	if tiles[x] then if tiles[x][y] then return false end end				-- Don't overlap tiles
	local t = {}
	t.x, t.y = x, y
	t.b = ground
	t.s = love.physics.newRectangleShape(t.b, x, y, game.grid, game.grid)
	t.i = image("block")
	t.ox, t.oy = 16, 16
	t.sx, t.sy = (game.grid+2)/32, (game.grid+2)/32
	t.r = (math.random(0,4)*math.halfpi) + (math.random(-5,10)^4/40000 * math.rsign())
	t.s:setData(t)
	if not tiles[x] then tiles[x] = {} end
	tiles[x][y] = t
end

This may not be very advanced, but it does give a rather organic, pleasing layout. As you can see, procedural code can be pretty easy. With a bit of tweaking (changing its behavior and the tileset), you could make that grow() function into something dedicated to, say, making cliffs, or swamp brush, or city streets.

[giniu]

Next question/poll is coming soon, last chance to vote for setting next one will be about 3 key gameplay elements

[napco]

Ok, we have the first poll result... The setting of the game will be...
STEAMPUNK, with 9 votes!

EDIT: By the way, i've voted "world interactions" instead of "story" in the second poll, so we'll subtract one vote from it and add to story when we'll have to decide!

[giniu]

Maybe we should chat a bit about hosting of project? My current go would be http://codaset.com/ - it's one of 6 recommended on git-scm.com, and one with very attractive features, looks like best from 4 that host public, open source projects. It offers Wiki, Blog, Tickets, Milestones, Code browser, Activity tracker, Community Network, interface to authentication trough SSH keys and more. Check how looks quite active project: http://codaset.com/codaset/codaset - check all the features on top, like milestones: http://codaset.com/codaset/codaset/mile ... ublic-beta. This single project is with private repo, but that's how repo browser looks like: http://codaset.com/codaset/git-chart/source. The service is currently at beta, and free for everyone (also closed projects) but is promised to stay free for open source when it leaves beta. That's my idea, I think it would be really good tool for this projects, even could be classified as best tool for the job. So how about it? Are we creating project with them or looking for other solutions? If we go with it I could manage the project page I think, at least for few first few weeks when we will setup things, as I have some experience with it already.

PS.: as codaset demonstrations I picked projects owned by page maintainers, so officially hosted there, they use their own tool to manage it's development, neat

[qubodup]

It warms my heart to see "realism" have zero points

It is a rather nice poll (good selection of answers) don't mind me saying so.

[Taehl]

Hear, hear.

Also, it's nice to see exploration and character interaction so highly voted. Most RPGs tend to totally overlook them! Those are the number 1 and 2 reasons that I still play Morrowind, after all these years.

[osuf oboys]

I like this community project but right now it sounds more like grand dreams that will most likely run into the sand (as such projects, even starting much closer to the finish line, tend to do). How about making a 5-minute RPG before setting out to make "the grandest RPG ever made".

Alternativly, one could work hierarchically: making a game (/writing a story) constrained in size, or at least the important hand-made parts of it, and increasing the length. One could start with a single scene that captures the essence of the story and iteratively, say, double or triple the length, eventually adding optional side quests for those players that enjoy side tours. In the end, things would have taken at most twice the time (for doubling) or 50% longer (for tripling), but probably resulting in a much more well-made game. You will also always have an end-product, even if you choose to abandon the project. My experiences with prototyping in programming also indicates that this makes you work out the most important features properly and gets rid of most of the backtracking, which can be very time consuming.

I believe this project would benefit the community a lot more if the underlying RPG engine and the RPG story were made into separate projects developed in parallel. A lot of people have attempted RPGs in LÖVE and worked to a great deal on those elements largely common in RPGs, in one form or another.

I can assist with the procedural generation if you need that. What kind of generated content are you looking for besides maps? One design choice is if the procedural generation should be run first and content added afterwards (much easier) or the content requirements first and generation around that (more powerful, less static, (uses less space)). E.g. first generating the world and editing the tiles to add, say, houses, versus being able to say where houses should be and adding the world around them in a consistent manner.

[Robin]

I like this community project but right now it sounds more like grand dreams that will most likely run into the sand (as such projects, even starting much closer to the finish line, tend to do). How about making a 5-minute RPG before setting out to make "the grandest RPG ever made".

I agree. I have been watching this thread, and it's really nice to see people so enthusiastic. But try to keep it real, or you only set up to disappoint yourselves. If/when you produce something playable, you can count on me to test it (and most likely to report bugs as well).

And one final advice: forget what I said about keeping it real. Overly optimistic and ambitious dreams are half the fun of projects like this!

[giniu]

I like this community project but right now it sounds more like grand dreams that will most likely run into the sand (as such projects, even starting much closer to the finish line, tend to do). How about making a 5-minute RPG before setting out to make "the grandest RPG ever made".

Those questions about design are not asked to make it all straight away, I know it's impossible and we need to start low and climb higher (somewhere before I said, that after about week from last post we would start with first prototype, and that would be small portion of functionality, then we would incrementally build on it), but also we need good design of overall end-product, otherwise we can come up with game that maybe not looks like, or doesn't hear like, but feels like made from unrelated blocks, just tied together, not being singularity by itself. Most of community projects that live enough to be finished ends up like this, exactly because of lack of good gameplay design. To create gameplay that sticks together and bring in some innovation, we need to have the "great picture" to look at, and it needs to be voted and published as 1-2 page document in case of community projects, so that all can look at it any time, and would know what we are doing and would get more consistent idea, clearer picture We cannot allow for half of people to think that fights are most important and other half to think that exploration is most important, or they would be creating 2 different games - and we need to make single game.

So in short - the 10 questions we are dealing with here, are just to catch the vision and make it consistent, and rest of work would start low and build from there. So worry not, I know what we are doing and I'm doing my best to keep the project on right track

Alternativly, one could work hierarchically: making a game (/writing a story) constrained in size, or at least the important hand-made parts of it, and increasing the length. One could start with a single scene that captures the essence of the story and iteratively, say, double or triple the length, eventually adding optional side quests for those players that enjoy side tours. In the end, things would have taken at most twice the time (for doubling) or 50% longer (for tripling), but probably resulting in a much more well-made game. You will also always have an end-product, even if you choose to abandon the project. My experiences with prototyping in programming also indicates that this makes you work out the most important features properly and gets rid of most of the backtracking, which can be very time consuming.

I believe this project would benefit the community a lot more if the underlying RPG engine and the RPG story were made into separate projects developed in parallel. A lot of people have attempted RPGs in LÖVE and worked to a great deal on those elements largely common in RPGs, in one form or another.

I agree with most of this, maybe just not that about making small portion of story first. First there should be small portions of gameplay - not story, and they should be tested well. I think I wrote about prototype approach I'd like to bite here also, this is very good approach and I also have experiences with it. If I wasn't writing about it in this topic, it was for sure mentioned in PM talks with napco during talking over current polls. Also I think I wrote about splitting the team after focus document and final prototype is made, something that then there would be engine work and when it ends there should be also story and art made. I meant that it would be done in parallel.

But the split if it should occur should occur when the gameplay is set, and to set gameplay all ideas must be tested with prototypes. If story (anything more than backstory or general sketch) is made before designing gameplay ends, it can result in pretty badly made game, that don't use some gameplay features and overuses some others, you also cannot plan well the learning curve and integrate it with story when you don't know all the gameplay that will end in it - and this is never good

I can assist with the procedural generation if you need that. What kind of generated content are you looking for besides maps? One design choice is if the procedural generation should be run first and content added afterwards (much easier) or the content requirements first and generation around that (more powerful, less static, (uses less space)). E.g. first generating the world and editing the tiles to add, say, houses, versus being able to say where houses should be and adding the world around them in a consistent manner.

Thanks for your offer, if we decide to do it, it would be sweet to have you on our side with it But to be honest, I don't know yet if we will do it. Question about this is planned in about one or two sessions, we would propose few solutions and see what will be picked by most people, that way we will make what most people wants. I wouldn't want to work on project with 20 other people where we would make one mans vision, so we should make vision of majority I think and that way all would be happy to help with it.

Anyway if we go with generated maps I was thinking about (as one of possible solutions) something like:

1) we divide the world into squares, each square can be either made/modified by artist or generated
2) cities and small area around them (say 2-5 squares each side) would be made/modified by artist
3) rest of space would be given as map, with roads, rivers, bridges, geographical data marked in some simple manner (one bit for water, one for road/bridge, and 6 for height map? Height can determine type of fauna and flora, and which parts are accessible and which not - for example more than one in difference in height makes it inaccessible. - don't know and actually I shouldn't decide about this, as I don't know too much about this. This is just technical detail, from point of view of gameplay design I don't care )
4) the space would be populated along the set rules from map and modifications from artist, it should be made always with same seed I think, otherwise we couldn't integrate artist-made parts with generated parts unless we use something advanced to constrain generated maps to fit well with artist made blocks - but that's as you said harder.
5) from gameplay perspective we give ability to fast-travel by roads from end of artist generated maps, with random fights if ambushed, but travel by foot should also be possible, and desired as not all locations would be connected by fast-travel-system
6) we should give chance for the city to grow, people should be able to do mods that occupy some unoccupied squares.

And - if we do it that we first generate world then add artist blocks, or other way round, I think that it's rather cosmetic for gameplay and that's what we work on for now. From the two we should pick one that will be preferred by artists and be possible to implement in finite amount of time

I like this community project but right now it sounds more like grand dreams that will most likely run into the sand (as such projects, even starting much closer to the finish line, tend to do). How about making a 5-minute RPG before setting out to make "the grandest RPG ever made".

I agree. I have been watching this thread, and it's really nice to see people so enthusiastic. But try to keep it real, or you only set up to disappoint yourselves. If/when you produce something playable, you can count on me to test it (and most likely to report bugs as well).

And one final advice: forget what I said about keeping it real. Overly optimistic and ambitious dreams are half the fun of projects like this!

This project in my opinion is real I know our limitations and that's why I was against large artist made world or full voice over, for smaller areas or some other solutions and no voice-over at all, unless we find separate team that will be willing to do it later - I'm also against many other things that just didn't came up yet. Now I'm just making sure we all work on same project and have it before eyes, because we cannot afford to let ideas diverge and rework them later, we don't have time for it, so we spend some time on preparations. In my opinion doing it well is only way community project can be finished and made well, it's known that "Poor People Can't Afford to Buy Cheap" - I might be mistaken, but better safe than sorry