A video game & software development blog by Christopher Horenstein.
Posts tagged Visual Studio
Workflow
0940 days
I’ve been integrating a lot of different little technologies to help me with the development of Ne+. One of the things I quickly realized is that my main source code repository is precious, something that I need to protect and keep clean while I’m creating a new feature or adding in some existing code. There are many ways that one can do this. Sometimes, you want to drastically alter your code and refactor many of your core classes or functionality to be more organized, or create a more streamlined design. It’s entirely possible to accomplish this without destroying your project. If you aren’t using source control, you’ve got bigger problems on your hands and should take care of that immediately. However, if you are using source control, it becomes infinitely easier to manage changes like these effectively.
I’m using Git for my project. With Git, the technique for developing a little something on the side, as opposed to in your main branch, is to just create another branch. It’s a simple concept – you’re creating another branch in your development road, one that could eventually come back to the main road, or lead nowhere. If it leads nowhere, you can delete it… otherwise, you merge those changes back into the main project and continue on. There are a few source control methods that contain this concept, but if you happen to be using something that doesn’t, make a copy of your project and do it yourself! The point is that you need to be able to experiment.
Another way to introduce a new concept into your project is to prove it outside of your project first, so that you’ve got some code you can use, as well as a general idea of how you might want to integrate it with your existing code. Create a new project and do the absolute bare minimum you need to in order to see the new concept working – this allows you a sandbox environment where you can do whatever you want. I have found it easiest for me to do this, particularly when I was trying to get the lighting involved with my project – it was easier to make it work on its own before getting it to play nicely with the camera and physics that were already in place.
If you have a nice environment for testing new concepts, I find that it’s much easier to keep from making your main project a mess. I also like tagging my code in source control at major landmarks. If the lighting is working for the first time, tag your project. If you got the bugs ironed out, tag it again. Leave some breadcrumbs, because you can’t be sure when you might have the need to retrace your steps later.
We have lighting!
0940 days
And I've only just started... I'd like to re-arrange the Engine a bit at some point.
Well, sort of. I have been working on integrating lighting effects into the game this week, and have expanded the engine components and arranged them, although I would like to move things around a bit. Currently, my Visual Studio solution is moderately small, although it does grow a bit every day. The engine’s organization is not something I’m completely happy with at the moment, although all of the function calls to it look how I’d like them to. The lighting effects exist now, thanks to an extremely helpful blog post on the subject and an example project showing the code needed to do this. However, the camera class doesn’t yet play nicely with the technique – I am still struggling with matrices and the associated jazz, so I am not sure what the best way to draw the shadows is – currently, they are being drawn at a stationary point, and I’m sure with a little testing I’ll be able to figure out exactly how I should draw them to line up with the rest of the things I’ve got working. Along with the lighting integration, I introduced a couple more of my first bugs – the Farseer debug view shouldn’t be affected by the lighting, so I’ll have to figure out how to exclude it. Also, I need to be able to draw my scenery and not have it obscured by darkness if I don’t want it to be. These things should hopefully be pretty easy to change, and will happen most likely within the next couple of days.
Moving forward, my plan is to fix those bugs and then start working on how to detect if an object is being touched by the lighting. From there, I can decide what happens if an object is indeed being touched by lights, and introduce the anti-gravity light! I also want to play with the lighting so that it is a little more dynamic as far as brightness, when it’s on, when it’s off, and so forth, all of which should be pretty simple. I just need to create simple interfaces to these things so that they can be easily manipulated.
One may note that I have not yet fully mentioned anything about Tiled, although the DLL is sitting in my project. Before the end of Sprint 2, which is now about two weeks from now, I hope to have integrated Tiled into the project in some simple fashion. I will be doing this most likely using TiledLib, which is an extension that was created with the intention of adding Tiled resources to the XNA Content Pipeline so that it is extremely easy to load Tiled maps into XNA projects, and also to provide a simple interface for accessing the data in Tiled resources. Tiled is a map editor that creates easy-to-read maps for projects, so basically I’ll be designing levels in Tiled and then reading the files in my code, and creating the game levels by positioning objects and creating their appropriate physics and lighting properties (and probably many other properties which I am not currently working on). I’m excited about using Tiled, because I have a feeling that it’s going to be a great editor that I’ll be able to use in every 2D game I ever work on during my own time. But I felt similarly about the engine I was going to use for my project, so we’ll see how it turns out in a few weeks.
The decision to be working with my own engine has so far been pretty good – I definitely like having full control over the major aspects of my project. The Farseer physics engine is still a blast to use now that it’s working, and so far none of the components I’ve brought in from outside sources have limited any of my abilities to do exactly what I want to do. That’s a nice kind of freedom, and now that I’ve been enjoying it it’s hard to imagine wanting to use a full-fledged game engine as opposed to pulling together separate components and gluing them together however I see fit.
It's nearly working. The platform that the box is sitting on should be visible, which I still need to work on. Click the image for a video.