next »

[SolarLune]

Hm, I just noticed something that's bothering me.
Is there any way to get the sprites to not be perfectly parallel with the screen all the time, like as an option or something?
The way the button sticks off of the wall 4 screens up bothers me.

The button is indeed off, and I'm not sure why. Other objects don't seem as bad, but I guess it's because they're 'aligned' to the ground (i.e. the tree and crate can sit on the ground without any problems). The button, though, can't sit flush against the wall, and redrawing it didn't help. So, I guess I'll have to make it 3D. Something that I'm trying to avoid is mixing styles too much. I was kind of trying to have 2D objects be interactive, but 3D be generally non-interactive, but the tree's 2D, and the terminal's 3D, so it just might not be possible. I'll try modeling the button instead.

@dusty d That would make the pixels squashed and rectangular.  He could up the angle and draw it again, showing more of the top and less of the button's face.  Though it might be nice to model it instead(?).

logos got crunch I like it.  

where the grates meet the road and where the grass meets the dirt maybe some kind of transition, like how the road meets the dirt.

Thanks. Yeah, the grating could use some sort of transition, but it didn't really make sense in the middle of the street, so I added an actual gutter tile. It could probably use a little lighting on it to not be so flat. I also fixed up the sidewalk to add some cracks.

Watched devlog video for the first time. I like the pace of your game. I remember some designs I did with a similar perspective, and all this level browsing and back-tracking, but more of a focus on drawn-out multi-room battles and physical combat.

The best part about these kinds of games is owning an environment, fast gameplay etc.

I would shorten the text. 6-page things break the game's pace. If you want to put some color text in I'd spread it out. You can pop that stuff up anywhere.

Thanks a lot. That idea sounds cool - there won't be multi-room battles in this, but it would be cool if enemies could stay aware of you and follow you from map to map. Maybe for another game.

You think the text is too long? I guess I see what you mean - it's a little thick to be the beginning of the game (where the text is).

Awesome logo. I take it from the style of your logo that the pixelated style that you use to make games will permanently be your game development style? It fits

Thanks. This probably won't be my permanent style, though - I'd like to try other stuff as well.

[Graham-]

Watched devlog video for the first time. I like the pace of your game. I remember some designs I did with a similar perspective, and all this level browsing and back-tracking, but more of a focus on drawn-out multi-room battles and physical combat.

The best part about these kinds of games is owning an environment, fast gameplay etc.

I would shorten the text. 6-page things break the game's pace. If you want to put some color text in I'd spread it out. You can pop that stuff up anywhere.

Thanks a lot. That idea sounds cool - there won't be multi-room battles in this, but it would be cool if enemies could stay aware of you and follow you from map to map. Maybe for another game.

You think the text is too long? I guess I see what you mean - it's a little thick to be the beginning of the game (where the text is).

Yeah I do. Even listening to you read it out I could tell you were just waiting to get through it too.

The beginning of the game is crucial. You win/lose a lot of players there and set the tone for the rest of the experience. If the game is fast-paced then don't mess with that with text.

You could space that stuff out. I wouldn't go above 3 text boxes in a row, especially at the beginning. I'd aim for 2 usually. Besides, if you spread out the content you could break up the pacing in sections that might be stretches of gameplay that are too long.

http://www.penny-arcade.com/patv/episode/tutorials-101

That's an Extra Credits episode about tutorials. They talk about the disadvantages of front-loading them in there. I love EC.

edit:

All my designs have this motif of drawn-out battles in which the player gets to know his enemy, gets to rely on his understanding of the environment, gets to re-track a lot of old ground in a new context etc.

p.s. you could always make some enemies run away, maybe take advantage of their knowledge of the player's position to counter-attack, maybe bring back re-enforcements if the player can't cut them off first, things like that.

they'd probably need a bit more health first, and you'd have to drop the inter-screen loading times a lot for it not to be annoying.

[SolarLune]

