Vapourware Codexian Game Development Thread

[20 Eyes]

Look great, chewie. Also, some very interesting conversation in the last several posts.

I was dicking around with XNA between classes today and I managed to make my first turn-based game. It's really simple, the only thing you can do is move around on your turn and watch the NPC move around on its turn. But I'm happy with it because I did it all on my own without referring to any e-books, tutorials, or source code or anything like that, so I feel pretty good considering I've only been studying this as a hobby for a few months.

 

[Davaris]

I just found this and it looks very nice. It has a very good explanation of how it works in Java.

http://www.gamadu.com/artemis/

 

[chewie]

I just found this and it looks very nice. It has a very good explanation of how it works in Java.

http://www.gamadu.com/artemis/

Indeed, very good read =)

This I´d call a pure implementation - much more sophisticated and generic then the one I developed.

Look great, chewie. Also, some very interesting conversation in the last several posts.

I was dicking around with XNA between classes today and I managed to make my first turn-based game. It's really simple, the only thing you can do is move around on your turn and watch the NPC move around on its turn. But I'm happy with it because I did it all on my own without referring to any e-books, tutorials, or source code or anything like that, so I feel pretty good considering I've only been studying this as a hobby for a few months.

Thanks =)

About you playing around with XNA - this gem sure has a nice rendering engine. Is it any good for the rest of a game (sound, input handling, gui and the like)?

And turn-based combat - yeah, the basic principles are easy, but I learned that it can get more complicated, espcially in terms of AI handling. You need a tough pathfinder and make sure to that the AI plays by the rules - in every aspect (as the player has more time watching the AI :D) Nevertheless - enjoy your victory, you earned it :D

 

[DakaSha]

Xna is powerful but complete shit in terms of platform support.
I used to use the FRB engine and from what I heard they moved to MonoGame meaning its cross platform.

Def worth a look if you insist on using XNA/C#

 

[Davaris]

I just found this and it looks very nice. It has a very good explanation of how it works in Java.

http://www.gamadu.com/artemis/

Indeed, very good read =)

Its the best explanation I have read of component based systems and it also helped me understand how to use the C4 Engine a little better. I just realized C4 already has the above capabilities and I was using it like an old fashioned inheritance programmer. Time to refactor some code. lol

Artemis_Entities == C4_Node
Artemis_Components == C4_Properties
Artemis_Systems == C4_(Script)Controller + C4_Methods

 

[20 Eyes]

About you playing around with XNA - this gem sure has a nice rendering engine. Is it any good for the rest of a game (sound, input handling, gui and the like)?

And turn-based combat - yeah, the basic principles are easy, but I learned that it can get more complicated, espcially in terms of AI handling. You need a tough pathfinder and make sure to that the AI plays by the rules - in every aspect (as the player has more time watching the AI :D) Nevertheless - enjoy your victory, you earned it :D

XNA is almost certainly powerful enough to make any 2D game an indie/small studio could make. Magicka and Terraria are two XNA games that made it big. Of course the downside, like DakaSha said, is it's very limited in that it only supports the Windows, Xbox 360, and Windows Phone 7 platforms. I think it's a great tool to learn on (at least it has been for me) because you can have sprites on the screen after just two or three lines of code and it's a good motivator when you can see your work so soon. I'm a big ways away from having to care whether Mac users can play anything I make, so it's not a big deal for me.

And yeah, I figure turn-based combat will get exponentially more difficult the more you add to it. I think I'm at a point where I could at least try to make something like a very simple, non-randomly generated roguelike. One player character, a few stats, a few enemies, very simple combat, and a few levels of a dungeon. Easier said than done, of course, but it should be fun practice and a good gauge of where I'm at.

 

[Davaris]

And yeah, I figure turn-based combat will get exponentially more difficult the more you add to it.

Trying to mix real time and turn based as Fallout does, is very fiddly. So if you want to make a turn based game, I'd recommend you make the whole game turn based, to save yourself a lot of trouble.

 

[Destroid]

I have to say, now that my mod is quite functional as a game and we are mostly to the point of adding additional content - it's a lot harder to get motivated to work on it. None of the new stuff is really *new*, it's mostly more variation on already existing systems which is really not as fun to work on, when previously we could see the mod coming together piece by piece with drastic changes each revision. Laying the foundations and painting the broad strokes of the design is much more interesting.

 

[OuterSpace]

