Vapourware Codexian Game Development Thread

[DakaSha]

Well since trees are being posted this is something i made quickly when trying to learn how to use unity a long time ago.
Never was meant to be anything more then an atmospheric scene.

I have no idea why i made a still video though.. i could have at least walked around lol

Looks good, you should keep at it.

Can you tell me, what is that rendering style I see on Unity? Is it a filter of some kind? It looks like a pixelated painting.

As fun as it was I have no way of actually doing anything serious in 3D. It just requires assets I couldnt even make placeholders for. I designed the tree in that scene but unity comes with a tree editor that allowed me to get what i want with some messing around and imagination.

Also I'm not using a specific filter for the effect. It's a myriad of post processing effects (shaders) applied.

 

[GordonHalfman]

Thanks for that 2D tree video, very nice. I suppose one advantage 3D has here is dynamic lighting. I don't know if there's anything you can do in that area for 2D? I guess there must be a simple blending operation that lets you apply at least a simple day-night cycle.

 

[GordonHalfman]

Dragging this post up from a while back, but could you elaborate on this point?

Well, the problem is really two things, though from what you describe we're only looking at one of them.

One of the problems with talent trees in many games is that they are used to hold unlockable abilities. These tend to change the very essence of an RPG. Instead of having numbers that determine how good a character is at the various possible interactions in a game, the abilities themselves are the interactions. This makes characters far less comparable to one another, and it makes it far more tricky for the player to cope with opposing characters who have abilities the player hasn't even seen or tried out. Furthermore, it makes it tricky for the developers to implement large scale game mechanics that affect each character to varying degrees. If a game relies purely on an ability/talent tree and does away with numerical statistics entirely, the developer has nothing to work with in terms of, for example, altering the cost of items based on the customer. Developers have to scale back on the number of formulae that can be used on all character in favour of formulae attached to unique abilities that a character can either have or not have. In other words, numerical statistics aid simulation far better than unlockable abilities.

The second problem, which is more applicable to you, is the tree itself and whether it's advantageous to structure progression in such a way. What trees do is linearise progression. Requiring one thing to get another thing may be appropriate if it matches up with real life skill requirements, but in a lot of games it tends to be very arbitrarily put together, though mostly in games with unlockable abilities like Diablo II. Instead, I think there's almost always a more appropriate way to go about structuring progression. Mixing up training, use-based levelling and point allocation while having very shallow hierarchies (such as spells inside spell schools) tends to be far more appropriate for most games than deep hierarchies.

Interesting thoughts thanks. Thinking about it I'm not really proposing a Diablo like tree, it's more just a D&D like system but where the skills have a narrower range and most of the feats have some skill/stat requirements. It's possible the last part is something I like more because of the way it appeals to players psychologically than because it's better in pure game-play terms. Harvey Smith talks about in it at the end of this video:



where he mentions how the swimming skill and augs allowed you to "build a fantasy in the players head" of being the "aquatic guy". Similarly I like the idea of being "the dodge guy" giving you some incidental bonuses like being able to run over a field of deadly traps.

The point about "aiding simulation" is interesting, it's not something that seems to apply a lot of the time in RPGs where the skills are only used for binary checks each set by hand by the designer, but that's something that can be improved in some cases.

 

[chewie]

Thanks for that 2D tree video, very nice. I suppose one advantage 3D has here is dynamic lighting. I don't know if there's anything you can do in that area for 2D? I guess there must be a simple blending operation that lets you apply at least a simple day-night cycle.

Have a look at the ethanon engine - there are some pretty nice videos about that topic:

-> http://www.asantee.net/ethanon/?p=videos

 

[Davaris]

Have a look at the ethanon engine - there are some pretty nice videos about that topic:

-> http://www.asantee.net/ethanon/?p=videos

This channel as well.

 

[Destroid]

C++ offers performance. It does not offer ease of programming. In most cases performance is really not a great concern for indie and amateur developers, certainly compared with productivity.

 

[20 Eyes]

Because you use the tool fit for the job and IMO C++ is going way overboard. You are just adding a layer of complexity that is not going to really benefit you in any way.

Never programmed anything in my life, but every good game I've heard of used C++ so it must offer something.

Good enough for Tim Cain, good enough for me. I'll pick a language Tim Cain knows over DU's language he uses to make an ignore filter.

Dakasha and Destroid are right. For anything you're going to make, especially as a new programmer, C# or Java would be more than powerful enough while being easier to learn and getting more work done faster. It's certainly possible to learn C++ first, but you might want to reevaluate your reasoning. Saying since it's good enough for Tim Cain and other professional developers with decades of experience is like saying that using models made of 10,000 triangles is good enough for them so that's what you're going to do too. Sure, you can. But, especially if you just want to do this as a hobby, it's probably not the most efficient way.

 

[DakaSha]

Because you use the tool fit for the job and IMO C++ is going way overboard. You are just adding a layer of complexity that is not going to really benefit you in any way.

