Print

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

[Skyrunner]

[miauw62]

[EnigmaticHat]

Ok so I've made some progress on making a generic Turn Based Strategy game for learning purposes.  A lot of the functions I'm making should be useful in the game I ultimately want to make, although I might not get around to that in a timely manner since school is starting soon :/

Anyway, you guys probably aren't going to be impressed by this but I'm impressed by myself so I'm going to post it:

Spoiler: images (click to show/hide)

Most of what I've done has been on code for the terrain, which is represented by basic shapes since I don't care about graphics right now.  What I have right now is an "overmap" that represents a large region.  Each over map tile can be selected and zoomed in to a local map, which is where combat will occur.  The window is resizable based on a text file (like DF's init file) and the map zooms if you move the crosshair past the edge of the screen.
Here you see the overmap, with a forest tile selected:

Hitting enter brings up that tile's local map, which is of a forest:

Hitting enter again goes back to the overmap, and hitting left arrow selects a plains tile:

Which can be zoomed in on for a plains map:

What's really cool though is that going back to the original forest tile on the overmap and hitting enter...

Brings up the exact same map, because each overmap tile has its own random seed and thus always generates the same local map, without having to save it.

Before I can move on to having units and stuff and eventually have that stuff fighting, I need to make the controls less awkward.  Ideally you should be able to move the cursor and scroll on the map using the mouse, as well as hold down buttons to move the cursor faster with the keyboard.  Right now you need to press an arrow key each time you want to move the crosshairs  I also want to add a system where terrain on the local level can be modified and the game will remember how its been changed.

[Skyrunner]

The local and overmap views look too similar. Perhaos you should try to distinguish them in some way. Maybe use differently colored shapes?

[EnigmaticHat]

Yeah, and probably different sized tiles too.  They should have a pretty different look.

[BlindKitty]

Uh huh. So, I'm somewhat back to my earlier project, which I will keep calling Forgotten Dungeon for now. I just still feel that itch, and probably I'll need to learn some programming anyway. Today I'm mostly commenting the old code, because I really need to remind myself what was I up to when I last phased out (I mean, other things overtook me). But I hope to get myself a little more organized anyway in the coming days, and working on the game some time every other day at least is a part of this plan. I hope letting the word out will be somewhat motivating to me.

A brief overview of what I'm aiming at right now (although it will take a long, long time even in the best case scenario):
 - simple map of very, very deep dungeon
 - somewhat advanced combat system (with various moves, swordplay and stuff)
 - extremely robust crafting/enhancement system with focus on materials
 - more of a duel-styled fighting, than mowing through groups of enemies.

So if you are interested in dueling with bears using your Gold-plated mithril and oaken broad battle axe of fire (mithril isn't very good for fire enhancements, that's why you needed to plate it with gold), you might be willing to take some interest in it.

EDIT: I've managed to comment all my code so far (it wasn't much, but mostly it was thanks to me thinking ahead and making variables and methods names rather straightforward ), so off to real work on it.

[BlindKitty]

Sorry for double - posting, but the thread is getting somewhat buried under others.

