Vapourware Codexian Game Development Thread

[Destroid]

Also, the song you made for your kickstarter video/barkley 2 was very good cboyardee.

 

[DakaSha]

Development of my roguelike project is going extremely well. I think i have roughly 80% of the core engine architecture finished. Feels good to have something resembling the vague outline a game for once.

 

[DakaSha]

So this is what i have managed to throw together in the past week. I'm not paying any attention to aesthetics yet so it doesn't look to hot. Also using a bitmapfont i got from the dwarf fortress font repository so i have that stupid face instead of a proper @ which will be changed.

Light looks better in actual game. Recording made it blocky as shit. Still doesnt look 'good' though. Not really important. Main thing is my overall design does what its suppose to. I think the next thing I'm going to do is add different lighting effects so that i can make the teleporter lights pulse instead of flicker

Not to exciting but meh. Closest I've got to a game so far so ill take it. I'm also pretty happy with what the engine can do already (Map is not randomly generated yet btw. It's just pre-made)

 

[shihonage]

Looks quite impressive. You may want to start early about implementing graphics into that if you want to sell it. It's a mistake I made with Dead Colony, which remained ASCII for a very long time, and inserting graphics into that framework became a nightmare later on - not because of inability to display them, but, uh... hard to explain. It's just that ASCII display mentality is different and creates different coding expectations.

 

[DakaSha]

Thanks.
I've done plenty of graphics programming. I understand the differences, but i dont plan on selling this. The whole reason im doing an ascii roguelike is because school demands to much of my time and attention. This is just a hobby.

If i ever did finish it and decided to release a commercial version then i still dont think it would be 'to much' of an issue to convert to 2d tiles. I think my game logic and graphics logic is pretty seperated.

 

[barker_s]

Instead of working on my dungeon generator, I decided to rip some Xenomorph models from A:CM and AvP2 and use them (actually just A:CM one, since it's prettier and I was able to extract its animations) in a little project that will probably get Foxed.

 

[DakaSha]

Added an effects function for display objects, allowing me to animate/modify them however I want. Fleshed out lighting system. Lights can basically be attached to anything, items, entities, tiles, whatever. Different types of light effects possible with varying brightness. Think glowing swords or something lighting up a room (and making your ass visible to the enemy)

Recording fucks up the colors so again it looks like shit but meh.

Also, although i have orcs in the video I actually plan on turning this into sci-fi survival horror (although with fantasy elements)

 

[DakaSha]

There has been a problem with this since i first started working with the light and now that its time to address it, i'm finding it's a lot more difficult then i had hoped. (Or I'm just a lot more dense then I'd like to admit)

The lights illuminate the walls, but this means they also illuminate them form the 'other side' relative to the player. Thats obviously bs and looks retarded (and also mechanically shit). I was hoping i could come up with some kind of logic to make this not happen, but all i can come up with are workarounds that id rather not implement.

If any logical bros have any ideas let me know. My implementation shouldnt matter to much I think

edit:

@ being where the player is and L where the light is. The walls in the middle shouldnt be lit of course
Again i dont think my implementation should matter to much up till this point. If there is a logical/mathematical process that can decide on whether the wall should be lit at that time then i should easily be able to implement it.
I can't shake the feeling that i should somehow be able to perform some kind of measurements between the player, wall and light, to discern whether or not the tile should be lit. Maybe it's also just fundamentally impossible, in which case I can at least start thinking about the best workaround

edit again: whoops the light is one cell over to the right.. whatever. I think its clear what the problem is

 

[shihonage]

This is probably the easiest solution:

1) Make your dungeon generator ensure that there is no block of wall anywhere that is smaller in size than 2x2.
2) Make sure that game entities (player, monsters) take up 2x2 blocks themselves.
3) Expand map size to 2x of what it is on both axis.
4) Leave lighting routines operating as they are now.

 

[DakaSha]

This is probably the easiest solution:

1) Make your dungeon generator ensure that there is no block of wall anywhere that is smaller in size than 2x2.
2) Make sure that game entities (player, monsters) take up 2x2 blocks themselves.
3) Expand map size to 2x of what it is on both axis.
4) Leave lighting routines operating as they are now.

Well one of my workarounds is similar to this, although it would be to have the walls of thickness 3 without increasing entities size. The 'lucky' thing is that it actually may benefit me game design wise (meaning regardless if i can come up with a mathematical approach to destroying this problem or not, i may still implement the walls of 3 thickness).

Keep in mind this is staying ascii so increasing the size of entities isnt really an option.

Thanks for the input. Any further ideas are appreciated

 

[shihonage]