Never programmed anything in my life, but every good game I've heard of used C++ so it must offer something.

Good enough for Tim Cain, good enough for me. I'll pick a language Tim Cain knows over DU's language he uses to make an ignore filter.

Every "good" game you have heard of was pushing the hardware of the time to it's absolute limits and was programmed by extremely talented people with decades of experience. Not to mention that a shitload of those games prob actually werent using C++... It's a misconception that all the old games were.. back then C++ had a reputation of being a shitty language incapable of fast processing.. you know kinda like the newer languages now days. Many of the games back then were actually done in C (Or a mix actually)

Old console games were done in machine/assembly languages.. Have fun with that.

Thinking that C++ brings anything more to the table then C# (or a lot of languages) is also a misconception.. C++ "CAN" bring improved speed performance but the fact of the matter is that the time you use trying to write fast C++ code can be put into optimizing your finished C# code. Achieving the same performance with less headache (Btw C# actually allows for optimization features (pointers) using unsafe code.. It's just not a "default" option.. not that ive ever done much using them)

But knock yourself out. Let us know how it went ^^

edit: I do have to add that C#'s console apps are unbearably slow. At least in their default state. I'm not sure if things can be turned off to speed them up (It may be the debugging). When I used them they weren't usable for a an ASCII rogue like. But there are other languages and there is nothing saying you can't just write an ASCII engine in XNA (allowing for some special ascii effects which I find cool in ASCII games)

edit: Btw I have an XNA ascii engine:


Ignore the console part. I changed that into the python console i showed in a former post. But this actually shows a usable ascii engine.

Its old though and its prob terribly written ^^

 

[Flatlander]

Another thing to consider is the huge inertia C++ has in game dev sector. Even if the major studios wanted to use something else it wouldn't be that easy because of the existing toolkits and talent base (and the fact that triple-A studios are primarily developing for consoles which have limited hw resources). None of that concerns minor players developing for the PC platform, and that should be used as an advantage.

IME there are two kinds of people advocating C++ use in games; n00bs who have heard that it's what the "real" games are made with and the very small amount of experienced developers who actually have positive experience with in situations where it's actually needed.

 

[Davaris]

Because you use the tool fit for the job and IMO C++ is going way overboard. You are just adding a layer of complexity that is not going to really benefit you in any way.

Never programmed anything in my life, but every good game I've heard of used C++ so it must offer something.

Good enough for Tim Cain, good enough for me. I'll pick a language Tim Cain knows over DU's language he uses to make an ignore filter.

C++ takes a long time to get really good at (some say 5 years) and it gives you more enough than enough rope to hang yourself with. However it does have a lot of libraries and is one of the fastest languages out there, apart from raw assembler.

Speed doesn't matter if you are making a simple game, but when you want to make a big complex game, where the architecture takes years to build, you will need all that speed and more.

All game engines written in C++ offer slower executing, safer and easy to learn scripting languages, so their artistic employees can script their games and that is what I would compare those other languages to. So what language you learn depends on your goals. If Tim Cain is any sort of a programmer, he knows a few languages.

Edit:
Another positive with C++, is you can customize game engines that expose their source code.

 

[shihonage]

To add my anecdotal and biased experience:

Shelter is written in C.
Reasons:
1) I needed to have enough speed for internal script interpreter (ShelterScript) which powers behaviors of people, dialogue, global events and object interactions, in real-time.
2) I didn't know how much the renderer would load the computer, and wanted to have low-level control over everything (and room for expansion).
3) I was previously familiar with C.

Monsterland is written in Pascal.
Reasons:
1) I wrote the core of it in 1996 in Turbo Pascal.
2) I like Pascal and am comfortable with it. Pascal-compiled executables reach within 10% speed difference from C/C++ compiled executables, which is good enough for me.

 

[asper]

Turbo Pascal... Well that brings back memories

 

[chewie]

Turbo Pascal... Well that brings back memories

yeah, even some bad ones...

 

[Zed]

went back to movement because I'm still undecided how to do combat. for a while I was working on tactical combat with 10x10 grid, like a chessboard. but that would require too much fucking work, especially making a somewhat intelligent AI. so now I'm implementing path-finding for the world view instead. this will be instead of arrow key movement, so it's fully pointer device supported, with keyboard purely for menus and stuff.


here are some sprites and shit I did before scrapping the combat I was working on. I'm fucking proud of myself I manage to draw a somewhat convincing 32x32 pixel woman. the trees were placeholder obstacles.

 

[20 Eyes]

went back to movement because I'm still undecided how to do combat. for a while I was working on tactical combat with 10x10 grid, like a chessboard. but that would require too much fucking work, especially making a somewhat intelligent AI. so now I'm implementing path-finding for the world view instead. this will be instead of arrow key movement, so it's fully pointer device supported, with keyboard purely for menus and stuff.
View attachment 164

here are some sprites and shit I did before scrapping the combat I was working on. I'm fucking proud of myself I manage to draw a somewhat convincing 32x32 pixel woman. the trees were placeholder obstacles.
View attachment 165

