I had some free time so I started work on my pathfinding for actor entities. Right now it’s barely functional (the actors can’t deal with obstacles yet and i need to cap path computation times).
When you select an actor then click a tile, it runs a function which computes a path to the tile (in the form of a queue consisting of tile objects). Then the actor starts de-queuing each tile and transitioning from tile to tile until it empties the queue. If a tile becomes impossible to traverse, then the actor will stop and re-call the pathfinding function, rebuilding the queue of tiles. For now, that doesn’t happen. It’s next on my todo list.
At this point i think i’m going to decouple pathfinding from actor entities and make an AI class for it because it’s becoming increasingly complex.
I finished more stuff. The white square up there is the cursor. I don’t have any cursor sprites (yet). Still waiting for the monogame update.
The yellow drawings i made there were a result of me testing my fully functional unit/tile selection code. And that dude in the top left corner is a (very crude) actor entity. It doesn’t do anything yet.
Redid the grid system, hopefully this will be the last time i have to do this. The grid is now an 8x8 2d array of chunks which are 256x256 tiles. At most, there are 4 chunks active (within camera view). All other tiles are made inactive until the camera moves within their visible range.
In the image above, the tiles are colored to show where chunks begin and end.
Ideally i was going to make the grid much larger but that would also bring in new issues. I’d run out of memory if i had more than 64 chunks and i would inevitably have to delete chunks that aren’t active then load them when the camera enters their visible range. So for now i’m going to stick with 8x8 (which is still pretty dang spacious).
I have put the sidescroller on hold for several reasons. The main reason being, i had no clear idea where i was going with it. I had ideas of what i wanted to implement, but overall it was a giant question mark. Sometimes that’s a good thing, in this case it wasn’t.
I’ve been doing a lot of the tedious boring stuff recently. I wrote an attribute system for entities and made them serializable. My next order of business is making a simple level editor. Instead of making a separate modding toolkit for this game i figure i might as well just build it into a developer menu since it’s easy.
No matter how i slice it, i’m going to need to implement a bunch of GUI stuff. I guess i’ll go with Winforms. I have no idea what i’m doing.
I Frankenstein’d the final product from several different sketches. I don’t own a scanner (i had to hold my webcam steady and take top down photos of each drawing) which explains the differences in color. If this looks like it was inspired by Earthworm Jim or something similar then that’s probably because it was.
For some god damned reason i can’t draw normal hands to save my life. I also can’t draw hands directly from an arm, i have to draw them separately then splice them in and re-scale them using Photoshop. The gun in his left hand was also drawn like twice the size it needed to be, because i’m cool like that.
More progress with player movement. Those two orange rectangles you see covering the blue bouncing rectangle are actually not colliding with anything, they are sensor bodies that tell me whether the player object is on the ground or touching a wall (which is why i can bounce off walls, that was intended). Normally they would be invisible, i’m just drawing them because i want to be sure they’re scaling properly based on the size of the physics entity they’re parented to.
The movement needs fine tuning but otherwise i’m pleased with the results.
I finished an input helper component which should come in handy for several things. I can’t see how anyone can program a game without using a component-based architecture… It’s messy enough with everything compartmentalized, I can’t imagine how much of a mess it would be if it weren’t.
This isn’t a very exciting update to look at but there’s a lot of stuff behind the scenes being completed! I wrote a basic EntityFactory and EntityManager class. Now i can go hog wild creating new entities.
I’ve also been working on a entity hierarchy. In my previous blogs i wasn’t actually using entity factories or my own entity classes so it took like 30 lines of code to just create one object, and then i had to write the code that draws the object on the screen. Now i can create an object in one line of code and I don’t have to worry about manually drawing it to the screen.
I need to figure out how to go about properly deleting entities. Right now, my EntityManager keeps a list of all the crap i’ve spawned into the world. If i delete an object then i also need to remove it from the EntityManager’s list (and if it’s a physics entity then i need to delete its physics object too). If i have a pile of objects being deleted at any given time then this could be a problem. Right now i’m using a List class to store all the entities and using List.Remove traverses the entire flippin’ thing and removes the specified entity when it finds it. This isn’t so bad when i only have 10 things, but let’s say i have 100+ entities and i’m removing a bunch of them in a given frame. Suddenly i’m looping through this entity list way more than i should be.
So maybe i should be looping through the list each frame and just removing any object that was deleted instead of calling List.Remove every time i delete something. I have a headache and i’m tired so i’ll leave that for another day.
Also, I have some juicy concept art that i figure i might as well post so expect that sometime in the future i guess?
So i got the main menu and buttons working exactly how i wanted them to. Right now only the New Game and Exit buttons work. If you click New Game, it transitions to the game screen and spawns a player object. And the exit button speaks for itself.
I think i’ll worry about getting a proper font and making the buttons look nice when it really matters. For now i want to flesh out the more important things. Oh, and it turns out there is a way to disable rotation on physics objects completely so my player object is no longer a tumbleweed.
So i got some work done on my interface. Buttons in particular.
In the picture there are 4 buttons in total, they support images and text (and a combination of both) but for now i’m just trying to get them to actually function like buttons. I think i’m just going to make my own text system using images for individual letters so i’m not actually drawing any actual text to the screen.
It’s hard to choose a starting point when you start from square 1, there are so many things to do and it’s hard to judge which features should take precedence. So for now i’m just going to try and get the basics of the interface sorted out and worry about everything later.
So i’m gonna start doing lil bloggies about a game i’m working on because that’s what cool people do, and it’s also fun to track progress and show off your half baked stuff.
If you don’t know much about computers then the next few paragraphs are probably not going to be a fun read so i’ll summarize what you’re looking at. The first picture is a box (with physics - you can click and drag it around with your mouse) inside of a small enclosed ugly orange rectangle frame. The second picture is just a bunch of textures being drawn to the screen (nothing exciting).
This project started out in VS2010 using XNA and an open-source 2D physics engine called Farseer Physics but then VS2012 came along and Microsoft stopped working on XNA. XNA still works but it’s officially deprecated, so i’ve migrated to Monogame which is basically a port of XNA that works on every platform (and works with VS2012 unlike XNA). Very cool.
I didn’t really get any work done on this when i was messing around in VS2010. I had no idea what i was doing so most of my time was spent learning C# (which is a cool language) and figuring out the architecture of the Farseer Physics test samples. When I finally got around to installing VS2012 i had to figure out how to make Monogame work with Farseer Physics. I was lost for a little while, so i messed around with SpriteBatches and managed to draw some crap (the red picture is the result). After a while i sorted out the physics engine. The solution was trivial, just had to replace the XNA references with Monogame references and it built without any problems. So after I got that out of the way i hit my second road block, I couldn’t do anything with XNA content projects in VS2012. Monogame will soon support content projects but for now I have to use a separate content project in VS2010 and build that every time i add new assets (textures, etc) to my game.
So, once i got those two things out of the way i could actually start writing the game. I kind of cheated and used the Farseer Physics samples project as a reference when I started working on my game. So far i’ve implemented a similar screen management system (most games use multiple “screens” - menus and pause screens and dialogues, etc.). And then there’s a lot of stuff behind the scenes that goes into actually setting up the “world” and spawning the low-gravity orange box you see in the first screenshot. It bounces around if you drag it with your mouse.
I guess my next task is to work on making the player object controlled by the WASD keys and make it so the player isn’t just a box that tumbles around (I assume i can just max out the damping on the box so it can’t rotate, or even just disable rotation or something). When you play super mario you don’t expect him to fall over and start rolling around like a tumbleweed, right? And then after that i suppose i’ll have to work on making the player object an animated entity with bones and joints and stuff. Plus everything looks like ass so i’ll need to work on some decent textures etc. So many things to do.