You tied yourself to console's "real" ASCII?

That is unfortunate because Vista and up disabled the authentic ASCII experience (fullscreen, direct to video B800:0000 memory), thus the ASCII you're doing is just graphically emulated anyway.

 

[DakaSha]

You tied yourself to console's "real" ASCII?

That is unfortunate because Vista and up disabled the authentic ASCII experience (fullscreen, direct to video B800:0000 memory), thus the ASCII you're doing is just graphically emulated anyway.

I never claimed otherwise? That doesn't keep me from using ascii characters, thus being tied to the constraints of ascii

edit: I'm using libtcod which, as you said, emulates a console, with the same constraints of a console (other than better color manipulation and being able to draw to a type of off screen buffer). Ascii is a choice. not something i feel pressured into using

 

[Niektory]

Hmm, maybe you can fragment the walls while still rendering them as one character, by making the displayed brightness an average of sub-blocks visible from the direction the player is looking from. Not sure if the effect would look good in motion but I think it's worth a try.

 

[DakaSha]

Hmm, maybe you can fragment the walls while still rendering them as one character, by making the displayed brightness an average of sub-blocks visible from the direction the player is looking from. Not sure if the effect would look good in motion but I think it's worth a try.

Again, I'm using an emulated console so I can't really fragment anything, apart from making a wall a minimum of 2 thick (Which I think would be equivalent of what you are suggesting).

What I'm wondering is if I can do this without 'cheating'. Somehow elegantly calculate whether the tile is blocking the light from the reference point of the player or not.
This is where better math skills would come in handy

 

[DakaSha]

Here is how i imagine walls of 3 thickness benefiting me:

Since I plan on having this be a Alienesque, The idea of air ducts etc is really appealing (Shit jumping out at you in the dark would be cool). When the player enters an air duct it would be easy to make all lights stop illuminating walls, so that the air ducts walls wouldnt be illuminated from the outside. also since this is a space station type setting it would make sense for the thing to be built with a bunch of modules, connected by pressure locks

It still doesn't address the actual issue (and i might not continue until i do adress it, if possible), but at least I feel I have a decent workaround. That is, until something else creeps up.. sigh

 

[Destroid]

Best I can think of is tagging which side of the wall tile is lit, then checking that the player can also see that side. Sounds like a real pain.

 

[Niektory]

Hmm, maybe you can fragment the walls while still rendering them as one character, by making the displayed brightness an average of sub-blocks visible from the direction the player is looking from. Not sure if the effect would look good in motion but I think it's worth a try.

Again, I'm using an emulated console so I can't really fragment anything, apart from making a wall a minimum of 2 thick (Which I think would be equivalent of what you are suggesting).

I meant fragmenting the walls in memory just for the purpose of light calculation while keeping the visual representation non-fragmented. I may have worded it poorly, I'm basically suggesting the same thing as Destroid.

What I'm wondering is if I can do this without 'cheating'. Somehow elegantly calculate whether the tile is blocking the light from the reference point of the player or not.
This is where better math skills would come in handy

I don't think there's an easy way out of this. Computer game graphics are full of hacks, embrace them.

You tied yourself to console's "real" ASCII?

That is unfortunate because Vista and up disabled the authentic ASCII experience (fullscreen, direct to video B800:0000 memory), thus the ASCII you're doing is just graphically emulated anyway.

You can still enjoy it in its full glory on Linux.

 

[DakaSha]

Oh i see. Yeah I'll think of something like that.

And just because game graphics are traditionally programmed with a bunch of hacks, it doesnt mean they necessarily always have to be. Games are also full of bugs

 

[Destroid]

DakaSha I asked around in #rgrd on quakenet where a lot of RL devs and jday provided some suggestions from work on Brogue:

<jday> You iterate over your lights, adding their effect to cells; if the cell you're adding it to blocks light, and if the player is on the other side of it from the light (you can do the dot product or just compare which quadrant they're in), then you don't apply it.
<jday> Also, I can't tell much from that image, but make sure that (1) neither lights nor cells ever have 0 in any of r, g, or b, and (2) that values greater than 100% are supported, and only clipped when it comes time to draw them.
<jday> Also remember that you don't have to (or really even want to) follow the physical formulas for luminosity, because if you're not also taking indirect illumination and angle of incidence, and all kinds of other stuff, into account, it's not the "real" formula anyway. Always play with it.

 

[DakaSha]

DakaSha I asked around in #rgrd on quakenet where a lot of RL devs and jday provided some suggestions from work on Brogue:

