Thanks just wanting to do some benchmarking on my implementation and it didn’t work so well. I have an idea of what to do now
I like the lighting system of the Game. It looks very similar to the fog of war effect in games such as Warcraft 3 and starcraft, where the obstacles block visions of your units.
I would like to ask an question here, How do you determine which tile should be lite? Do you cast rays from every light emitter in the map for checking obstacles?
Yeah, now that you mention it, it does look a lot like how fog of war would generate with a player/character was talking around and exploring. 
I don’t use any raycasting what so ever, I use a heavily modified variation of my pathfinding system. (That’s based on A*) but instead of finding a path, it does the same search pattern spreading out evenly in all directions, and every tile checked gets marked as a “light source” on a byte array by adding a light value to the tile. This also comes in handy when 2 lights overlap, because both of their light values are added together on that tile, making the light blending look pretty natural.
finally, the render loop just forloops through the byte array, and any value > 1 it knows should be lit up, and places a light there with the alpha level balanced based on what the value on that tile is.
There’s a little more complicated stuff going on too, like the closer to the center the brighter the light tile will be. But that’s the gist of it. It’s basically a lighting system based off pathfinding formulas 
[quote](That’s based on A*) but instead of finding a path, it does the same search pattern spreading out evenly in all directions
[/quote]
Wouldn’t that be equivalent to casting rays uniformly in all directions?
Wouldn’t that be equivalent to casting rays uniformly in all directions?
[/quote]
yes and no, raycasting goes straight out from the center point until it hits a wall, where as mine actually curves around walls. Bright enough lights can actually completely encapsulate an object (like a bright soft light should) where as raycasting you have to do some extra layers and blurring effects to get the same kind of effect.
Here’s an example using a really bright light, pointing out the areas where the soft light starts to wrap around;
Full size to see detail: http://sixtygig.com/junk/InDev-2014-05-27-8b.png
http://sixtygig.com/junk/InDev-2014-05-27-8b.png
Here’s another one that shows why I did it this way, allows lights to travel through passages a bit, to me, I feel it’s a tad more natural because lights usually dont just cut off hard corners… they can lightup nearby rooms not in direct paths of the light.
It probably winds up being quite similar to the effect you get with the Radiosity technique, which is pretty cool.
[quote]yes and no, raycasting goes straight out from the center point until it hits a wall, where as mine actually curves around walls. Bright enough lights can actually completely encapsulate an object (like a bright soft light should) where as raycasting you have to do some extra layers and blurring effects to get the same kind of effect.
[/quote]
I see, thanks for the detailed explanation 
It makes sense to use this approach for illuminating, having Radiosity-like effect is desirable in most cases. However I feel that ray casting is probably faster since you can pre-compute the ray path and the checking stops once you hit an obstacle.
I see, thanks for the detailed explanation It makes sense to use this approach for illuminating, having Radiosity-like effect is desirable in most cases. However I feel that ray casting is probably faster since you can pre-compute the ray path and the checking stops once you hit an obstacle.
[/quote]
Depends, I think raycasting is much faster to calculate adding/removing lights or changes in the environment, but my way doesn’t have to calculate anything at all except when a light is added or removed. When that’s not happening, there’s no calculations going on what so ever, it just renders the results in the render loop. Where as (and you guys can correct me if I’m wrong here) raycasting pretty much has to calculate some basic math all the time even in a mostly static environment.
Mine just changes the values in a large byte[][] array when it detects the need for a change, then a render loop just cycles though the array and outputs light sources all over the map.
Do you use multithreading for any thing?
I know you use it for saving
This looks nice, when do you have some kind of playable demo?
Just saving right now, I experimented with sticking my light calculations in another thread and that just blew up in my face. I probably still could, but I got the lighting calculating fast enough there’s no real need.
I may attempt to stick pathfinding in it’s own thread though, now that my game supports 512x512 maps my pathfinding (that was designed for 256x256 maps) may not be too happy about that. But we’ll see. Pathfinding doesn’t need to scan the whole map anyway, it’s just the longer the path, the more complex the calculations. Thus, with a 512x map there is the potential for needing 4x more calculating that originally anticipated. But even on the 512x map with a 2500-3000 entities the game is still running strong. So I should be fine. Won’t know more until I switch gears back to working on gameplay to find out if it had any serious adverse side effects.
I plan to release a “map editor” edition first, that should allow everyone to make maps for the game that in-theory should be 100% compatible with the actual game once it’s completed, unless I have to make serious changes to the tile engine. Don’t hold me to that though, I may have to change some fundamentals in the tile engine later that may make maps made with the current version of the Map Editor null. But if people start playing with the map editor and releasing some cool maps in this thread, I may try to make a converter of some kind to keep them around.
(EDIT: Also should be important to note that even if the map will technically load in the final game, it’ll be missing core game elements needed to play. For example, I haven’t coded the mine shafts yet, and those are planned to be the primary way to gather ores. But nothing is stopping you from reloading the game in a newer version of the editor and adding the extra parts needed. If enough people are interested in making maps I’ll probably release updated map editors as I go that have the new content.)
While the map itself isn’t exactly much to look at, here’s a shot of what I am currently working on. Full in-editor 1:1 map image exporting, allowing you to generate images of your map to show other people before they download:
(huge image, so you’ll have to click the link)
http://sixtygig.com/junk/map0Full.png
Of course, that’s not a real map. But you can imagine how it would look with a full featured map. 
Progressing on graphics some more, working on multilayered textures!
I just had an idea: Will there be siege weaponry?
Honestly not sure yet. Most of the attacks will probably involve tearing down walls rather than climbing over them, so any siege-style weapons would probably be battering rams/catapults/etc.
I’ll probably start figuring that out when I get to mobs though, as of right now there’s no reason there can’t be any. It’s just up in the air if there will be.
One more! Bringing this game to the next “level”. (har har)
Yeah, looks good.
It looks very good. How many of the buttons at the top are implemented?
Ugh I wish I was good at drawing like you are… those are some really nice graphics, very jealous of your skills!
Only the minimap button.
Most of the work has been on the left and right hand tabs (Both closed in the shot). But the top menu shouldn’t really be all that complicated. They’re all pretty basic menus.
I plan on removing the Settings button and replacing it with an Information button that has general info about the map. (Size, name, etc) Setting will be tucked under Menu.
Thanks