Those sprites are nice. Everything else is looking promising.

I need to hurry up and finish these damn essays so I can get back into my game.

 

[Zed]

what was really good about those sprites was this

hands (unarmed) and weapons are separate. obviously, I could have split it up to have armor etc. but my point is it's not easy making a sprite that's essentially a 32x32 paperdoll.


anyway, the pathfinding - again. the green box is the player, 16x16. the yellow is the pathfinding, which travels a tile at a time. to make camera and movement smooth, the green is eased into position after each pathfinding node. works pretty nice. the only thing I have to do now is add is a way to click to cancel movement (then I might upload a prototype on the codex for funsies) and then I'm back at solving combat.
I'm very inspired by the combat in this game, http://www.rpgcodex.net/forums/inde...wler-that-is-actually-fun.70857/#post-2036323
it has some positional tactics, but it doesn't rely on the AI being smart about it.


oh and I don't know if I've shown it but here's the new stat system. what I have worked out for the stats should work with a combat system like in that flash game in the link above. I'm considering having party-wide skills, e.g. as long as someone in the party, doesn't matter who, has 10 Dex, then you are able to max pick lock. "what if a character with the 10 Dex dies?" well, unless they all die and it's game over, every fallen characters are revived at 1 hp after a fight. If that feels weird then I'll consider something else.

 

[Excidium]

Turbo Pascal... Well that brings back memories

yeah, even some bad ones...

mostly bad ones. :p

 

[chewie]

oh and I don't know if I've shown it but here's the new stat system. what I have worked out for the stats should work with a combat system like in that flash game in the link above. I'm considering having party-wide skills, e.g. as long as someone in the party, doesn't matter who, has 10 Dex, then you are able to max pick lock. "what if a character with the 10 Dex dies?" well, unless they all die and it's game over, every fallen characters are revived at 1 hp after a fight. If that feels weird then I'll consider something else.

I'd skip the resurrection - if someone important dies, he dies. So the party has to work together to not let that happen.

And if the 10 DEX-guy dies without the party having a chance to prevent that from happening, then the party either has to look for a new lockpicker, or the next one in the row (e.g. the DEX 6 char) has a new task at hand.

That's a nice example on how party based games could be improved =)

 

[Zed]

chewie yeah I know, it's pretty shit. I should just have guys die. I'm still trying to figure it out.
For a time I was considering having just one main character, and the others being fully expendable randomzied henchmen. Henchman dies = go to tavern, hire new one. Main character dies = game over.
I really want to stick with fully player-created party for this though. Characters that last throughout the whole (relatively short, probably) game.

 

[Lord Rocket]

Maybe a wound system, like in Wasteland? 0HP = not dead but fucked up, have to expend resources to keep them alive, take them to a town to get healed, etc.

Less annoying than instadeath, less retarded than resurrection

(or you could balance the game for TPKs I guess)

 

[SCO]

http://www.ai-blog.net/archives/000152.html

 

[Davaris]

http://www.ai-blog.net/archives/000152.html

Yeah, nav meshes are the way of the future. I am adding recast navigation to the C4 Engine for that reason and will show a video when its done.

Here's the blog of the guy that made recast navigation. Its free for commercial use and I think he was the lead AI programmer on Crysis, so its incredible he is giving it away.

http://digestingduck.blogspot.com.au/

Here's video of recast generating a nav mesh, while the game is running.

 

[SCO]

Yeah, nav meshes are the way of the future.
...
Here's the blog of the guy that made recast navigation. Its free for commercial use and I think he was the lead AI programmer on Crysis, so its incredible he is giving it away.
http://digestingduck.blogspot.com.au/

His next-to-last blog entry seems to be him apparently disagreeing.

Anyway, anyone can remember a "chase sequence" game that allowed the npcs to fall off ledges? It would be interesting to a have a (mirror's edge for instance) game with fallible ai like that, say 20% chance of the mook jumping after you and 50% chance jumping too soon and grabbing the ledge or falling off or both.

That would introduce some strange cross-purposes on the navigation; you'd need to see if the jump was actually possible for the normal jumping animation, but intentionally fail it into a failure animation. But maybe they can be put on the same place, just make the failure "jump" shorter, instead of jumping earlier.

 

[Davaris]

His next-to-last blog entry seems to be him apparently disagreeing.

Wait and see if it makes its way into the recast lib and it works in practice.

The article you posted earlier compares navmesh to waypoint graphs, and many rt games are still using waypoints. If you want to understand the downsides of waypoints and why they should be abandoned, your article is a good one. IMO people are still using waypoints, because they are very easy to program.

Edit:
If Mikko's latest line of research pans out, and I understand it correctly, you could make turn based games in dynamic worlds.

 

[SCO]

Something good for programmers to read about FP:

http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

summary:
http://www.altdevblogaday.com/2012/04/05/floating-point-complexities/

tl;dr: