Actually, I found out what the issue was with that crash and I finished migrating some more code over to the little entity management system I've written, but now I have a new weird problem. I have a vector that stores my entities. I can push_back() one entity successfully, but any additional entities will crash it.
This one I really can't figure out. emplace_back() doesn't work, either. It kinda sucks as I've been kinda significantly altering some things in an effort to get it to work, but I don't know if I'm barking up the right tree.
It's definitely adding the first object to the vector. It reports that it's size went from 0 to 1. I may try just limiting it to one and see if there's something wrong with the copy it's holding onto. I don't get why it wouldn't be able to allocate more memory for additional objects.
I'm really at a loss on this one... I'm using very similar code to store my maps and the elements in the maps and my screen buffers and all of them are working properly...
Got it working. I dunno why, but it was due to the pointers I was using to build my entities. I'm not sure why it was screwing up this particular vector. I will have to look into that as a bit of research.
But it works. I converted the boulders of the previous builds into entities and plopped them into their positions. Currently they have physics, but I don't actually do any checking against other entities, yet.
The next steps will be to start building all of the various little systems to get the entities working together. I already have a couple of them in place for the Player. All I have to do is add the other entities to those systems and they should work exactly the same way. I still debate whether or not I should integrate the player as just another entity, but I feel it would make the input system too complicated for its own good. As it is, I can basically get things to work for the player and more or less know that they'll work for everything else.
Wow. OK, I've been working on this and I think I am at the point where I need to figure out how to debug this, cause something is wrong and I am completely at a loss as to why. I have fucking mangled my code trying to understand what the fuck is happening, but to no avail.
Going to take a break.
The issue is that I'm now checking to see if the desired position the player wants to move to is occupied by any other entities, and if so, it will check to see if that entity is solid / can be pushed / etc.
So the movement of the player was working in a previous build before I started adding that, but now the player doesn't move. It's still working, in that the keystroke is still happening, it's getting it, it's assigning a movement vector and it's running through the update process that alters the position of the player, but for whatever reason it no longer is actually working. I have no clues. I removed all of the checking and I am basically straight-up assigning a movement vector to the player now when a button is pushed, and it's just not moving it.
I have no idea what I changed to fuck this up. I have to go get some food and get away from my PC before I put it through the window
I am such stupid. Fucking jesus. I still have to go get food, but I now know why it was doing it. I am the dumbest mother fucker on the planet. I just wasted like three hours of dev time because I forgot to put a '&' in my code, and then rewrote half my update routines as a result. Jesus. Well, should be mildly quick to fix, at least...
Ate and watched an episode of Star Trek to unwind. Took only about five minutes of coding after that to get my expected results to happen in the game. Discovered a drawing glitch as well and fixed that on top of it.
Video of current build:
As you can see, you can push the boulders around now. They collide properly with each other and walls, but if you push one and there is another boulder it will not allow movement. I could allow that with one simple call change, but I'd rather not that sort of behavior. Also, if you can push an object, then you will also be able to pick it up. Right now it's a simple flag to see if something is pushable, but in the future I will change this to a check on strength and weight. The idea being that as you get stronger, you could eventually lift these and throw them at enemies, enemies might attempt to throw them at you, and because this works with any entity type, you could conceivably pick up and throw the enemies themselves... possibly even swinging them like a club or something.
And, of course, enemies will be able to do the same to you, though I will probably make that a very rare occurrence. Having an enemy prefer tossing and then giving them the ability to toss other enemies as weapons might be an interesting scenario, tho. Now big slow boss guy is tossing his henchmen at you, which then start attacking you if they aren't stunned for a turn or two....
I normally work on this on my days off, which generally happen every few days (I work an odd shift where I work a few days and then get a few days off rather than working on weekdays and having the weekends off). i did a little bit of work Wednesday, but I started thinking about the current state of the project and what is happening in the code. Thursday I spent the day kinda mulling over some ideas and taking some notes. Today I went back to work and took more notes on my breaks on what I'm doing here...
So I've decided to kinda rewrite the entire thing. See, I was planning on rewriting a chunk of the entity system due to my not fully understanding the system I had implemented, and I did it a bit on the inconvenient side. The solution is to rewrite that system, but that rewrite is going to affect like 5 other things. I started thinking about the other half of the program that I wouldn't have been rewriting, and it dawned on me that I was doing it kinda ass-backwards as well, in a very similar way to how the entity system was built.
So I've decided to rewrite it. And this has prompted a new debate in my brain: Stick with the ASCII graphics or take the next step and actually draw onto a window.
Now, I would still be using a similar method to all of this: It's not going to be some OpenGL or DirectX sort of system. I'd be drawing more or less the same way, but with my own graphics instead of ASCII art. It would require different code, but would probably be a very similar approach. 'Probably'. It would also sorta force me to use a better input method as well, as the method I was using was actually sorta not kosher for working with a window.
I may or may not. I'm going to look into the feasibility of it at my current skill level. The major hurdle to programming for windows is that the people who designed the windows API were all apparently smoking crack, because the API does things... Like they created a bunch of basic variable types (like 'int, bool, char, etc'), but they reused the same names, but they changed what they actually do. In C a bool is a variable that is either a 1 or a 0 - yes or no, true or false, on or off. In the windows API, a BOOL is an int. There are five different types of char, and they all start with 'char', except one of them doesn't. And then there are unions of them, so another kind of char can be either of a couple of types of char. Shit like that. They currently hold my own personal award for most convoluted API.
That said, it's something I'll have to tackle eventually, anyway, and it's likely that I'll only have to really deal with a tiny bit of their API, since once I can blit an image to a window I'll be able to do everything else with my own code, anyway. This will also make the interface a bit easier to deal with, and I'll be able to provide mouse control for menus and shit. Would be nice.
So I'm seriously considering it, given that I'm going to be rewriting a large chunk of this thing regardless...
I spent today thus far getting a library to work properly. After looking into it a bit, it seemed very much like going through the windows API was going to be a big hassle. I haven't mentioned my difficulties with SFML in this thread, but that was the library I made my first attempt on this whole game programming thing with. I had been promised that it would simpify the process. This, however, is true only if you accept doing things their way and don't have a problem with forcing your users to install a bunch of superfluous libraries (including the MSVC libraries). I don't like that kind of thing, but my attempts to compile that particular library ended in frustration. I think the culprit was their exception handling, which sorta forced me to either compile their entire dependency chain as a single, massive static library or just force users to install all of that other crap.
Yesterday, tho, it dawned on me that I could simply cut out the middle man and simply use the same OpenGL library they use. It doesn't have the same sort of dependency issues, and it requires only OpenGL to compile (which is distributed with most systems and graphics drivers anyway...)
So I got FreeGLUT and built it and had nary a problem getting everything set up and running. So I'll be learning OpenGL and will use it as the basis for the graphics in the game. This will allow me to avoid dealing with the hassle of the Win32 API, which is nice, and the library already has a lot of useful functions for loading images and drawing everything. Going to eat and take a break for a while and then take a look at some of the basics of this library and start writing some of the basic elements that I'll need to get going with the game. I should be able to port most of my existing code over to this once I get the basic things rewritten for graphical elements rather than ASCII art.
EDIT: I will, tho, probably rewrite everything as opposed to trying to port the code over.
Yeah, definitely. Now that I have the basic structure of the game down, I'll know exactly how to make the various little systems to get them all working with each other nicely. Once I figure out how to get the drawing of things to a window happening and have a system up and running to draw things to that window on command, I should be able to get the game back up and running to the point where I left off fairly quickly.
And with the different approach to the entities that I'll be using instead of the old system, it'll be that much easier to expand the game and have more stuff happening.
The OpenGL part of the game will be its own little thing. The rest of the game won't really be able to tell the difference between drawing stuff to the new system and drawing stuff the old way. It'll just be handing over a little image file instead of a text character.
Keeping the ASCII characters for drawing for the time being. I've rewritten the entire thing with a few copy/pastes and alterations. The way that drawing works now is completely engine agnostic. I can rewrite the buffer system for a normal window, OpenGL or whatever else I want and the game will still work. I've included some extra values in the map tiles for future use if I do swap out a normal window and tile graphics.
The only actual bit of the game I'll have to change to swap the drawing code is the tile map tile drawing code and the graphics component for the entities. Everything else will not need to be touched.
So now I've just got to write the new entity / component system, and I should have it back up to where it was before shortly. It should be noted that there will also shortly be player stats going on in the left-hand side of the shots I post, as that system will be extremely simple to add now, as well as event messages at the bottom. It's probably going to be actually playable soon.
Tried some more interesting lighting. I don't like it, so I'm gonna undo all of that.
I also managed to add some inconsistent bug that's crashing the game if I try to change the size of the view radius, sometimes. Every attempt to run the program works, but as soon as you use one of the keyboard commands that alters the radius of the player's view area it just shits the bed. Not sure where that one's coming from, though I'll be honest here and say that I was very eager to get something more interesting looking. A lot of this code is probably going to get thrown out. I've got some really hacked in shit going on right now. I've got to get a handle on my systems...
I also really need to wrap my head around Bresenham's line algorithm. Something about it is making it impenetrable. I hate other programmers. I try to write code that you don't have to comment. It tends to be more verbose, but I can go back and read it a month later and know exactly what's happening. I give things descriptive names and try to write it in such a way reading the code is kinda like reading really broken english.
Other coders, however, abbreviate everything and then combine multiple abbreviations into variable names, so I have no idea what half of the variables in a lot of example code 'mean'. They all get lost in my brain in a jumble of random letters. Either that or they name a class Class and then make a Class called class and then make multiple of them, so you have Class classA, classB. Or they 'demostrate' things by using 'foo' and 'bar' and then start doing Foo* foo = new Foo bar... It's fucking annoying to try to learn a lot of C++ shit on the internet.
Doesn't help that they often want to show off how awesome they are at programming, so they'll try to cram like 5 things onto one line of code... I dunno...
Bresenham's algorithm will be used for lighting and line of sight. It will look cool, if I can figure out how to code it.
So I'm going to change this up. Been playing about with SFML to familiarize myself with it. For now I'm still in a very experimental phase and playing with things, but I'm going to be switching this up. Instead of a turn-based roguelike, it's going to be a realtime action-y rogue-lite. This is sorta the game idea that gave me a mental breakdown a while back
Anyway, I think I've got a much better handle now on the fundamentals, though I'm not going to worry too much about making progress on this game in the immediate future and instead focus on the individual aspects. As I get elements working separately I will implement them into the game itself. I'm also going to be putting this up on Git and will attempt to be more organized when it comes to keeping my files nice and structured.
I also want to practice building objects that are fully independent of each other. For example, this screenshot features an image management object whose job is simply to store the texture images and keep them in memory and then hand then out using a keyword. It's nice and small and simple and it will prevent me from ever losing track of a texture's memory location.
I've got a series of steps I wish to implement things in that hopefully makes sense. I'm going to get one aspect working smoothly and then move on to the next. The benefit to this, I think, will be that with the systems I've got planned, I'll be fleshing out the entity system by adding things like camera movement and parenting. I'll be able to use those systems on any of the other entities later.
I'll post some mockups and some other crap later on. I have a simple goal for the next couple of days that I'm gonna try to hit.
As it currently stands, I've got a window that currently supports three resolutions and fullscreen mode. My goal is to have a basic test map (no collisions necessary), a simple player object that will accept input and move around, and a camera that will follow the player and scroll the map.
I can't imagine a turn-based Diablo. Would have been weird.
Diablo is definitely one of my favorite games, tho, and I often go back and forth with myself on which is the better game, the first or second Diablo. The second had more variety and the expansions especially added a lot of additional mechanics to that game, but the original has such a simply perfect purity to the mechanics, and the mechanics are so perfectly tuned, that the debate in my head can get quite heated
Personally, I think the second game is better, but only if you include the expansions. Base Diablo 2 is just a tad bit not quite so good as the original. The horadric cube is really the thing that gives the original Diablo a run for its money. If that was something only found in an expansion, then Original Diablo would beat it hands down.
First version with something that happens. You can scroll the 'map'. Choppy-looking as fuck right now, but I just hacked it in through the 'event' code, not through actual game code. I have to write a proper 'camera' system, but I can't really do that until I start getting entities in, cause it'll be mostly tied to the player.
Drawing a 100x100 tile grid (10,000 tiles), but culling them down to around 240 or so. When I'm not recording it manages to get itself up over 1000 FPS, so I guess the drawing is about as optimized as it's gonna get for now.
Need to rewrite the tile object to support animation and give it a few more variables, but after that, the tile code will be more or less finished and I can flesh out the map code a bit and generate a nice little testing area to start working on more interesting stuff.
Using a tileset I found on the interwebs. It'll look more pretty maybe tomorrow. Probably not by much, tho
I was working on some animated tile / sprite stuff, and I think I stumbled upon a really interesting way to generate tilemaps programmatically rather than adding things my hand. That way, I can use a basic txt file (like xml or something) to define a bunch of tiles by name. The game would store these as a tilemap, with the references to the texture coordinates of each tile. You could add the tiles and keep track of stuff by name, as well as set up their collision areas. It would require a bit of a function to load all of the bits and store them, but you'd end up with a tilemap object that would store a big-ass list of tiles. You could then use a similar method to define the actual map, by referencing which 'tilemap'(s) you want to use (so that you could, for example, have themed areas that would have different types of ground, grass, rocks, decoration, etc, but you'd still be using the same tiles for certain elements.
Honestly, I think I might be leaping a bit too fast before I plan this shit out a bit. I thought I had a solid idea on paper, but it's one of those things where I keep thinking of ways to improve stuff.
It all boils down to data storage and retrieval and how easy it is to manipulate that data. I'm inclined to sorta rewrite the 'world' I've got thus far, as an object which does absolutely nothing except store and retrieve the data for various aspects of the game. IE, not at all object oriented, but instead a more data-oriented approach. Still using classes, but where the class methods would be mostly used to gain access to data references that would in turn be handed over to plain-old functions.
I really need to sit down with some paper and plan out the way I'm storing data (again), cause I don't want to sit here recoding shit just to alter the tilemaps / maps / animations / etc. I need to have systems to load and reference that data automatically. Then I can pretty easily make and alter the tiles, maps, animations, sprites, etc without having to recompile or rewrite the texture coordinates for each tile or frame of animation if I decide to change something later.
I would spend all of my time just doing that and not writing the game's systems...
1) This larger project is going on hiatus for the time being: The reasoning behind this is that I dislike the way SFML does things. I have a vision in my head of how the drawing, updating, etc functions should be working in my games, but SFML is written with in a very OOP / polymorphic / inheritance sort of way. Trying to get a component system running would require me to write entire chunks of code that would essentially be replacing their code. After thinking about it for a while, the best solution was to simple use their OpenGL context to write my own direct draw calls straight to the OpenGL buffer(s).
Since that is the case, I figured it would be a good idea to circumvent SFML entirely and simply create my own, simpler context without all of their weird OOP overhead. I don't want to use their library this way only to find later that there's some other section that I need to entirely rewrite.
2) I need more practice writing the necessary systems: It would be nice to have some much smaller-scale systems under my belt before I try to tackle something that complex. I haven't really had too many problems with the systems thus far, but the previous turn-based incarnation went through multiple rewrites due to my inexperience with these systems. I figure I should back the fuck up a bit and implement all of the necessary systems in smaller games that won't require that they be horrible complex and massive and scale up the complexity as I go.
So for now I'm going to create much smaller games that are finished and polished. These smaller games will have a growing level of complexity to them, or they'll achieve some coding goal for me. I'm going to start with a simple Breakout clone. I already have a basic framework of the application in place.
All of the games will be part of one app, so I think from now on I'll just update the thread whenever I finish one of the games and make the binary available so you can try it out if you'd like (and probably experience bugs that I missed ). So that's the plan for now.