|
341
|
Player / General / Re: Fight Thread Pollution! Post here if it's not worth a new thread!!!
|
on: September 02, 2011, 11:32:35 AM
|
the purpose of that post i made is to kinda make fun of that video, which he read cthulhu as Ga-La-Thoos-Teh. well i suppose everyone have their own pronunciation. for me, Thool-Hu, or Chool-Hu.
That channel is a joke - he intentionally mispronounces every word he puts up. He pronounces "bruschetta" as "bron-TU-pis-to". Unless, of course, you already knew that, and I'm just misunderstanding you.
|
|
|
|
|
343
|
Developer / Technical / Re: What are you programming RIGHT NOW?
|
on: September 01, 2011, 09:44:22 PM
|
 Tiles don't block yet, but it's running smoothly and colors are blending nicely. You can change a light's intensity, too, making it bright center larger and causing the curve to black to become harsher. Now I need to figure out how constant directional lights will work. Hrm.
|
|
|
|
|
344
|
Developer / Technical / Re: What are you programming RIGHT NOW?
|
on: August 30, 2011, 12:43:48 PM
|
|
Nix, after looking at your video, everything looks green. Ow. Neat, though. I'm working on 2D tile-based lighting. Each tile will be able to block different amounts of light. Not exactly realistic lighting, but it should look nice enough.
|
|
|
|
|
345
|
Developer / Creative / Re: Can I finish my game in a week?
|
on: August 30, 2011, 10:26:28 AM
|
You should tone down the saturation on the pink a bit.
That's a screenshot of Commander Keen, not of this game. It's been out for 20 years now, so it's a little late to tone down the saturation on the pink.  Telenauts is looking great! Hopefully we'll be able to play it soon.
|
|
|
|
|
347
|
Developer / Technical / Re: Flixel, Flashpunk or Unity? Or none?
|
on: August 23, 2011, 06:33:04 PM
|
|
I guess the main thing with Flashpunk is that it speeds up development time a bit since you don't have to worry about the engine as much. If you're looking for an "express" way of doing things (which appears to be the case), there's not much reason to avoid using a pre-made library.
|
|
|
|
|
348
|
Developer / Technical / Re: Auto-Tiling: Let's Discuss It
|
on: August 23, 2011, 12:09:47 PM
|
|
Yep, mine has to look through a list of all possible cases for every tile. Obviously, that makes it a bit slower, but it does allow for things like optional cases (which has saved me a lot of time) as well as some other things I added in like tiles being able to automatically add each other and having different layers of tiles.
|
|
|
|
|
349
|
Developer / Technical / Re: Flixel, Flashpunk or Unity? Or none?
|
on: August 22, 2011, 11:01:22 PM
|
|
I can't speak for Flixel, as I haven't used it yet, but Flashpunk is a great tool for quickly putting a game together. It gives you the basics of a game engine (collision detection, rendering, animation, basic entities) and lets you go from there. It's a simple enough library that it's incredibly easy to modify, so as long as you know what you're doing, it's not hard to add or change features that it already includes. For simpler projects, you might not even need to modify the basic classes, as they're set up to be extended pretty easily. I'd definitely give it a try if you've got some programming experience under your belt (which it seems that you do).
Unity is also quite nice to work with, although it's definitely a more complex system than FlashPunk (and as a result working with it feels a bit less "traditional"). It's best suited to 3D stuff, though, so unless you can make or otherwise get your hands on 3D models, you're probably better off with Flixel or Flashpunk.
|
|
|
|
|
350
|
Player / General / Re: Human Hugs
|
on: August 22, 2011, 12:36:57 PM
|
Smithy, that sounds like something straight out of The Daily WTF. Sorry to hear that. At least you can know that the kid is probably going to have a really awkward time from now on.
|
|
|
|
|
351
|
Developer / Technical / Re: Auto-Tiling: Let's Discuss It
|
on: August 18, 2011, 08:55:57 PM
|
Alright, here's the post I promised. Instead of using lots of if statements, I came up with a way of using bitfields for this that makes life a lot easier in the long run. Each of the eight adjacent spaces to the tile are represented as a power of two, from left to right, top to bottom, like so: When a tile is placed, it checks the spaces around it, combining them into one value using bitwise OR. So, a tile which has another tile to its left and one below it would be represented as 01001000. Then, the tile checks itself against a list of all possible "cases". At its most basic level, a tile case has three values: its filled tiles, its optional tiles, and the sprite index that it's associated with. Filled tiles are which surrounding spaces much contain a tile, and optional tiles are which spaces may contain a tile or not. The optional tiles make things a lot easier to manage, as you don't have to create a huge number of duplicate tiles for all possible cases. That said, it means getting a wee bit more complicated in checking whether the current tile's situation and the potential tile case are equal. To check whether a potential case fits, I do this (assuming "filled" is the current tile's filled adjacent spaces, and "case", containing "filled" and "optional" is the tile case we're checking against): if ((filled | case.optional) == (case.filled | case.optional)) { //This case is a match, so set the tile's sprite. } The way this works is (in case you're not familiar with bitwise operations), the "optional" spaces can be ignored, so due to the bitwise OR they're set to 1 on either side of the equality operator. For instance, let's say you have the same tile situation as before (01001000) and you have a tile case that must include a tile below it (01000000) and can optionally include a tile anywhere above it, or to its left (0001111). 01001000 | 0001111 = 0101111 and 01000000 | 0001111 = 0101111 so it's a match! The nice part about this is that you can easily make your tiles defined from a text file once you can get a parser working. I've got a little format to define tiles like this: (7,5) { --- + + *** } The tile's index within the sheet is given between the brackets, and then between the curly brackets is which spaces around it are filled ("+" meaning there must be a tile, "-" meaning there must not, and "*" meaning it's optional). The main downside of this is that it can be a bit slow to sift through a list of tile cases to find matching tiles when there are a lot of tiles being placed at once. There are probably some ways to optimize this that I haven't thought of, though.
|
|
|
|
|
352
|
Developer / Technical / Re: Interesting Programming Problems
|
on: August 18, 2011, 03:10:11 PM
|
Sure, that sounds great! I'd be willing to share some of the inner workings of my system. I'll come by later and talk about it a bit if you've set the topic up (or if not, I'll just start the topic) - I'm working on some other parts of the system at the moment. 
|
|
|
|
|
354
|
Developer / Technical / Re: Interesting Programming Problems
|
on: August 17, 2011, 02:37:13 PM
|
I've been having some fun recently making a system that automatically chooses a tile's sprite based on its surroundings. My artist ( capnbubs) gave me a sprite sheet to work with and I thought this would be a neat project. It's lots of fun to platy with now that it's working! It sounds simple, but it really isn't! The complicated part is that, to make things look nice, some of the tiles are made up of a solid ground tile, then a small, rounded patch of dirt on top. I ended up coming up with a method of defining each tile and when it'll appear, as well as what tiles it'll add. On top of that, some tiles need to add multiple generations of tiles (mostly for the background - you add one tile, it adds 8 more tiles, then those tiles each add some tiles). But all of those tiles need to interact differently depending on how many ancestor tiles they have, so I added a "generation" system to the whole thing. Different tile types also need different layers, too, like the aforementioned background, or grass growing on top of the dirt. After a bunch of work, though, it's working pretty nicely: I can just define the shape of the terrain, like so: http://dl.dropbox.com/u/2149322/TileEditor/Ground0.pngThen it places all the dirt looking nice and interconnected, as well as automatically adding background tiles: http://dl.dropbox.com/u/2149322/TileEditor/Ground1.pngIf I want to, I can just switch layers and put some grass on top: http://dl.dropbox.com/u/2149322/TileEditor/Ground2.pngAs well, since I made all the tiles dynamically connectable, you can extend the background beyond its default placement if you want to! Take these tiles, for instance: http://dl.dropbox.com/u/2149322/TileEditor/BG0.pngI switch to the background layer and drag out a shape: http://dl.dropbox.com/u/2149322/TileEditor/BG1.pngAnd the result is a fully-connected background! http://dl.dropbox.com/u/2149322/TileEditor/BG2.pngAll of this tile data is being read from a human-readable, 37-KB text file (although it's growing rapidly).
|
|
|
|
|
355
|
Developer / Technical / Re: Updating saved data
|
on: August 14, 2011, 08:16:32 PM
|
|
You could include version information in the save file's header. That way, when you update to a new version, you can convert the save file to its new format before saving. Or am I misunderstanding you?
|
|
|
|
|
358
|
Developer / Technical / Re: Copying Code
|
on: August 14, 2011, 11:21:40 AM
|
|
That isn't the same code, then. Unless it looks like you directly copied and pasted code out of Spelunky, you're probably okay.
|
|
|
|
|
359
|
Developer / Technical / Re: Copying Code
|
on: August 14, 2011, 10:58:16 AM
|
After Mikademus pointed that out, I checked the download for Spelunky's source code. It comes with "COPYING.txt", which actually tells you the license. You may want to read that. The important part is this: You may modify and redistribute the Game and its Source Code under the following conditions: You may modify and redistribute the Game and its Source Code under the following conditions:
(1) This license and any appropriate copyright notices in the Source Code are kept intact.
(2) You may not sell Covered Works.
(3) You must display an appropriate copyright notice somewhere in the beginning of all Covered Works and in any documentation accompanying such Covered Works.
(4) If you share a modified version of either the Game or its Source Code with others, you must not present it as an unmodified, or official, version of the Game or the Source code. Please make it apparent that it is a mod. So, you may want to make sure that you're not directly lifting any code from the source.
|
|
|
|
|
360
|
Developer / Technical / Re: Copying Code
|
on: August 14, 2011, 10:10:50 AM
|
|
I don't think anyone is going to decompile your game and accuse you of stealing Spelunky's code.
|
|
|
|
|