<jday> You iterate over your lights, adding their effect to cells; if the cell you're adding it to blocks light, and if the player is on the other side of it from the light (you can do the dot product or just compare which quadrant they're in), then you don't apply it.
<jday> Also, I can't tell much from that image, but make sure that (1) neither lights nor cells ever have 0 in any of r, g, or b, and (2) that values greater than 100% are supported, and only clipped when it comes time to draw them.
<jday> Also remember that you don't have to (or really even want to) follow the physical formulas for luminosity, because if you're not also taking indirect illumination and angle of incidence, and all kinds of other stuff, into account, it's not the "real" formula anyway. Always play with it.

Ok cool. I'll read up on his solution to determining whether or not the light is being blocked by the wall.
The other advice is sound and i'll look into when i actually start tweaking my lights. I haven't even begun to try and make the lighting really look 'good'. I'm still just messing with the rendering order.

edit: i *think* i may be on to something. It seems at first glance like i might be able to do it with old fashioned triangles. I need to look into what the dot product is though. It'll take me a while to decipher that.
Also i'm not sure what he means with quadrant. If he means quadrant as in the different quadrants that BSP produces that that wont work since i wont be generating m map like that

 

[Niektory]

I dusted off my project from last year and added some GUI and other stuff.

No Codexers were harmed in the making of this video.

 

[DakaSha]

Engine looks awesome

 

[Destroid]

DakaSha I asked around in #rgrd on quakenet where a lot of RL devs and jday provided some suggestions from work on Brogue:

<jday> You iterate over your lights, adding their effect to cells; if the cell you're adding it to blocks light, and if the player is on the other side of it from the light (you can do the dot product or just compare which quadrant they're in), then you don't apply it.
<jday> Also, I can't tell much from that image, but make sure that (1) neither lights nor cells ever have 0 in any of r, g, or b, and (2) that values greater than 100% are supported, and only clipped when it comes time to draw them.
<jday> Also remember that you don't have to (or really even want to) follow the physical formulas for luminosity, because if you're not also taking indirect illumination and angle of incidence, and all kinds of other stuff, into account, it's not the "real" formula anyway. Always play with it.

Ok cool. I'll read up on his solution to determining whether or not the light is being blocked by the wall.
The other advice is sound and i'll look into when i actually start tweaking my lights. I haven't even begun to try and make the lighting really look 'good'. I'm still just messing with the rendering order.

edit: i *think* i may be on to something. It seems at first glance like i might be able to do it with old fashioned triangles. I need to look into what the dot product is though. It'll take me a while to decipher that.
Also i'm not sure what he means with quadrant. If he means quadrant as in the different quadrants that BSP produces that that wont work since i wont be generating m map like that

Ah maybe he meant the cross product between a line and a point. It till tell you which side of the line the point is on (+ve or -ve result). All that math cramming should come in handy about now

 

[Zed]

I wonder how long you'd have to run a wiki (by yourself - mostly for content management) in order to get a rich world usable for games.
I'm thinking lore, maps, creatures, classes and professions, culture and so on.

Indies usually go the route of making engine/tech, then adapt some sort of on-the-fly creative work, because they don't have access to rich existing PnP gameworlds and stuff like that.
I think I'll start one and see how it goes. Maybe I'll invite any codexers who'd like to contribute (or just view it), but I only have vague ideas so far. It would be fantasy of some sort. Forgotten Realms with a Scandinavian folklore twist.

I am, of course, inspired by IDtenT (http://www.rpgcodex.net/forums/index.php?threads/idea-codex-original-lore-initiative.82858/), but this would be my own setting where any contributions would be a creature here, a town there, or a deity or something. But no-one would want to contribute to something absolutely shitty so I'll just sit on this myself for a while and maybe I'll come back with it later.

 

[DakaSha]

I've been working on my roguelike almost every day but most of it has been more thought work than anything. I decided to not worry about the lighting issue for awhile* and started work on the best part: Dungeon generation. I've mentioned before that i had previously worked on a dungeon generator that i was very proud of so this one has to outdo it of course and i have been going through a lot of approaches. I have the very very very basic and boring beginnings more or less done and may tidy it all up and make it expandable and leave it at that for awhile. My current goal is to make this playable (if you can call it that) so that i can have some fun with it.

I guess im just writing this so that it doesnt look like ive once again given up and the project has become vaporware . I'm actually really into this right now. Of course that will change when fall semester starts but meh

When i have my basic dungeon gen done ill make another shitty video because i know the entire codex just cant wait to see my shitty beginnings of a doomed-to-vaporware roguelike.

*(because chances are i will be implementing my own algorithm for the FOV in order to make them look more realistic around corners and there is no point worrying about the problem because it may become irrelevant)