So, first major accomplishment is getting the character creation mostly working - player can choose a predefined starting gear (well, right now there are no sets, but they will come up after minor build 0.4; more on the subject later) or buy equipment from new shop (which isn't perfect too, unfortunately). It was pretty hard, for a number of reasons, biggest of which is the fact that I'm building pretty much everything from scratch. It took me whole day to generate a method to print list longer than one page without messing everything up, and it was a complete rewrite of an earlier method, that took me all day too.

But the version is now 0.4.1 - and the goal for now is moving all my data files to the XML format. Right now I have a method reading rather poorly planned text file which is less then readable for humans, and I would like to have something easy to mod outside of the game, and easy to handle in code. So, XML it is. After that, I will be able to incorporate recipes and materials to make something at least barely playable - so I think version 0.5 might get out and be at least considered tech demo.

[guitarxe]

I plan on making a Roguelike pretty soon in C++,
So PTW
Also, I noticed that the Terror In ASCII Dungeon link doesn't work. Anyone got a good, complete, text-only tut for C++?

There's one here, using the libtcod library:
http://codeumbra.eu/complete-roguelike-tutorial-using-c-and-libtcod-part-1-setting-up

[Xgamer4]

So I've been meaning to try to develop a roguelike for a few years, but now that I've actually graduated college and don't have homework to kill my time, I've started.

I finally got to the point where I have two objects running around the screen! The player character and an "AI-controlled" character. That probably should've been easier than I made it, but I was reading articles on Reddit about Entity-Component design, and I liked the idea because it'd make the core concept of my game really easy to implement, so I was working off that design. And one of the ideas I read is that components shouldn't be obviously dependent on each other, or include much in the way of links to each other. So I built a rudimentary messaging framework so that components could talk without needing to know anything more than the name of the other component...

I'm hoping I didn't just build a massive performance impediment. But at this point, I'm going for "make it work, then optimize if necessary" over "make it perfect, and never actually get anywhere".

Just excited and wanted to share.

[dennislp3]

Thats a great approach...most the time perfection of code is never actually something that comes to pass...you are far better off (time wise) to throw some hacky thing together and if it works and doesn't need touched then leave it be

[Anvilfolk]

--SNIP--

That's what I've been building off of for my engine too, but I don't think I've got the messaging part down... Namely, I find it hard to make relatively simple systems work, like having armour components reduce incoming damage (e.g. what happens when there's no armour component?) unless you can change the contents of messages, and that makes it much harder to work in MP in the future.

[BlindKitty]

I have successfully migrated to XML based data system, and repaired quite a few things along the way (including, but not limited to, ability to print lists longer than one screen, and actually scrolling them somewhat - this is still pretty rudimentary, but still, it works). This means I'm free to go into more game-y details, like making more defined (and more differentiated) opponents, and a little more complicated fighting system (a.k.a. version 0.5). When this will be more presentable, I'm planning to release it on the public and maybe start a new thread or something. Prepare some eye patches, because your eyes will probably bleed.

[Xgamer4]

--SNIP--

That's what I've been building off of for my engine too, but I don't think I've got the messaging part down... Namely, I find it hard to make relatively simple systems work, like having armour components reduce incoming damage (e.g. what happens when there's no armour component?) unless you can change the contents of messages, and that makes it much harder to work in MP in the future.

Disclaimer: 
What I'm gonna say was my solution before I tossed the strict messaging system, because it made doing simple things very tedious. My current system is to basically use the Entity as the messaging system - every entity has zero or more components, every component has one entity (the entity with that component assigned to it). Then I just go through the entity to get to any other component. Also, I use Python w/ pygame.

First things first:
The way my messaging format worked was as follows:
Every component contained a dictionary named "vars".

The initial message is a tuple of the following form: (recipient/sender component, contents).
The "recipient/sender component" was the name of the recipient component, if it's a message being sent, or the sender component, if the message is being received.

The contents is a tuple of the following form: (instruction, variableName, newValue)
"instruction" was an integer - the most common instruction was to update a variable, but there were also instructions to update a variable outside vars (in very specific circumstances where using the vars dict wasn't possible), to request a message, or to indicate that this is a response to a requested message.

When received, the update variable instruction just did

Code: [Select]

self.vars[variableName] = newValue .

Then every function in a component just checked self.vars for any value it needed, so that any other component could update it as needed.

Unfortunately, the way it was implemented meant that messages could only be sent inter-entity, and instead of redesigning, I scrapped it for the system in the disclaimer.

My (never implemented and untested) solution to your incoming damage/armor problem was to have component that handles attacks send a message containing a tuple to the defending component of the form (hitChance, damage). From there, the defending component would use the hitChance to determine if the attack hit, and if so, calculate the damage from its own damage reduction and the damage in the message.

-----------

I think that was just a very long-winded way to say "In my design, it's impossible for something not to have a necessary component such as armor, and the message can be changed." Sorry, hopefully you found something useful in there...

[Anvilfolk]

Cool, I think we're pretty much on the same page!

The thing about messages is that you don't really hardcode interaction between components, which is a great plus for reusability. Right now, my components are definitely inter-connected in the sense that my AttackComponent is checking whether targets have HealthComponents and things like that.

I think a much better system would be having component interfaces. So, every component implementing the HP interface would need a way to damage it, but the underlying implementation could be different. One simple HP component could just receive damage, whereas a more complex HP component could check whether there were "DamageReducingComponents", of which Armour could be one, MagicBuffs could be another, etc. These would all implement the same interface, but having pretty different underlying mechanisms.

There's lots of interesting resources you can read on EntitySystems or EntityComponents, like Game Coding Complete's first chapters, and some loose chapters on it in several Game Programming Gems books. Definitely worth a read.

If you're ever interested in collaborating on a Python/PySFML game, check my sig For now I admit I've given up on roguelikes!

[Xgamer4]

I think a much better system would be having component interfaces. So, every component implementing the HP interface would need a way to damage it, but the underlying implementation could be different. One simple HP component could just receive damage, whereas a more complex HP component could check whether there were "DamageReducingComponents", of which Armour could be one, MagicBuffs could be another, etc. These would all implement the same interface, but having pretty different underlying mechanisms.

That's actually how I'm kinda handling mine - the only difference is that, instead of using an actual interface (ie - how Java uses them), I'm using a component as an interface.

So, for example, for attacking someone, all the system handling collisions has to do is pass a reference to the colliding entity into the entity that got collided with to the CollisionComponent of each - from there, the CollisionComponent determines what needs to be done.

That said, while I'm not using explicit Java-style interfaces, my Components themselves are very subclassed. There's a Component class - which handles the parts that every component needs to have in common - then there are what I call "Base Components" (Collision, AI, Ability, etc) that define the parts that any component intended to behave as a Collision handler, AI, ability, etc needs to have. The actual Components that are given to entities are subclasses of these Base Components. So the Base Components basically are the interfaces.

(And the components dict in the Entity is basically a way to get around Python's duck-typing, now that I think about it... The name of the component (defined in the Base Component) is used as a key, and that's how I guarantee I'm handling the right component. In Java it'd be less of an issue - define the base components as interfaces, then give each Entity an instance of each interface (possibly empty), and I'd accomplish the same thing... Huh, didn't realize that's basically what I was doing until now...)

I actually did poke around both of the projects in your sig. I'm somewhat interested in Agora (and my two preferred languages are Java and Python, so no problems there...). I'm just not sure I have the time to devote to getting up to speed right now, and I'm not sure I'm confident enough in my skills to be of much help in a collaborative project, honestly...


As for my game -
I swear, I'm doomed to annoy myself with perpetual subtle errors. Overhaul my messaging system? Go to test, spend a half-hour to an hour troubleshooting, and the problems I'm having were because I did this:

Code: [Select]

for var in list:
   var2 = func(list)

Fix that, and it works fine.

Decide to cut up the UI into multiple screens so I can add room for a message log and a stat window, while adding a camera to the map in the process? Spend a half-hour debugging the fact that python defaults to integer division when dividing an integer by an integer - so my (1/3) and (1/4) that were meant to split up the entire screen turned into 0, and not the fraction I wanted... Fix that, it works fine.