That PA video was pretty informative. I'd like to work with it, to be sure. I agree that the best tutorials are the ones that are basically invisible. If the player's informed about the game before going in, that's just as good as having an invisible tutorial. I think that the larger the game, the more of a tutorial it needs, but also that finding out things about the game is a lot of the draw. Some of the fun in playing is not knowing everything that's going to happen - not knowing exactly what will happen if you attack this enemy, or use that pick-up. The core mechanics should be outlined to you somewhere, though - either in a tutorial or in a manual.

A lot of good games, for example, don't bore you with instructions on how to move your character - you read the manual or ReadMe if you wanted to find out. It did, though, hide useful information, 'mini-tutorials' in a sense, in optional signs, NPCs, events, etc. The observant player was more equipped than the 'gung-ho' player, but neither was punished. I hope to have that kind of element be in the game.

I think that the text in the first video isn't too long, though. Being the opening of the game, I agree that it shouldn't be slow or make people say, "Yes, alright, let's go!", but it shouldn't just drop you in the world with no context. If I'm aiming to make a story-based game, I think I should frame it a little with some events. I thought I read the text alright in the video (if a little embarrassingly, ha). What was in the video isn't really a tutorial - it's an event. A tutorial is something that tells you how to play, while an event shows the context and plot of the scene. I'm not trying to be nitpick-ish or anything, I just want to establish the difference.

However, I do think that I don't want to hamper the game with text, but use it to build on the game, so I'll keep an eye out to ensure that it doesn't become unnecessary.

[SolarLune]

Okay, so I uploaded a devlog video basically just showing what progress I've got so far / what I've been posting.

[Graham-]

That PA video was pretty informative. I'd like to work with it, to be sure. I agree that the best tutorials are the ones that are basically invisible. If the player's informed about the game before going in, that's just as good as having an invisible tutorial. I think that the larger the game, the more of a tutorial it needs, but also that finding out things about the game is a lot of the draw. Some of the fun in playing is not knowing everything that's going to happen - not knowing exactly what will happen if you attack this enemy, or use that pick-up. The core mechanics should be outlined to you somewhere, though - either in a tutorial or in a manual.

A lot of good games, for example, don't bore you with instructions on how to move your character - you read the manual or ReadMe if you wanted to find out. It did, though, hide useful information, 'mini-tutorials' in a sense, in optional signs, NPCs, events, etc. The observant player was more equipped than the 'gung-ho' player, but neither was punished. I hope to have that kind of element be in the game.

I think that the text in the first video isn't too long, though. Being the opening of the game, I agree that it shouldn't be slow or make people say, "Yes, alright, let's go!", but it shouldn't just drop you in the world with no context. If I'm aiming to make a story-based game, I think I should frame it a little with some events. I thought I read the text alright in the video (if a little embarrassingly, ha). What was in the video isn't really a tutorial - it's an event. A tutorial is something that tells you how to play, while an event shows the context and plot of the scene. I'm not trying to be nitpick-ish or anything, I just want to establish the difference.

However, I do think that I don't want to hamper the game with text, but use it to build on the game, so I'll keep an eye out to ensure that it doesn't become unnecessary.

Yeah, I mean, that's the general idea.

I will say one thing. If you're ever worried about "context," the best way to build context is through gameplay. Right? The motivation to play should come from the most important elements of your game. In your case that's your mechanics and environment. "Requiring" text is to say those elements aren't inherently motivation enough, so you need something extra. That's kind of backwards. If your game is text-heavy in general, then an intro with text makes more sense. Also, I'm only referring to text when you get items. The dialog was okay.

ps. Your soldiers are cute. Your idle anim. for main character rocks.

double ps. I might be wrong.

[eigenbom]

nice vid, this could really be a champion for blender gamedev, keep it up

[clockwrk_routine]

looks good and feels good I like the stealth action you have so far, have you thought about adding a suspicious state such as they hear something or see something that they are not sure about, it would add baiting/ambushing to possible strategies, also to help maneuver around enemies that are in the way.

[SolarLune]

@toast_trip - You might be right about not 'requiring' text. The story-necessary parts (i.e. cinematics) might need text, but the actual game probably shouldn't force it so much (i.e. necessary items you pick up). Text can help to make the game feel a little more deep as it adds things that you can interact with (i.e. objects you can examine that have no bearing on the game just to add to the depth, like in most RPGs), but they can distract as well. So, it might be best to keep the text to a certain amount - the '2-page' amount that you mentioned feels pretty good, after trying it out on a simple object (a movie poster).