Trying to mix real time and turn based as Fallout does, is very fiddly. So if you want to make a turn based game, I'd recommend you make the whole game turn based, to save yourself a lot of trouble.

Agreed. Doing it the way fallout does it would be a major headache.

I'm still trying to wrap my head around this component based entity system. I'm very interested in it.

I've seen comments in articles where people argued a component should never refer to any other component and that confused me, because I couldn't see how you could not do that in an RPG.

Do you mean that components would interact with other components directly? Would these components be within the same entity?
It seems like the System would act as an interface for all Component interaction.

 

[Davaris]

Do you mean that components would interact with other components directly? Would these components be within the same entity?
It seems like the System would act as an interface for all Component interaction.

You would run into the same problem with a system needing to know about components, or other systems, where the entity it is operating on, may not have all of them.

Edit: according to this article, systems should not know about other systems. They call them behaviors.
http://stackoverflow.com/questions/8332040/frp-on-a-game-engine-is-it-worth-it

Of course you can check for that, as chewie said, by making the system do nothing or return a default value, if all prerequisites are not met.

I'm still trying to wrap my head around this component based entity system. I'm very interested in it.

Stick with this link and play around with the Java code. There is also a C# version of Artemis you can try.

http://www.gamadu.com/artemis/


All the other articles I have read, gave me the general idea, but left something crucial out, or provided no source code and ended up leading me down the wrong track.

Having said that, here's another article.
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy

If I remember correctly, this article combines both data and systems into 'the component', so it is inferior to Artemis IMO.

And this article describes messaging between components:

Why I switched from component-based game engine architecture to functional reactive programming
http://lambdor.net/?p=171

Don't ask me what functional reactive programming is, that is something else entirely.

 

[OuterSpace]

Thanks for the reading material Davaris. I'm going to study up on this for a bit.

 

[chewie]

I'd like to add - those are concepts. (good ones) This doesn't mean you have to implement the whole range - you can also stick to the basic principles (which I did). It's like... humm... writing a rule based ai or implement a neuronal network IMO. The network is far more powerful in direct comparison, but then again you have to ask yourself: do I need all that power?

You have to find a balance how much time you can invest into a feature like this (without making your team and / or project suffer) - because especially if you are completely new to a topic, your first implementation most likely won't work as good as the next iterations. (okay, you can be a fucking genius and just get it right the first time, but most of the time that doesn't happen :D)

But wrapping your ahead around it is worth the time I'd say - gives you some fresh perspective

Oh, and about collecting knowledge about that topic - there is also Grease (python based)

http://pypi.python.org/pypi/grease

parpg is using this one, I lately talked to one of their programmers, and it seems to work nice for them =)

 

[DakaSha]

Started work on something of an engine in Haxe/NME (Which I recommend to everybody)
http://www.swfcabin.com/open/1331927692

Move with arrow keys, zoom with +/- and you can change top viewports position by clicking on the bottom hexes.

It doesnt look like much but the point of it was to be able to show a scene/world from multiple cameras/viewports. It can support an arbitrary number of cameras.

Btw it runs like shit when zoomed out but it was designed for the c++ target and im just using flash to show it. also it hasnt been optimized at all.


Of course ill never do anything with it but meh

 

[20 Eyes]

Made some progress in whatever-turn-based-thing-I'm-working-on-right-now, but most of it is under the hood stuff. Right now I'm trying to come up with a decent HUD layout. It sucks when anything you would want to ripoff be inspired by is either 15 years old or based on D&D. I really have zero interest in D&D-like combat because Knights of the Chalice and Temple of Elemental Evil already do a great job with that (and it's overdone). JA2 is the main source of HUD inspiration right now, since I think it does a great job and I'd like my game to be party-based. It's hard to keep things relatively simple (at least in the HUD) and still let you know what you need to know. Right now I only have a few essential stats that really define your character in an RPG:

I'm considering changing 'HP' to a localized damage system, like a more RPGish Deus Ex. But right now I just want to get the fundamentals done, and HP is easy.

 

[chewie]

Yeah, gui design is science by itself - took us 4-5 iterations of concepts until we reached something we all could live with. Still loads of opportunities to improve it though.

About your approach - I´d say it's a good start so far. The HUD should give all the info needed to handle the current implementation of gameplay features. This helps you as a developer to see what is needed in terms of usability and founds the base for the next iteration (e.g. when a designer creates some nice gfx / layout)

Keep on coding =)

 

[Zed]

