I moved to a new URL! Check it out!

posts tagged with: csharp

Dev Log: Example Game Arts

Dev Log: Example Game Arts
For my upcoming 2d framework built with C# and SFML I'm building an example game that at first was going to be a super quick project, but when it comes to art I'm still a little stumped on what the best workflow is going to be.

The game is going to be a little simple platformer, and if this were pixel art then I would have no problem just jamming out a bunch of pixel art for it... but with high res comes all kinds of problems.

I usually have used GraphicsGale for pixel art and animation, but now with high res Gale is no longer a very viable option. There's animating in Photoshop but it's horrible for animating. I really wish the animation options in Photoshop were better. There's tools like Spine and Spriter, but they're more for 2d bone animation and don't really help at all when it comes to frame by frame hand drawn animations.

There's also the problem of tile sets. With pixel art comes a very limited canvas site and color set per tile so making tiles line up with each other is a relatively simple task. When the resolution of color and canvas size increase then it becomes more and more of a pain to make each tile line up. I tried this with Snapshot but eventually I gave up and just faked using a tile set by making a bunch of independent images about the size of a tile and just stamped them on top of each other. Unfortunately right now that isn't an option for this game since I'm using Ogmo Editor as my level editor and strict tiles is probably my only option.

Here's a quick sketch of what I want the game to sort of resemble and I can already tell the tile set is going to be a nightmare because of the bleed of certain tiles (like grass, even stones have bleed, argh!)

Image


So that's where I'm at right now. I'm continuing to chip away at code somewhat as I think about how to possibly solve these art pipeline issues, and I expect to be done with the example game sometime next month along with the first public release of the framework.

Dev Log: Atlases

Dev Log: Atlases
Getting ready to head back home to Phoenix today after two weeks of being in the Northwest! I went to Seattle for PAX then up to Vancouver/Richmond to hang out at Indie House, and now I'm back in Seattle for a little bit and I fly out tonight.

During the week I was in Indie House I got a lot of work done on my upcoming 2d framework. One of the major features that I managed to get in is texture atlas support. Texture atlasing is pretty awesome and I'm surprised SFML doesn't have any cool built in support for it, but basically it's a way to pack all of your image assets into as few textures as possible to use in the game.

Image


I'm not super well versed on this kinda stuff, but apparently one of the most expensive things a video card has to do while running a game is switching which texture it's using to draw. So if you have a game that has 100 different sprites on 100 different textures, that can get kinda rough for the video card. However, if you can pack all those sprites into one texture and use just that one texture to get all the sprite data from, the video card only has to render that one texture (hopefully) so the performance is greatly increased.

This task had been on my to-do list for awhile but it wasn't until Saint requested it that I felt motivated to actually get it working. He was working on a little game in the framework as a test and it was super motivating (and also scary) to see someone using the framework! Right now the framework only supports the Sparrow/Starling export from Texture Packer. I'll leave support for more formats up to individual users after that.

I'm still busy working on my example game for my framework that will hopefully be done in a week or two. The major tasks for the rest of the game are just art, so I just need to buckle down and draw a whole bunch of stuff. Once the example game is done I'll be taking one last look at everything and then I'll make it public for anyone to use. There are some parts of the framework that are a little weird since I learned better C# programming practices as I coded it, so some of the earlier stuff probably needs some revisions, but aside from that this thing is almost ready to go!

Dev Log: Squishy Platforming

Dev Log: Squishy Platforming
I've been at Indie House Vancouver for a couple days now and my main focus is working on my C# framework with SFML. I'm working on a little example game that will hopefully show people enough stuff on how to get started with the framework and use it. When the example game is totally done I'm going to release it along with the framework all 100% open source.

Image


Right now I have some neat little platforming going on involving running, jumping, wall sliding, wall jumps, and a special skid jump technique sort of like Mario 64 but in 2d. Also to make the game more fun with rectangles I added a lot of squashing and stretching to the player rectangle with tweens. I am planning to do a full set of graphics for this game, but right now I'm focused on getting the whole thing playable before I tackle any art.

Today a whole crapload of people are coming to Indie House so hopefully I can make some more progress before the entire gathering turns into a TowerFall tournament.

Dev Log: Ogmo Integration

Dev Log: Ogmo Integration
I'm starting to put together a quick example game for my C# SFML framework during the Ludum Dare weekend of jam madness, and part of this will be Ogmo Editor integration, YEAH!

Image


Loading XML seems to be pretty straight forward so far in C#, but I do miss some of the XML features of AS3. Right now in that image I'm just loading a grid collider and a tile map from the XML data in Ogmo, and the green box is a player that can run around and collide with the tiles.

For this example project I'm just going to make a quick and easy platforming and collecting game. I want to make it as complete of an example as I can, and not just a single level room. Multiple levels, menus, saving and loading, stats... I want all that kinda stuff in this example so people can see a sort of "complete" game made with my framework.

I'm hoping to have this done fairly soon, but on Wednesday I'm taking off for PAX and I don't think I'm going to be working on anything during those four days of insanity.

Dev Log: Screen Scalin'

Image


Look out, it's a 6mb animated gif! Another thing off my task list was scaling the game window to different resolutions. I wanted to keep the same stuff on the screen as I scaled the game window up and down (since I imagine people will want to play games at varying resolutions) so what I'm doing right now is just scaling a render texture to the size of the window. I guess we'll see how horrible or okay this approach is soon enough.

I've been trying to figure out the best way to start making assets in terms of their resolution. Right now my idea is to just pick a resolution that the game will natively be in, like 1920 x 1080, and just make all assets as if the game is being played at that resolution. Scaling that resolution up to 2440 x 1440, or down to something like 720 x 480, doesn't seem to be that bad. My only concern is keeping text readable at low resolutions, so I might have to do some extra work to maybe change fonts or text sizes depending on the resolution.

Image


For Snapshot, we just chose a virtual resolution of 1600 x 1200 and made all assets as if the game was being played at that resolution. This seemed to work out okay in the end, but we did spend a lot of time at the beginning of the project trying to figure out the best solution for this issue. If I were smarter I'd be doing something like having assets for different resolutions and loading the right one depending on the resolution but I have no idea how to do that for now so I'll go for the short and simple approach!

Dev Log: Collisions!

Dev Log: Collisions!
I'm back working on my C# and SFML framework after many weeks of very very slow progress. I've been tackling all the different kinds of collision detection that I want to have, and although the rectangle to rectangle collisions are easy, stuff like rectangle to grid started to get a little messy.

So then I got to the point where I wanted to add line segments and circles into the mix, and even with just these four types I found myself in a maze of code and math.

After trying to figure out some math on my own, I finally stumbled upon some line segment intersection code that helped out quite a bit. After I got that running, I was also able to find a line segment to circle collision example, and that gave me enough to fill in the rest of the blanks.

So now I have four collider types: Rectangles, Grids, Circles, and Lines, and they are all able to collide with each other. I haven't super thoroughly tested this stuff out yet though, so I'm sure some of it must be broken somewhere, but for the rest of the week I'll be testing this stuff out a little more.