@eigenbom - Thanks a lot!

@minnow - Thanks. That would be pretty cool. I already have the "?" sign, so I could probably build it into that, but I think it might be a bit too much. I might be able to add an ability to throw objects to distract guards, though. Maybe I'll add that in.

I think I found a way to improve the path-finding for the guards so that they'll move more predictably. Currently, they establish a path between them and you and create a path using pre-placed nodes. That works, but the path always starts with the node closest to the guard and ends at the node closest to you. It would be faster if the path started with the node closest to the finish that the guard can move to - that way, for example, the guard won't walk around 15 nodes when it can just walk directly to the exit.

Anyway, I also re-factored the code for the GUI so that it tries to group similar items together in the equipment menu. I took the extremely lazy way out and just added a letter to the beginning of the internal item names to indicate how they should be sorted, i.e.

Agm - Machine Gun (Group A)
Agp - Pistol (Group A)
Bbj - Jump Boots (Group B)
Big - Grenades (Group B)

This way, similar items can be grouped together. The down-side is that it's not very flexible. I think I'm going to change it again really quickly to use a specific variable for it on a per-item basis, rather than forcing the name to perform this task. It's working, at least. The top-left one is the machine gun, and the one to the left of the cursor is another weapon. This was mainly so that you wouldn't have to scroll through items to equip weapons.

[Graham-]

@SolarLune

It's up to you eventually. All we have are our instincts. Maybe this thought will help. If you ever find yourself "needing" to put something into your game, and it doesn't feel right, even for a small reason, or it feels awkward, then you very likely don't need it. The player's experience never needs to be interrupted. It just needs to be redesigned.

Yeah, text can brake up pacing. The question is, "would my player be motivated to read this text right now?" If you talk about lilies for the first 20 pages of a book, because it's about lilies, then you start talking about cars, people aren't going to care, unless the cars obviously provide a nice analogy for lilies, or play on the knowledge of lilies well, and the reader trusts that such a relationship exists, so they know that the tangent is something they want.

Also. PS. I love Planescape: Torment, and stuff. Text can rule a whole lot. Even the books I found in Skyrim were really world building. They were just painful to read on my non-hd tv. Also their ugly formatting made them "part of the world" but not part of my "easy to digest experience." Sometimes devs forget the real reason people are playing their games. I always forget....

[Swaggermuffin]

(image)

I take it this game's going to support gamepad controls? What with the A and B buttons, it looks like it's being made for them.

[SolarLune]

Yeah, it already does. I chose the buttons because the project started off being heavily inspired by the GBC Zelda games, and so that's what the buttons were supposed to evoke memories of. I guess I could change it to keys, though.

-----

As a sidenote, I now use actual sorting variables rather than just using the name like before, which is good.

