Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Andir]

This is maybe a bit too much revival of a dead thread, but I'd rather raise zombies than create duplicate threads.

I've started learning programming -slow progress being made- and have been thinking of different formulas and concepts to include in my eventual game. I know that the advice is to not leap into making your ideal project, but my idea that I've been toying with is to start with a very basic core game and then add features as I went along until it would approach what I envision it to be which is, as all pipe dreams are, fairly complex.
My question is this: Is this a recipe for certain failure? I understand that sometimes with this method that major code rewrites become necessary for large improvements (see DF's z axis and the current army arc) but I was wondering if having a base idea in mind is enough or do all the interactions of objects and functions need to be pretty carefully coordinated prior to the coding? I know that experience would probably teach me this in time, but I haven't really gotten to the point of anything complex and thought that there's a wealth of folks on that there internet who already know.

Plan big, code small.  In order to do what you want, you have to create your objects in such a way that they are truly single function entities.  OOP is good for this if it's done right.  It's also a nightmare to recode if it's done wrong.  Just keep in mind while you're programming that your creature object is only meant to modify the creature, not sort inventory.  (That's meant for your inventory class.)

Truthfully, adding a Z axis to a game should never require a major rewrite.  You just have to add support to each object that uses coordinates.  If you are learning to program, this can be hard to do.  You will want to do things the way that works instead of doing it right.  One example is using accessors where you should instead of leaving a public variable.  (creature.getSpeed() instead of creature.speed)  If you use accessor functions, it makes it easier to modify the output if needed.  In the speed example, you can have that function figure in items the creature is carrying and return that value instead of returning the base speed and having another class figure the total speed with items.

You also need to think of things in the simplest form and think of thinks at different levels.  For instance, an entity on the coordinate plane (everything!) shares the same attributes as every other entity.  It's a generic object that may only contain coordinates, and that's it.  Every object you create would then inherit those coordinates from that base class.  A mob and a player both have inventory, and technically a tree, a tile, a house and a bush could as well... you could even say that a world has inventory if you wanted to go that far.  Adding inventory to an object could be as simple as extending the SimpleInventory class.  Adding movement could be as simple as inheriting a MovingEntity or MoveableEntity class... if you wanted to make trees moveable one day.

Of course, since this IS programming, there are multiple ways these things can be done.  People will also debate on the right and wrong ways to do them as well.  If you are learning, prepare to rewite some of our code, but if you find that you are recoding the entire thing from scratch, consider picking up an OOP programming book or a class and spend some time with it.

[deadlycairn]

Deadlycairn has become a Legendary Necromancer!

But seriously, I need help. After months of doing nothing, I've caught the development bug again. I'll go back to the ASCII Dungeon tutorial, but does anyone have any ideas after that? Preferably something written in the same style, for C++. I know of a few C++ primers but reading those is like beating my head against a brick wall.

Thanks already, and get back to coding! You guys are almost as lazy as me! 

EDIT: And i've just started going through the tutorials at adrianxw.dk - some of the stuff I only barely understand, but I'm keeping it together so far.

[turkishgiant]

But seriously, I need help. After months of doing nothing, I've caught the development bug again. I'll go back to the ASCII Dungeon tutorial, but does anyone have any ideas after that? Preferably something written in the same style, for C++. I know of a few C++ primers but reading those is like beating my head against a brick wall.

Thanks already, and get back to coding! You guys are almost as lazy as me! 

Try this:
http://www.amazon.com/Beginning-C-Through-Game-Programming/dp/1598633600

It's fairly easy to follow. I havn't programmed in years and I'm using it to relearn stuff, more or less. It'll definitely prepare you for programming ascii type games as all it uses is STL/console stuff.

And yes, I also find it incredibly hard to stick with something like programming. Only thing I can suggest is to do a little bit everyday.

[deadlycairn]

Unfortunately, I'm broke. I'll look for it in the library though!

[magikarcher]

2 Words: THANK YOU!

[lemmy101]

Hey all! I'm chris, the writer of the incomplete C++ ASCII Dungeon tutorials. Just got pointed over here and wanted to say a few things.

First, thanks for all the lovely comments about the tutorials. It means a lot they've been useful even if they're not complete. ()

The main reason for this is the site, which I used to co-run, got into some ownership disputes. Basically the guy who owned the domain and bought the server space decided to sell the site without even checking with us. We realised our hard work meant nothing and the site was never considered 'ours' and so a few of us left the site, and sadly this included the tutorial.

BUT. We've just recently started a new indie game development site (http://www.theindiestone.com) which will be the host to the new ASCII Dungeon tutorial at some point in the future. I've decided to rewrite it to focus on C# / XNA development, mainly because XNA came out after I started the tutorials and C++ never felt like the best choice after that. Secondly I've abandoned C++ for my new love of C#.

So the good news is the tutorials will be back and continued at some point when time permits. I've got about 3/4 of the way through porting the tuts to C#, but as always my life is pretty hectic so it'll be 'when I get time' progress will be MUCH faster in C# anyway, so in the longrun I think it's the best choice. Apologies to all those that specifically want to learn C++. I hope you can be tempted to the warm bussom of C# as I have

Thanks again! And apologies for the ongoing delay in sorting the rest of the tutorial out!

Coincidenetly I started playing Dwarf Fortress for the first time just a couple of weeks ago, so funny that I should come across this thread here.

laters!

lemmy aka Chris

[Sowelu]

That's awesome to hear!  I really look forwards to seeing that tutorial in XNA, as it can be much more accessible for people who like C#.

You'll get quite a lot of backlash from people who want their games to be cross-platform though...one of the benefits of roguelikes is that, well, they are easy to make cross-platform.  So OTOH I'm not sure it's a great idea, because as a C++ tutorial it was really quite good.

Anyway, thank you for the tutorial in the first place!  It's a bit under my level, but it's great to direct people at.

[lemmy101]

That's a good point. But to be honest the tutorial is more aimed at 'people who want to program but think it's too hard' specifically, so I should take any steps I can to make the tutorial target those kinds of people. I may think about avoiding XNA that way people could use Mono and it would be cross-platform.

Thanks again!

lemmy

[Sowelu]

Hmm.  With that target audience, it's not a bad choice at all.  And the standardized IDE and stuff sure means that you won't get library hell that's usually associated with newbies getting into C++. 

As you were!  I have full faith in your ability to rock the newbie roguelike programmer community to its very core.

[magellan]

That is actually what struck me as odd when i saw those tutorials.
Programming a roguelike isn't *that* hard, granted, but it's definitely harder than games with fixed content (wich on last count consisted of everything else but roguelikes)
I think it's a bit like saying "pottery isn't as hard as it looks. Here is a tutorial how to make greek statues" 

[Sowelu]

On the other hand, the work-to-playable-game ratio is a bit higher for roguelikes than it is for other games.  You can make a little jumpy platformer game, but it's going to be fun once.  A roguelike OTOH gives a lot more gameplay for your effort, even if the effort required is pretty high.  Also, roguelikes are turnbased, which is very easy comparatively, and the graphics are somewhat simple--and many novice programmers are not great artists!  A roguelike means you can do it with a team of one, and not need to get an artist to help.

[magellan]

But learning coding doesnt exactly improve your drawing skills.

Difference between turn based and realtime is
getplayerinput
vs
getplayerinput
wait until player really inputs something

... and if i spent the time i played around with map generators on drawing maps i would have quite a few.

sorry, my is still there.

[Sowelu]

Still graphics and sound.  A roguelike doesn't need either to be fun (although they can help sometimes).  A platformer totally does.  Graphics and sound usually means a team of more than one.

[Singularity]

But learning coding doesnt exactly improve your drawing skills.

Difference between turn based and realtime is
getplayerinput
vs
getplayerinput
wait until player really inputs something

... and if i spent the time i played around with map generators on drawing maps i would have quite a few.

sorry, my is still there.

Well, in my case, I'm an absolutely atrocious designer.  I'm no good at coming up with unique ideas, especially with level design. So, in my case at least, it's actually more appealing to think of randomized levels.  Besides, the common opinion is that many people create roguelikes so that they can enjoy the game they made... which is much easier when there's randomness than when there's a fixed plot / level progression.  Just my two cents.

[Andir]

Well, in my case, I'm an absolutely atrocious designer.  I'm no good at coming up with unique ideas, especially with level design. So, in my case at least, it's actually more appealing to think of randomized levels.  Besides, the common opinion is that many people create roguelikes so that they can enjoy the game they made... which is much easier when there's randomness than when there's a fixed plot / level progression.  Just my two cents.

Agree.  I'm the same way.  It's much more fun and entertaining coming up with an algorithm to make the dungeon interesting, yet make sure there's always a path.  It leaves the mystery of the dungeon to the computer and more for me to explore.  For someone hellbent on just "completing" the game, I'm sure it's preferred to have static maps so they can find the quickest route, but that's boring.   I want to explore.  Riding on a rail is boring.