I think UI should be one of the most iterated elements of a game. If you, as the creator and initial tester feels it's off, it's usually very off. At least that's my experience. But developers, I guess very often the more programming-centric ones, might go "it works, good enough".

 

[chewie]

Zed you are right - especially because you said "UI" - the whole user interface has to be constantly checked if it makes any sense, is too complicated etc. Very important point =) (and one that can eat quite some hours of your time ._.)

Some update about Zero - I finally managed to both capture sound + video (don't ask - took me several days, minimum). So now here we are - after 6 months of intermission:

ZeroTV episode 16 'High yield'

A lot of stuff is going on, added a wall of text to the video itself, but here a teaser:

- Expl0sionz!
- Soundz!
- turn based combat
- lockpicking (wizard style ^^)
- fleeing npcs
- a lot of dead - but no pixel was harmed!

Have fun :D

 

[Surf Solar]

20 Eyes - UI creation and design is one of the most enjoayble things for me to do - send me a rough draft and a "theme" you want to see and I will try and see what I can do!

 

[20 Eyes]

20 Eyes - UI creation and design is one of the most enjoayble things for me to do - send me a rough draft and a "theme" you want to see and I will try and see what I can do!

I'd love some UI help. The game isn't going to be commercial, in case you were wondering. I'd like to do a 1-4 hour small campaign that consists of a few small battles with a small persistent party and release it for free if I think it's worth playing. A few UI assets and a layout would be great.

BUT, before I'd feel comfortable accepting any help I need to get the basics of the map/pathfinding systems down. Right now enemies just chase the player with no respect to collisions. I managed to get a functional A* pathfinding system in my last game, but there is still a chance this part will cause me to ragequit (again) because it's a bit more complicated. And then I'd just feel bad about wasting your time. Once I cross that hurdle, everything else should be relatively smooth sailing. And if you still have the free time, I'll let you know the specifics (another thing is I don't even know myself right now). Thanks for the offer, by the way.

 

[DakaSha]

http://www.codeguru.com/csharp/csharp/cs_misc/designtechniques/article.php/c12527
Best c# Astar ive ever found. I even ported it to haxe (as much as possible)


No reason to write your own

 

[Angelo85]

20 Eyes: You should charge Surf Solar for the "invaluable learning experience" he'll get for helping you with the project.
Damn, I think I might have drunk too much juice today.

 

[DakaSha]

20 Eyes :

If you ever do anything with hexagons I think I may have even made a hex version of that pathfinder. Just to let you know. I think I have it on my assembla account

 

[20 Eyes]

20 Eyes :

If you ever do anything with hexagons I think I may have even made a hex version of that pathfinder. Just to let you know. I think I have it on my assembla account

Thanks, bro. I'm making a tile engine right now, but I think this one is going to be square-based for simplicity's sake since it's my first try.

Pic related, it's not pretty but it works:

20 Eyes: You should charge Surf Solar for the "invaluable learning experience" he'll get for helping you with the project.

lol, if it worked like that I'd just get a couple of programming students to pay me for the privilege of making all the tedious parts of an isometric tactical RPG engine and allowing me to sit back and code in all the combat and character systems and anything else that might be occasionally fun. I would tell them that directly participating in Vaporware Quest by 20Eye Studios will help them get a job at Bethesda or Bioware and rake in the cash.

In reality, I have just the faintest idea what I'm doing and am incredibly grateful for any tips/advice/help.

 

[Zed]

Start by copying a game 1:1. Preferably a simple game.
Say, a roguelike. Then, off that, you can expand.

 

[20 Eyes]

Start by copying a game 1:1. Preferably a simple game.
Say, a roguelike. Then, off that, you can expand.

That's more or less what I'm doing. The project in the screenshot I posted with HP and AP on it has a simple, but working, turn-based system and was only a dozen or so lines of code away from having basic roguelike combat. The only difference is it has a variable for a character's 'speed' (action points) allowing the characters to take multiple moves or attacks (when I get around to implementing attacks) in a turn depending on their relative speed instead of the standard 'I go, then you go' roguelike approach. A map system with proper collision and pathfinding for NPCs seem to be the next big building blocks in a roguelike game so right now I'm just going through some tile engine related tutorials to get ideas.

Another big difference from a standard roguelike is I want it to be party-based, but I don't think this will be much of a problem based on the way I set up my 'Actor' classes. The last huge difference is no random generation for simplicity's sake. And shitty pixel art instead of ASCII, I guess.