Sarah and I are visiting her family, but in some of the downtime, I've been able to figure out a large portion of the autotiling code. Later I'll add some code for the inside corners, but I'm not worried about that right now.
For now I have some basic tile placeholders. Not 100% happy with them, but I don't feel it's necessary to have them perfect at this stage in the game development. I think a tile graphics overhaul may occur late in the game, so I'll worry about it then.
I have designed the menu to shift screens underground, descending deeper with every option selected. Eventually, these backgrounds may incorporate items or dynamic players / monsters that will move about in the background.
Now I'm trying to hash out some code I redid for the player graphic to make it easier to create non-controllable players (for the player select screen and multiplayer player entities (no I did not stutter). In the meantime, I'll just dabble on the code when I have time, and fill you in over break!
As I have posted previously, I started using Game Maker which has built in multiplayer functions.
Correction, it DID have multiplayer functions before coming out with the Studio version, which they declared them to be obsolete. Multiplayer functionality may not come out in Game Maker:Studio until late next year!
I was very... frustrated... to find this out last night as I looked for the correct functions to start adding networking to my game. I wanted to start adding networking as early as possible to avoid having to re-code sections of the game I create. I'm going to have to set networking aside for now and just focus on solo-play at the moment, which is fine; there is plenty to develop.
My list of things to do:
Title and Main Menu - Basic functionality almost complete
Game Setup Screen and Multiplayer connection - On hold until Game Maker supports this.
Player Actions (punching) - Complete
Multiplayer Chat - On hold until Game Maker supports this.
Other players appearing on screen - On hold until Game Maker supports this.
Inventory screen and handling - Complete
I'll turn my focus now from entirely networking and functionality to include content and visuals, including:
Additional Tiles and Textures
Autotiling Feature
Health, Magic, and Money
Health and Hotbar HUD Display
Wearable Items (No more nude player!)
On a good note, before YoYoGames comes out with network capability for GM:S, they will be adding shader functions. This means shadows and advanced lighting would be possible again. I might be able to keep the torch item after all!
Currently working on a Title Screen and Main Menu, which will lead me to creating network connections, which will lead me to creating multiple instances of plays on screen, chatting abilities, etc. AND will give Alpha testers something to play around with.
Of course, I also want things to look somewhat decent, so I'm putting a little work into auto-tiling and will soon create something other than these darn purple bricks. Dirt, stone, sand... anything non-purple.
Imagine walking away from your computer and this is all you see.
On a completely unrelated note, here's a quite humorous list of unrealisms in video games.
I've been working, almost daily, little by little, on the game. I now have an inventory that almost works the way I want it to, and I've started player arm animations. About 90% and 15%, respectively. Once they are done, I'll throw together a basic menu and see if I can get a network connection with functioning multiplayer chat. What fun!
Welcome to Game Maker, Descend!
I have also started putting together a GDD, or Game Design Document, to keep track of my ideas. As much as I DON'T want to do it, I think it just might be a good idea in the long run. The biggest reason I don't want to do it is because the time I spend on that document is time I could be using to code the game together, however, I guess it's still all progress on the final result. Right now, it's just section headings, and is about 10 pages long.
As I complete it, is anyone interested in seeing bits an pieces of the GDD?
Things are moving along smoothly in Game Maker. It is quite simple, as I learn to use it. I've already have a little guy with arms and a rotating head who jumps about and collides into walls. Next up I want to tackle opening the inventory, picking up and storing objects, and being able to move them about in inventory (or dropping the items back to the world).
I'm reluctant to share any pictures/video for a while, since everything I'm doing, you have already seen and more. It will be interesting how guick I'll be able to catch up with this system.
The following objects need to be done before I feel caught up:
Title and Main Menu
Game Setup Screen and Multiplayer connection
Player Actions (punching)
Multiplayer Chat
Other players appearing on screen
Inventory screen and handling
Not that i'll be doing any of those things in that order. I also may work on some new content before finishing all of those.
Best part about using Game Maker is it is supported by steam. I can release free demo/incomplete games on the Steam Workshop, for everyone's access. However, I'm not sure how to approach this as closed alpha testing. Maybe I'll just have to make a private Drop-Box location for testers.
This blog has been dead for quite a while. Some of the readers that I know personally know why.
As I tried to hash out the lighting in Descend, I found the whole system was slowing down. So while trying to figure out if I should scrap the lighting system, I was thinking about my approach to creating this game. I feel full heatedly that I could to everything I set out to do in the game with my abilities in coding in C# and using XNA. However, I have other things I like to enjoy doing, involving music, friends, and my fiance. So I stopped, setting down the game to pursue other hobbies.
However, my love for problem solving keeps pushing me back to coding. I've researched a handful of game development tools looking for an easier way to handle a 2D multiplayer platformer game. At first I was looking at Unity. It looks great, it's easy to use, works with C# and ports out to many systems. It's great with 3D graphics and is set up for game development. However, it extremely lacks in 2D gaming support. People have found ways around it, but the more I tried it, the bigger the headache.
Recently I have been trying Game Maker by YoYoGames. I'm weary as it has it's own handful of issues. They created a game development studio that allows even a caveman to put together a simple game in about 5 minutes with drag and drop features. It only works well with 2D graphics and uses it's own coding language. It has multiplayer support and many built in features that should allow me to create the game faster, not having to worry about the little things. The code language isn't hard to follow, and you can expand the program's capabilities greatly through adding your own code.
Well, we'll see how it goes. I'm starting from scratch, but I'm hoping I'll catch up to where I was before in no time.
Two terrible titles to make up for the missing title of the last post.
Moving along. First, I was testing the order in which light scans occur by starting dark and getting lighter for each ten "pixels" scanned, the restarting. Working properly, it looked like this, and was pretty cool, so I took a snapshot.
Groovy
I will note that the program scans in octants, 8 traingular sweeps ouward from the center of a light source (our player, at the moment). This picture shows the lightest points at the beginning of the sweep and darkening at the end of the sweep (light multiplied by angle).
This was closer, but I found 4 points where the light overlapped still, and corrected it. Now i need the bricks underneath to block the light.
Next, I wanted to see where the scans first detect shadow. There seems to be some sort of offset error I need to fix, but it's close to correct. Here's a video that is somewhat interesting!
More pics to come, as I code.
Saturday, July 14, 2012
I'm getting closer. I formed a method that involved drawing small squares of different shades over and over, reducing my game's frame rate to 13 frames per second. Scrapped that idea.
Now I have figured out how to manipulate the pixels of a texture, so I am drawing a small texture, scaling it to cover the screen, then blending it with the image of my world. A lot faster, keeping a smooth 60 fps, but there are some alignment issues. And my code is messy as hell. I need to re-code my light-mapper, then tackle the issue of misalignment. From there, I should be able to manipulate the pixels in an efficient manner and start the core shading code.
Shading is a totally new thing for me, and I need it to fit the image of the game properly. Been doing a lot of research, and found that it will take a combination of recursive shadow casting and alpha blending (oooh! Big game concept words!). It's pretty interesting how it's done, and looks somewhat complicated, but should work for what I have in mind, keeping a pixelated look, while enhancing the experience with color and shadow.
This is the article I found most helpful.. What? But your game isn't a rouge-like!
Hardly anything happening right now in my game development right now, and I know why. The render target method of re-sizing the screen and making the game available in different resolutions requires some re-coding that I wish I didn't have to do, so I've just been sitting on it. I need to stop sitting on it, because I want to continue with the more exciting stuff, and not working backwards.
Sorry guys. First step to fixing the problem is admitting you have one. My lazy frustration is getting in my way.
Edit: I'm coding today. Going to attack dynamic lighting right after equipping items. Two birds with one stone, when you're designing a torch. Oh... and expect some particle engine work too. I want my torch to burn!
In my research about lighting and different ways to go about dynamic lighting, I came upon something that I hadn't self taught myself about - Render Targets. They solve a huge issue with my game, and I have not built my game on them, so I'm about to start a (hopefully not so huge) overhaul of the game code.
Basically I've been writing my code to work in two forms. One that is twice as big and pixelated (the way I want it to look) and regular size, so that it may be possible to play with things small, but looking sharper. I did this by setting a 'scale' variable to work at x1 and x2 and had everything viewed in the game shift that much.
With Render Targets, I can take a snapshot of the entire screen (in my case, the screen would be small), and blow it up twice as big, or any size really for any screen, any resolution. It seems so easy. It solves all the pain-in-the-rear math of moving things twice a distance with larger sprites, and makes it easier to create multiple screen sizes.
I've been doing a lot of research to try to get smooth movement to work. It's not, and I want to move on. For now, I increased the updates to 20 times per second and I'm connecting them linearly. It doesn't look that bad, so I'm moving on. Sitting idle too long on one subject is killing my momentum, so it's time to look elsewhere.
I'm going to add some server commands that will allow me to temporarily rename players in the server. This will keep names straight for when we attempt to get four people on the server at once, without me having to finish the "Create a Player" page, as I'm not yet ready for that. This should be done tonight, so I'll be contacting a few people for testing either tonight or tomorrow.
Some things I'll be working on in the near future (not sure what I want to attack first):
- Background bricks
- Ladders
- Passable platforms
- Item equipping
- Dynamic lighting
My player got to meet someone last night. Actually, he met me, testing from my laptop, but was still quite amazing (personally anyway). As you can see there are differing results based on small tweaks I made along the way. It still isn't "perfect" by any means, and making the movement smoother is actually trickier than you may think.
Check out the video. Feel free to skip the rant afterwords. Things are going to get deep, not so much technical, but should give you an idea what I'm up against. It will also help me think this through.
For the sake of trying not to lose you, in this next section, let me define some things. The player is the person on screen representing you, the player, as you move about the world. The friend (usually your friend) is the other player on the screen, controlled by someone else, as they move about (I actually named the class that holds all this information "Friend". How cute.)
In the initial part of the video, the friend is moving (woohoo!) but irratically, as if we turned a slow strobe light on. I'm not going to talk about the messages the player is sending, only those being received by the player from the friend, because it affects what we, the players, see. I'm also not going to talk about latency/lag (at least not yet) because, since I'm testing on my local area network, I receive messages within 2-4 milliseconds. Therefore, the choppiness is not due to lag.
What's happening is that the friend is sending messages to the player every 1/5 of a second, actually, the friend to the server to the player, but that's all about lag. To simplify, the message is coming directly from the friend every 1/5 of a second. The message contains the friend's position, velocity, and head angle (and soon facing direction). Every 1/5 of a second, the friend is updated to the new position. Velocity isn't coded right yet, so the friend doesn't actually move, he just "teleports" to the message's given locations. Your brain tries to link the positions together, and would have an easier time if we increased the number of messages per second. Also, the friend is updating the head angle, but is trumped by code telling the head to watch the cursor (same thing is happening to the facing direction, but it isn't receiving messages for that yet)
In the second portion of video, I added animation to the friend and made the head angle independent of the cursor. That's when I realized the friend was teleporting. Damn it Google, how do you not know that teleporting is a word. Teleport, teleporting, teleportation. All words. Welcome to the twenty-first century Google.
The third section of video works like this. Player receives message from the friend that says the friend is located at A, moving X speed. Until the next message, keep moving the friend at X speed (plus gravity and collisions) to help connect the teleporting positions. This is closer to smooth movement, however, any change in behavior that the friend makes (starting, stopping, jumping) causes a little stutter effect, as the player is incorrectly guessing where the friend's next location will be. Understand? No? Try this analogy:
Your friend is driving down the interstate. They call you to check in once an hour. They first call and tell you the mile marker they are at and their speed (they always drive the speed limit) of 65 mph. In one hour, they call you again. They are still going 65 mph, and they are 65 miles further than where they were the first time. You could, in theory, know exactly where the friend is along their route at any time, without having to talk to your friend.
However, the next time your friend calls, an hour after the last call, they are still going 65 mph, but they only drove 45 miles, due to bad traffic along the way. The traffic is now clear, so they are cruising at 65 mph, but you have to adjust your friends position on the highway because it was 20 miles off. If you were graphing your friends progress every minute, you would have a big jump in your friends distance traveled to correct when you got their call.
Even more severe, say your friend calls, and they drove 50 miles since the last call, and are currently driving 55 mph. Are they continuing to go 55mph? Are they speeding up? Slowing down?
This is what is happening in my game. The game assumes the car is going the same speed, but is updated and told it was off, so it corrects (causing a stutter-like effect), then keeps assuming based on the new speed. You can see above how this can be an issue.
In this third section of the video, to be more accurate, I cranked up the messages to 20 messages a second instead of 5. The movement is smoother, but still stutters when the player changes direction. This is treating the symptoms, not fixing the problem. It's also adding the amount of information being sent per second. If enough information per second piles on (from player info, monster info, item info) it can bottleneck and really cause issues.
I am proposing this to smooth out the friend's movement: add a buffer which waits for an amount of time after a message is received before actually updating the friend. Then, with the messages received, connect the positions, using the the below methods to avoid jarring jumps that cause stutter effects. If a message isn't received in time for the next update, continue moving the friend in the direction and speed last sent, as we are doing currently. There might be an abrupt movement when the next message arrives, but these glitches are unavoidable when latency is poor.
I've created these graph to help demonstrate. The green line is the actual position of the friend in some direction in time.
Currently the game acts like the orange line. It receives a message from your friend with a position and velocity, and continues in that direction until you get another message, then corrects. Look how choppy that becomes! I should also mention, this is extremely exaggerated, if you hadn't guessed. My messages arrive 5 or 20 to a second, and my player cant change directions that quickly. To fix this, I can use a buffer.
The game adds a delay (in this case, its as long as the period between messages). When a message tells the game where the friend is, it determines the velocity needed to move the friend to that new point in the amount of time the delay is for. The red line demonstrates how close the viewed motion of the friend is to the original, however, due to the delay, you actually witness the friend at the dotted red line. When it comes to a fraction of a second, this may not matter. Because this is exaggerated, the actually game might look pretty good like this. But if not, there's plan B.
Plan B (which I might do anyway): Instead of setting the velocity that will get the friend's location to the next message position within the delay time, you calculate the acceleration needed to get to that position and smoothly roll into it. Then the new velocity takes over until you get another message, and change the acceleration to turn you to that point.
HOLY CRAP! Long post, but it helped me figure out what to do next. Thanks guys! Now that the night is shot, I'll code tomorrow. Good night!
But let's just say, server connection to a remote client worked beautifully. Thanks Julie (my sister) for testing the connection. Going to clean some things up, and try for 4 player connection next.
Due to the lack of updates from the lack of coding and non-lack of moving, I feel I owe you something to keep you checking back here every so often.
My sister recently sent me this link, which cites different ways of going about movement, collision detection, and just lists different ways 2D platformers are made. It's an interesting read (though I've only gotten halfway through). If you're into games (I assume you are if you check here often) then take a look at this article.
I will say this though - my method of collision detection is not the same as what this article lists. There are many different ways, and I feel mine is quite simple, while flexible. For another post I suppose (if anyone cares).
Since my Mother's Day post, I haven't had time to even look at my code. I've hardly had time to think about my code. And the same may happen next week too.
Have I given up hope? Hell no!
The entire apartment is a horrible mess as my fiance and I have been packing to move to a new apartment next week. Packing is about, I'd say, 70% done, but then everything needs to be cleaned. And my fiance is going to Colorado for 4-5 months... tomorrow morning. I will manage fine, packing, cleaning, trucking, and unpacking by myself (and local friends help), but don't expect much on new updates until I'm in my new apartment and at least unpacked to a livable state. However, if I'm packed and cleaned early... maybe?
I'm hoping to solidify the code to allow for online testing from my new apartment. That's my next step.
Actually, no, I will not ever be adding eyes to the player (or any other facial features, though masks are a possibility), but the player is now much more than a running bean man.
The player now has a head. It does it's best to follow the cursor (he doesn't turn his head to look straight up or straight down, as his neck doesn't work that way). Also, the player remains facing the cursor and can run backwards.
The player now has arms. They swing about while running and jumping to keep balance (or maintain circulation to his hands)..
The player now has a bad attitude. Click to punch. Hold and release to uppercut. Only bad asses uppercut.
Yes, left and right click control right and left attack, respectively. It's awesome.
What? Isn't that backwards? Yes, and will be a lot easier this way.
I have a friend and fellow gamer who hosts a web comic with his brother. It is quite entertaining, and features better art than you will ever see here (by myself anyway). It is one of the great things I can still check out during my lunch breaks at work, and the comic is updated twice a week, which is also more exciting than this blog has been (coding has been slow with all the apartment moving).
His most recent post made me feel like a giddy little school boy as he created a post that featured DESCEND! You can go see for yourself, but I recommend you check out the rest of their comics. They're a fun and interesting read, plus will give you something to check out in between my updates. I'll be including a link to his website on the side of my blog soon, so don't worry if you forget.
Also, check out my most recent work in the below video. Sorry if it's fuzzy. And in case you were wondering, this is at 1.5x speed.
Success. I was able to successfully load a small level from the server into the client, and can run the game just as I had before with my little bean man running around. Once the game has started, there is no passing information to and from the server... I'll work on that later. Now that I have caught up to what I was working on before, I'll go back an solidify some things for testing over the internet.
I would also like to create an easier way to build test maps: something that will change a text file into a game level, so that I can create simple standard rooms to test things like walls, room sizes, ladders, etc. I may do this before testing with people so that I can create some sort of interesting "level" to navigate once they load into the game.
In my current momentum I haven't gone back to test with people yet to see if we can join a common server. I'm sure it will work, I just need to figure out the exact code for what goes down when your not all on a local server.
However, I have starting coding the loading screen that occurs after you "start the game". The server starts sending out many small bite sized info messages to the clients. These messages reconvene into the world map and locations for things such as chests, keys, doors, etc.
I will in the near future however need to go back and test out connecting over the internet with my first group of Alpha testers! Oh the excitement!
The past week or so has been quite slow, development wise. My fiance has been freed up from her work in the art studio so we have been spending more time together before she leaves for an art internship all summer. However, I have been adding things here and there. I've got a handful of buttons made up for the main menu and lobby. I'm trying to create a decent prototype to send to my first testers.
That being said, I need testers! I need 3 people (other than myself) to try to join in one server lobby, exchange messages, and leave successfully. The exact time is to be announced, but it won't be right away. I will be very grateful. Let me know if you're interested. If I don't know you, I will discuss later how we can get in contact.
I'm getting rather excited to finish up the menus so I can continue on the game portion of the game. I'm constantly thinking of new ways to do things and content to include.
I lied. I am not going to be making that simple multiplayer game. I'm skipping my own advice (kind of) to take little steps and just adding it to the game. The game had no entry point anyway, so it got me building on the main menu code, and more on the multiplayer lobby. I have also been building the server.
So far it has been running great. I can successfully talk to the server and have set up an "instant messenger" so that players can chat while they set up the game. The server of course can see everything behind the scenes, and do some server stuff, like kick players.
Before the weekend is over I will test communication in the game between my laptop and computer. When that works, I'll have a friend test connect from another locale.
On another note, I was working on the title screen, but don't have a great title yet. My program right now is called "Crawler" and the title screen shows the pending name "Another Downward Path". I don't like it. Name my game!!!
Here's a teaser photo of the inventory screen I'm working on.
But, I think I am getting ahead of myself. I really think this game needs multiplayer functionality, and if I do not start incorporating it soon, I'm going to have to gut a lot of code, and I don't want that.
So, I'm going to start with a new project. My goal is to create a server based "game" where each person connected moves a dot around on screen, and that dot is moved for everyone else. Sounds exciting? No, but I've never dealt with any multiplayer mechanics though, so I'll see what happens. Anyone want to try it out when its ready?
Edit (Additional Comments): There's a lot online about lag compensation and client side prediction. To keep the cheating down, your game should send the server the button presses and what have you, and then have the server determine where you are, what you hit, etc. This seems like a lot of work, but I think it's only really important for competitive games, especially when you don't know who you are playing with. This keeps players from telling the server "I'm here" then teleporting elsewhere and saying "Now I'm here" without the server having any say. They can also say "Hey, my health is actually full now for no reason!" and the server, if not controlling this, just accepts it. This is bad for games like Counterstrike, or Mario Cart.
For this game, I could care less if you cheat. When you play online, you typically will only be playing with up to 4 of your friends. Everyone is working together towards the same common goal. If you cheat, you lose on the experience of the game. Your friends are less likely to play with you, unless they are cheating too. If your all cheaters, then heck, more power to you. You will be drying up the fun in the game in no time.
I do, however, intend to have the server control some things that ARE competitive in a sense. Two people who think they have picked up an item just before someone else (because of the delay over the internet) can't BOTH have the item. I also have to make sure that the person who runs the server and has the fastest speed isn't the one who is taking all the loot, leaving everyone high and dry.
Again, suggestions are welcome. At the moment, I am thinking items will be assigned to a random person in the group with a timer, after which the time is up anyone can grab the item. Coin/Treasure pickup will be instant, and will not be worth anything until the end of a level. Everyone puts the treasure they picked up into a pot (more people means more treasure chests, monsters, items, etc.) at the end of a level, and then is paid out "evenly" at the end of the level. Items acquired are for keeps and can be sold for straight cash to player.
When I say paid "evenly" this depends. Before the level starts, each player will "sign a contract" which they can set the % of money they take from all the treasure they find. This starts even for everyone. But if you have a friend who you want to catch up to the group or doesn't have as much cash to buy some items, you can adjust your own percentage down so they can adjust yours up. You then "sign" the contract to agree. Any percentage not accounted for (players dropped their percentages without raising any others) will go to "charity". This does nothing, and you lose out on that money. So much for charity work.
Moving the map with respect to the player wasn't too extensive a task.
I just wrapped up the collision detection between the player and the surrounding world. There's a lot of looping and decision making code that was just piling up and piling up until I was swimming to deep in it. The code was a mess and not working right, and it was a headache to make heads or tails of it, so I scrapped the whole thing. I wrote out what I needed to do on paper and figured out what loops needed to control the collision detection. After copying some of the old code, it took me just about 45 minutes to rewrite the organised code. It's so much cleaner now.
That's what I get for starting from scratch with no plan.
Now with collisions working, I am finding that my map movement is not lined up correctly. I've fixed it on 200% viewing scale, but 100% is still off. I'll take a look at the drawing code for the world tonight and fix it up. I'll also start putting together some walking animation for my "naked" player sprite. I hope to post a video with the collision detection and sprite animation working correctly.
I have been working on a way to make the screen (camera) follow the player and make the world seem to move instead of the player, without actually moving the world. I've gotten things to be successful, but I only half understand why it's working correctly. It kind of happened on accident, and one of the variables is confusing me, but I think it should work with everything else that will need to be viewed. I'll tackle that hurdle if I can't jump it later.
Next on my list is collision testing, which a lot of people online do in extremely complex ways. I don't think it needs to be that complicated, and have an idea of how I would like to do this. After that, I'll add some physics, get my un-animated 2D sprite to move and "jump", then I'll add some animation.
Hey! Some graphics! How exciting. Randomly tiled bricks in a 10 by 10 space. Okay, so this is a small step, but you have to take small steps before moving onto bigger items. I then made the space as wide as the screen, and worked up a chunk of code to handle auto-tiling. It's job is to detect the edges of a texture group and change the graphic to create a smooth transition. The above picture looks very tiled, with a definite grid. To try to cut down on the grid seen, the auto-tiling smooths out the textures below and gives edges where needed, as soon below.
It's hard to see how much auto-tiling is actually occurring, as there are only four separate brick images needed in the above screen capture. The same tile arrangement is below, but I used a different texture. Below that is the image that my auto-tile uses, cutting it up into bits and rearranging them as needed.
Auto Tile Sheet
Now I am working on the camera, maybe some of the GUI, and then I'll add a player with collision collection and controls.
I'm trying to figure out how my map is going to populate the screen, holding information about the tiles, and being able to move the camera. I feel like I'm close, but not quite wrapping my head around it yet.
Remember, small steps.
I think I have a direction in which to start testing things out. Let's see where it goes.
As for sprites, check out the title! I'm not sure how crazy I am about it (Edit: Better now, the little guy was not to scale with the bricks). Right now the pixels are blown up to about 200%. If I want to keep things crisp, it will all be smaller, requiring better artist skills, which I do not have. I'm also not too thrilled with my little guy I have made. I'm thinking the game will have to animate the legs, each arm, body, and head all separately to allow for all the combinations of clothes, item use arm movements, and general looking movement. I have an idea how to address this too. I can't really rotate things, otherwise the large pixel feel will look worse with rotated pixel objects.
Anyway, time to code, unless Ash calls me to play Payday: The Heist. Robbing banks is addicting.
I've been trying to figure out some sprite editing software to use for the graphics of the game. After looking at quite a few, I found some that look promising.
For my level maps, I want something which I can have a grid and place my sprites in it, to see how they work and look together. I want to be able to edit them, pixel by pixel, and see all of that type of tile change in real time to make sure things line up correctly and what not. A program called the Dame Editor looks promising, and holds many features (many that I do not need) and I have not seen an easy pixel editor but I'll check it out. I do not need to make maps with it, as this will happen in the code itself, and be randomly generated.
I will use GraphicsGale for everything else un-map related.
For characters, items, GUI, and pretty much everything that isn't map related, I'll use GraphicsGale. I am definitely no artist, and I will find out tonight at what extent I am truly bad. I've seen some useful tutorials online, and I don't want to copy someone else's sprites, but I have a plan in which I shouldn't fail too miserably, if I can figure out how the program works...
Edit: Screw it. I think I'm going to stick with Paint.NET. It is amazing, and I can do great things with it quickly. I found a site about resolution sizes and how large to make a character here. I like the pixelated style, so I'll go for a charactor standing at ~128 screen pixels, but only 60 drawn pixels tall (by dropping the pixels per inch/resolution). We'll see how that goes.
A few days after starting my project I have come up with a basic dungeon map layout builder. The actual tile map that the player will see will be built based on the layout that this chunk of code will spit out.
What the code does is starts ("S") a dungeon at the surface (top) of the map, or just below from the side to allow a different style of entrance. It then branches out in random directions (weighted depending on the type of level) and lengthens rooms randomly, adding a door ("D") at the end. If a dead end is encountered before the minimum amount of spaces are used, then a treasure room ("T") or key room("R" for red keys, "G" for green, "B" for blue) is created, and the program backtracks to another room, starting again with colored door for keys when applicable. When the number of dungeon spaces are acquired, a door to a boss chamber will be created in the end of the dungeon("X").
I'm now trying to figure out what scale everything is going to be in so I can start developing the tiles for the tile map. I'm not a great artist, but at small scales it may be doable. If you would like to help, that would be great too! I need to find a program that edits tile maps easily and efficiently. Research is still in progress...
See below for some dungeon outputs the code spits out so far! I generated all of these in a row. I did not pick and choose my favorites.
The first dungeon features an early green key room, which unlocks the door allowing you to venture downward. The bosses chamber is located halfway down, but for the true treasure hunter, they will continue down the treasure room located at the deepest depths of the dungeon.
The second dungeon offers a choice to the player. With the first blue key they find, will they open to door that leads to the boss chamber, or will they open the door to yet another key, making the player venture back and forth through dangerous corridors.
The third dungeon is a straight run to the finish, probably riddled with traps and dangerous creatures whose loot can be just as useful as those found in treasure rooms of other dungeons.
Dungeon number four is a fairly easy venture to the boss, however, it may prove quite valuable to look further, acquire the blue key to the early found door, leading to a treasure room.
For this fifth dungeon, I doubled the amount of room spaces. See if you can find your way through. As you can see, with more densely positioned rooms, you get interesting variations, such as treasure rooms that aren't in dead ends, and you may even find yourself carrying a few keys at a time. Also, if you choose the wrong doors, you can still make it to the final boss, however, you might miss out on the two extra treasure rooms!
I really love coding and really wan't to start a new project. Well, technically I have already started, but I will act as though I haven't yet in this post. I'm going to try to create a game in XNA to practice my coding skills, and maybe result in something my friends can enjoy as well (maybe even together!).
The concept came after playing hours and hours of Terraria, a 2D game with a randomly generated world which you mine ores, build a base, discover tons of items, fight monsters, bosses, and even each other if you really wanted. The style itself really caught my attention as well. It is quite simple, and generated from square tile pieces to form a complex environment. You and your friends can even explore the same world, and if resources are scarce, you can carry things between worlds. There's a succession of items that you acquire in order to become more powerful, instead of having to level up or gain experience. It is a very well rounded game and can cause you to loose a lot of time deep in the enjoyment of playing it.
Example of Terraria with a Dungeon-esque look.
Stylistically, I want the same kind of pixelated type of game world. However, instead of being in a sandbox sort of game where you mine, build, and explore, I want to create a 2D side scrolling dungeon crawler. You can play solo or (hopefully) you can play with a couple of friends. Upon entering a new map, a dungeon is randomly generated. Players will not "level up", but find items of increasing strength and abilities in the depths of said dungeons to be able to play deeper, harder types of dungeons. Levels will always end with a boss stage, randomly generated based on your carried items.
There will be no building aspects to the game, only a trading mechanism at the start of each level to sell found items or restock yourself with potions, arrows, and the like before diving into the next dungeon. I would also like to incorporate a two handed system by right clicking and left clicking. Wield a sword and shield. Wield a lightning staff and throw acid with your other hand.
The basic, easiest dungeons will allow a player to proceed, able to access everywhere without the use of certain items. Harder dungeons will require the players to equip items to slow their decent's into pits (A summoned cloud, a hang glider, an umbrella) or be able to access high platforms and rooms (double jumping shoes, wolverine claws for climbing walls, wings and grappling hooks).
We'll see what happens and how far it gets. Please keep my motivation going by posting on the blag from time to time. I'll update with screen-shots and code results from time to time to show you how things are progressing. Feel free to ask questions!
Well, lunch break is over. Got to get back to work. (Most updates will probably be typed up during my lunch break!)