[Maud'Dib Atreides]

Yeah, it already does. I chose the buttons because the project started off being heavily inspired by the GBC Zelda games, and so that's what the buttons were supposed to evoke memories of. I guess I could change it to keys, though.

-----

As a sidenote, I now use actual sorting variables rather than just using the name like before, which is good.

you have gbc zelda nostalgia

wow, my idol

you are my idol.

But one thing I never understood about the zelda games (By all means, don't let this change your game, I'm supporting the AB button combos) but in the Zelda games, you were forced to unequip a bracelet (Such as the Power Bracelet) in order to hold a sword.

Why not just wear the bracelet AND the sword?

One of the items was a feather. Why not just tape the feather to the blade of the sword?

I mean if you have the ability to carry an entire surplus of equipment capable of fully stocking an Army Surplus store..

I guess a lot of games do this, like in Castlevania SOTN, how Alucard could only wear two rings.... I mean he had 10 fingers.

Realism in games.

Anyways, do what you want. I like the AB combo. Reminds me of when I was a kid and carried my lime green GBC everywhere. I finally got a GBA and played Zelda in it only to find "special features for the GBA"

but I digress..

[Swaggermuffin]

Yeah, it already does. I chose the buttons because the project started off being heavily inspired by the GBC Zelda games, and so that's what the buttons were supposed to evoke memories of. I guess I could change it to keys, though.

-----

As a sidenote, I now use actual sorting variables rather than just using the name like before, which is good.

Oh my god those were my favorite games for the game boy

[SolarLune]

Worked on a new weapon, the spread shotgun, and a hookshot item. The shotgun is powerful, firing several bullets at a time. In addition, it gives a slight kick back when you use it.

The hookshot was going to be a traversal item that would allow you to swing between grapple points, but I'm probably going to cut it out because it just doesn't work as I'm having trouble programming it correctly. Maybe I won't cut it out entirely, but will rather leave it in - I don't know. I already have an idea for a replacement item that would do something similar, but be easier to use, and yet much easier to mess up with.

@#Sharp - You raise an interesting point about equipment. I'm wondering now if my current method's a good implementation, as currently you can wield two weapons, regardless of their sizes or types (i.e. spread shotgun and pistol). Restricting it to one weapon and one item or just two items would make more sense, but would close up some possibilities.

[SolarLune]

SONIC BOOOOOM



Using the Boost Bracelet, neither blast-resistant walls nor light enemies can stand against you.

[poe]

Fuck yes.

[Maud'Dib Atreides]

SONIC BOOOOOM



Using the Boost Bracelet, neither blast-resistant walls nor light enemies can stand against you.

I stared at that for 3 whole minutes

my mother is proud

[melos]

SONIC BOOOOOM



Using the Boost Bracelet, neither blast-resistant walls nor light enemies can stand against you.

Will it make him strong? Will be he be able to fly? Or reach the other side of the rainbow? Will it be alright to take a chance because there's no circumstance that he can't handle when he uses his mind?

[Pemanent]

I'm impressed with your Blender dev skills. I've always been super frustrated with bge.

[SolarLune]

Thanks a lot, everyone.

@seagaia - Heh, I love that song, seriously. Played it all of the time on Sonic Generations.

@Pemanent - Thanks. It was interesting when I started out because the BGE was kind of non-conventional to me. It's like Game Maker in a sense, because it's approachable with logic bricks, and expandable with Python, but a lot of the time, rather than trying to code a feature in you can just end up thinking about how to do it with Blender / objects.

For example, if I wanted to have an astronaut orbit a planet, I could go through the math to make it happen, and I have. It wasn't great math, but it worked. Now, I would just parent the astronaut to the planet, and then rotate the planet. Or, parent the astronaut to an invisible "OrbitHook", and then move the hook to the planet, rotate the hook to make him orbit, and move him back from the hook to the distance I want with code. If I want to break the parenting relationship, I can do that easily with Python. It's very simple. Some of working with Blender is actually coding, and some of it is just switching the way that you approach development - trying other ways to do something.

The more I worked with it, though, the easier it got. When I started, I thought of the BGE as a toy - it just didn't really feel like a real game engine. After seeing that it had Python and working with it, though, it just got more and more capable. That combined with the updates over the years really turned me to it. Now, there's pretty much nothing that frustrates me with it, and now I can work around problems that I have.

---------------------------------------

So I'm just fixing little things now, adding sounds and stuff. Something that I found was a pretty good way to cut down on the loading times. A quick test cut it from something like 4 to 5 seconds to around a half a second, or something like that. 4 - 5 seconds isn't a lot, but when the game reloads every time you die, it can get a little annoying.

Basically, I currently have all of the maps in the game in a single scene in Blender, which means that the BGE loads it all up and places all of the objects. That's kind of unnecessary. In addition, all of the objects execute logic, even if they're not on the same map as the player. This is cut down by slowing the frequency of script execution / stopping scripts early for objects not on the same map as the player, but it's still happening. It would be far faster to split up the maps into individual scenes, or at least sections of the game world into their own portions in the game world (i.e. all of the sewers in one scene, all of the city in another, all of the park in the third, etc). It's something to think about / implement, to be sure.