Making Games Megathread: Congratulations on releasing the horniest game of 2022

The Something Awful Forums > Discussion > Video Games > Making Games Megathread: Congratulations on releasing the horniest game of 2022

«‹›9 »

The Cheshire Cat: Jun 10, 2008; Fun Shoe

DeathBySpoon posted:

Hey, I'm looking for some feedback on a game I'm working on. It's a Metroid-like and I'm trying to get a workable look and feel down.

How does this look? Criticism / critique? I'm pretty sure the game is going to have to look blocky just because of the way I'm handling tiles, but I want to make it look the best I can given that. Is the appearance passable or is the blockiness a big turnoff? I'll try and get something interactive soon, but hopefully this is enough to get some feedback on already. Thanks!

You can break up blockiness somewhat by using secondary, non-interactive background details; stuff like plants or holes/cracks in the walls, etc. Look at Super Mario World for a good example - that game is totally block based, but they break it up with a lot of curved and angled background details. A good 70% of the things you can see on any given screen in that game serve no gameplay purpose but make the environments look much more interesting.

# ¿ Sep 20, 2012 19:10

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 10:57

The Cheshire Cat: Jun 10, 2008; Fun Shoe

DeathBySpoon posted:

I guess that's a bad screen- I have 45 and 22.5 degree tiles done in code, but no visuals for them yet. I'll try and get something workable and show how they look. Thanks for the feedback already, I'll look into adding foliage details / etc too.

E:

Slants in place. I'll try adding some brush / foliage / etc now.

E:

Ok, yeah, that makes a huge difference. Not sure what to put on the floor though, if anything. More feedback?

For the floor you could probably just put some misshapen rocks - though lots of other stuff works too. Based on the environment in that screenshot you could have cave foliage like mushrooms or other fungi of varying sizes. In a city environment you could have things like trash or debris, etc. Lots of games do stuff like that so if you're ever hurting for ideas just google a few screenshots from Super Metroid and the like and just look at their environments.

Another thing you can use to break up the visuals a bit is negative space details - putting holes in the ceiling or floor past the edges, so that the walking surface is still solid but it's got a bit of a "Swiss Cheese" texture visually. It may be a bit tricky to do depending on how your engine is set up - the way I would probably do it is break up my visuals into graphical layers like background 1, background 2, foreground, etc. Your ground tiles that have an actual physical presence in the game would go in the foreground layer, and on top of that would be a special "alpha" layer. Anything drawn to that layer, instead of displaying a sprite, would cut out the shape of that sprite in the foreground layer, so that it would display whatever background layer was present behind it.

If you don't have your graphical system set up like that, it's not a big deal - what you can do instead is just draw up a few variation tiles that blend in with your regular tiles but have some extra detail on them to break up the tiling a bit. Said detail could include a transparent section, and you'd just plop that tile somewhere instead of a standard tile.

One issue with that approach is memory, which isn't really much of a big deal these days, but I think it's important to always be aware of the drawbacks of a particular design. Back in the NES and SNES days, having something like that might have broken your memory budget, since just one "variation" tile for each terrain type is going to double the memory footprint for foreground objects, which might prevent you from adding something more interesting like a new monster sprite.

The Cheshire Cat fucked around with this message at 20:50 on Sep 20, 2012

# ¿ Sep 20, 2012 20:45

The Cheshire Cat: Jun 10, 2008; Fun Shoe

The White Dragon posted:

Now I've never claimed programming to be my strong point--just good enough to get things working without the universe imploding-- but I've been checking my task manager with my game open and have gathered the following data:

On an i5 quad core, it usually runs at <1% (displays as 00) CPU and peaks at around 3% between stages before falling back to <1. This, I'm cool with this, I must be doing something right, haha.

It's the memory consumption I'm worried about : whenever I go to a new stage, it seems like it's loading all the PNG data into RAM, if that's even how it works. This seems to be a pretty static value and only increases at very noticeably set times (i.e. transitioning between stages and the world map). Even though the PNG data falls out of use, it looks like the RAM doesn't get flushed and it hovers around ~250-300MB, increasing by about 4-10kb every time you go back to a screen you've already been to, and proportionally to a screen's data size the first time you go to it while the program is running.

At the size rate of the screens that I'm using, it'll probably come out to be about 1GB if everything gets loaded. I mean this isn't really a problem in this age of "16GB of top-quality-brand top-speed RAM costs $120," but conceptually I don't really like this. Is there a way to flush your memory usage in XNA? And if there is, is that even a good idea?

I don't know a lot about XNA specifically so I apologize if this comes off as very generic advice, but hopefully it will still be helpful to you.

What I'm guessing is probably happening is that image data has to be manually unloaded from memory if you want to free the space up again. Garbage collection could unload it if you've got nothing pointing to it, but the thing about garbage collection is it's not the end all solution to memory management - all it does is prevent you from creating memory that you can't possibly recover without closing the program. As people mentioned in the previous posts that were made as I was typing all this up, it's generally a bad idea to just try to flush your RAM, assuming the API lets you do it at all. The most you'll ever want to do along those lines is manually call the garbage collector, and even then it's usually not necessary since most garbage collectors are just set up to run exactly when they're needed anyway.

What you need to do if you want to clean up your memory usage is take a look at your program and see how your images are actually being loaded in. I'm guessing it's probably something like you've got a game object which has a 2dImage value (made up class name, just substitute with whatever is appropriate), which you probably create a new instance of when you define that object. Example:

code:

EnemyShip ship = new EnemyShip(new 2dImage("\imagedata\ship.png"));

Might be how you create a new instance of an enemy if you were doing it wrong. I say "doing it wrong" because what this will do is load the same image data into memory as a new object every time you instantiate another ship (It's totally possible that your class might be "smart" and recognize this to automatically point new things at the previously created image objects, but unless you wrote it yourself you shouldn't assume that). I'm assuming you're not doing this; however, the reason I bring it up is that in this example, your image data WOULD be garbage collected just by setting the ship reference to null. The garbage collector would dump the orphaned EnemyShip object, which would orphan the 2dImage object, which the garbage collector dumps next pass, and it's all gone.

Now, what I assume you're probably doing is pre-loading your graphics with a factory class of some kind, and instantiating your game objects something like this:

code:

constructor:
2dImage shipGraphic = new 2dImage("\imagedata\ship.png");

newShips:
EnemyShip ship1 = new EnemyShip(shipGraphic);
EnemyShip ship2 = new EnemyShip(shipGraphic);
//etc.

(but like, with an array or hash table or something better than named variables for every object. I'm just trying to keep my examples simple!)

Which is good, and more efficient. Here's the key though: As long as an instance of the factory class exists, the garbage collector will never free the image data from memory (If it's a static class, one technically exists for the entire duration of the program). The reason being that even if you dereference all your game objects, there's still going to be that 2dImage object (shipGraphic in the example) sitting there ready for use by the next thing you ask the factory class to make for you. This is fine within a level since you're probably going to need to keep making use of that graphic data, but between levels you'll need to set up some system to dereference graphics you know you won't need for the next one. There's a couple ways you might do this:

A) If your factory class is instantiated instead of static and only loads graphics into memory the first time it needs them, you can just create a new one and point your factory variable to that instead of the old one. Then the garbage collector will come along and dump the old one along with anything it's still got loaded into itself. The downside here is that you're going to spend a lot of time reloading the same graphics if you happen to share certain ones between levels. If it front loads everything this will also seriously slow down level transitions since it's going to load your entire graphics library into memory every time.

B) A more efficient option is to define resource tables for each of your levels - a lot of older games do stuff like this which is why in say, Jagged Alliance 2, mods will allow you to build sandbags in-game, but only on levels that already have them (because on the levels that don't, the object/graphics data isn't loaded into memory). Then when you change levels, you have your factory object look at the table for the next level and compare it to the data it's already got loaded - it keeps anything that's also used in the next level, and only loads in stuff that hasn't been seen yet. Finally it dumps all the stuff that it has loaded but is not referenced in the table for the next level. This way if you have a lot of objects that reoccur frequently you won't have to constantly reload their graphics, but you still trim the fat for things that you know you won't be needing in the near future. The best way to produce the tables for a level is to just set up a level design tool that does it for you and saves it with the level data.

So hopefully that helps. I don't know how your game is set up specifically so I kind of tried to cover as many bases as I could. If it's all tl;dr, you might want to check out this thread where you can post code snippets and probably get much more specific answers from people who actually know how XNA works.

The Cheshire Cat fucked around with this message at 22:10 on Sep 24, 2012

# ¿ Sep 24, 2012 21:50

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Nition posted:

The Cheshire Cat, that's a way better reply than mine and I think I learned something too.

Can I just clarify, you're saying that if I made 50 clone ships from shipGraphic, none of them will get collected until I've cleared the reference to shipGraphic itself?

Not exactly - each clone instance will be garbage collected, so you'll free up the memory being used for data related to individual instances (like the variables representing their health and so on), but the graphical data and any other data shared by every ship (like weapon definitions or whatever) will still be referenced by your base object that you defined when you instantiated your factory. Basically think about it like this: if, after you clone your object, you assign new objects to any of the clone's variables, those objects will be cleaned up with the clone if you remove all references to said clone.

So you won't end up with 50 clone ships floating around in memory with nothing referencing them after you drop them from your main game tree (or however you have them stored), but the bulk of memory use in most games is graphical and sound data, which will still be referenced by your factory object.

seiken posted:

ChesireCat you went to a lot of effort on that great post so I don't mean to annoy or anything, but I saw you (not exclusively, a couple people did it) use "dereference" to mean "set variables referencing [the object] to null". I think this isn't the correct term and in a programming context it already has a meaning (getting the value a pointer points to) so calling it that could be a little confusing, even though it's a reasonable name for it otherwise. I don't know what the correct term is since I rarely use garbage-collected languages, sorry!

You're right about that; I'm bad with terminology. It's tempting to use "dereference" the way I did because it doesn't really come up with most modern languages (C++ is kind of a holdout), but yeah it's not really what that term means. I don't what the correct term is for what I'm talking about either. It seems like there should be one. "Unreference"?

The Cheshire Cat fucked around with this message at 23:48 on Sep 24, 2012

# ¿ Sep 24, 2012 23:44

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

I always looked at Commandos and thought I'd love it, but I never actually took the time to play it. It looks very slow paced.

It's a bit misleading. It's more of a puzzle game than a tactical/strategy game. You have to figure out how to use all your guys special abilities together in order to accomplish the goal. Which does usually involve stabbing a bunch of nazis in the back, but still. The actual shooting mechanics are pretty terrible, but you aren't really supposed to do much shooting (except maybe with the sniper).

It would be an interesting thing to look at though, just to contrast against games like Syndicate or turn-based tactical stuff like Jagged Alliance or X-Com. Might give you some interesting ideas (you can get the whole series on GoG).

# ¿ Sep 27, 2012 22:47

The Cheshire Cat: Jun 10, 2008; Fun Shoe

DeathBySpoon posted:

Elemental weaknesses and related messages are in. Characters can now Resist, Null, Absorb, or be Weak to any attack. I left out reflect because I got into some annoying issues with attacks looping infinitely between two characters that reflected the same element. Next up, I need to award extra turns for hitting a weakness, and add a downed / dizzy status for characters. Defending also works now, leaving items as the last major menu thing to implement. Those will come last, though- I want to get the skill / turn system totally finished first.

For reflection you could just take the final fantasy approach where a spell is only reflected once (so you can penetrate enemy reflection by bouncing something off yourself). If you want something to still be protected from that element you could have it tagged to null it as well.

# ¿ Sep 28, 2012 18:00

The Cheshire Cat: Jun 10, 2008; Fun Shoe

*edit* ^^^^^^^^^^^^^^^^^^^^^^^^^^
It probably won't really matter performance-wise, but how come your cubes have so many polygons? Is it for the shading effects? This isn't a criticism, just curiosity - I don't know a ton about 3D.

As for the rays thing, that sounds like it'd be fine to me. It sounds like a lot but since you'd only be moving one character at a time it wouldn't really be that big a deal to shoot that may rays every step. It probably wouldn't even take that many if you can find a way to optimize it so the computer can figure out exactly how many it needs to fire to cover all possible angles. I don't know how you'd do this off the top of my head but it sounds like something that someone would have solved with fancy math already and you could probably find it online.

Svampson posted:

You aren't truly bad at drawing unless you go low-resolution 2D sprites for humans (since they are hard to model) and make the world 3D (because you can't grasp perspective)

Which me reminds me that I haven't posted about my latest project on here

Turn-based combat!

Some LOS stuff I shamelessly bought from the asset store (That probably won't make it into the full game since the way it draws the fog doesn't jive with the blocky nature of the world, will probably have to roll my own)

The idea is a party based rougelike with SRPG combat mechanics + a town building game which you constantly feed into when you are adventuring (Your party members are recruited from your village, Found gold goes to the treasury, finding an enchanted anvil will improve the stuff your blacksmith can provide etc)

Still super early in development!

I think the art style works here because you've kept the texture resolution consistent with the low-res character sprites and the 3D stuff is all blocks so it presents a unified aesthetic. The key with any art style is that you should be using it for a good reason. "Because it looks retro" isn't a good reason unless your game is specifically meant to evoke a NES era game or whatever, which involves more than just the artwork (there's an old Multimedia Fusion game I have that someone made that was a great example of an NES throwback that I wish I could remember the name of. It not only had the graphics and sound design, but even did stuff like making sprites disappear if you fired too many projectiles).

Plus I like the sound of the concept. Kind of like Shiren the Wanderer + Final Fantasy Tactics. As a random aside, I think it would be cool if you had permadeath for party members, but also a limited supply of people in the town, who could all be recruited into your party or work in the town. Then you could have buildings/jobs that you can put resources into to attract more people to live in your town. The idea being that you'd have to balance expanding your town with making sure you have enough people to fill your party and staff jobs in the town (and you'd also be rewarded for keeping your party alive since it means you'd have to spend less on attracting immigrants).

The Cheshire Cat fucked around with this message at 16:23 on Oct 1, 2012

# ¿ Oct 1, 2012 16:11

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Svampson posted:

I played trough X-com last week again in anticipation of the new one, and the way you grow attached to your little soldiers when they manage to pull trough/dies horribly is so good and is basically one of the things I want to achieve (It probably won't be as super brutal as X-Com however )

Haha, it's funny because I was thinking about X-Com making that comment too. If you wanted to be mean you could have a random "town attack" event where you have to defend the town with all your non-combatants, since I imagine otherwise there won't be much reason why your townies would ever die (unless you ran so low on party members that you have to start recruiting people away from key jobs).

That seems like something that would be best used in moderation though. Not so much because of the "gently caress, they just killed my legendary blacksmith!" angle as the "Goddammit, this poo poo always takes forever" angle.

# ¿ Oct 1, 2012 16:32

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

Your stuff is always charming but I do the exact opposite to you. I started off with an idea for an engine that would allow me to create things within limits I thought would be reasonable (isometric, tile based with everything locked to a movement clock, designs for sprite banking and creature classes) and once my limits were set and the engine was functioning, I started to design a game in those limits for that engine.

I should point out that this isn't the best approach if you aren't very disciplined as a designer - I'm always coming up with ideas for game systems that I never get around to making because without a solid game concept it's very easy to get carried away with feature creep and never end up writing a single line of code because you keep coming up with more ideas and you don't want to start implementing anything until you've designed the perfect engine to be able to do anything you can possibly imagine.

It's a lot better to start off with a game idea and let that dictate your engine, since then it's a lot easier to figure out exactly what the game needs to be capable of and what limits need to exist. Plus it's not as bad to have a hacked together engine if you already know what your game is going to be like, because so long as it can do the specific things needed for that game, it doesn't NEED to be extensible or maintainable (note: this is assuming that the game, once finished, is actually finished. Don't hack together an engine for an ongoing project or you will hate yourself later).

(this isn't a criticism of you, Mug, since obviously you've demonstrated the ability to actually get something made with this approach. I'm just saying that it's an approach that can easily overwhelm people like me)

# ¿ Oct 2, 2012 16:50

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Hellbeard posted:

Just coming out of lurk mode to post these, re: the recent discussion on "pixel-art".
Made them for an isometric turn based combat prototype that didn't go through.

These are gorgeous. Did you do them by hand or are they 3D modelled and then you played with the renders to get that look?

# ¿ Oct 3, 2012 15:29

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Epsilon Plus posted:

How do I figure out what engine/SDK/whatever I want to learn to make my game in? GameMaker suddenly appearing on Steam miraculously reminded me that I have a lot of great ideas for games and should probably make them instead of waiting for one of my friends to magically become a competent programmer. The games I want to make are more reliant on menus and buttons than movement and physics. I'm willing to (try to) learn proper programming; I just don't know where to start. Programs like GameMaker and platforms like Flixel and Stencyl seem more focused on action games, sidescrollers and the like - lots of focus on moving objects around the screen and the like. Unity looks more flexible (and one of my favorite games and an inspiration to me was made for it - AI War), but it seems really focused on 3D environments. I know that Source and UDK and the like are obviously not good choices for me: I can pick out the wrong answers, I just can't find the good ones.

I'm starting with something simpler (a ripoff of Super Crate Box that will be undeniably lovely, I am sure) in GameMaker but knowing what I should make the move to when I'm ready to start my big-boy game would be nice - then I could maybe port over my current project.

Most people in the thread are probably going to say Unity, and I can't really argue against it since it's the most flexible system of any of the things you mentioned. It seems focused on 3D but it can make 2D as well (someone posted a 2D Unity game a page or two back). UDK is probably going to get you better performance in a 3D game, but you have to learn UnrealScript and are limited by what it can do (since it doesn't give you base engine access like Source), while Unity just uses C#.

I haven't really used Unity much since I'm still kind of in my "Tooling around with GameMaker" stage of growth, but it's the most logical progression when you decide that GameMaker isn't a robust enough toolset for what you want to do. Flixel/Stencyl is a good intermediate step though, since they might seem focused on action games, but everything is really. That doesn't mean you can't make whatever you want with them - Flixel is ultimately just a rendering engine, not an SDK. It doesn't prevent you from doing anything you might have done from scratch in ActionScript; it just makes it a hell of a lot easier to get set up and coding up gameplay instead of frame clocks and the like.

# ¿ Oct 4, 2012 05:03

The Cheshire Cat: Jun 10, 2008; Fun Shoe

HelixFox posted:

Posts like the above always make me feel like a Bad Coder.

Pretty much everyone is a Bad Coder, don't worry about it too much. The thing about that stuff is that it is the right way to do it - but if you can get stuff done without it, then you're still producing something and so that's still better than someone who does it the "right" way and never gets past the documentation phase.

That's not to say that if you can get stuff done you should just ignore the things Regalia mentioned; you should ALWAYS strive to do a better job. You don't have to be perfect, but you should still be aiming for it.

# ¿ Oct 5, 2012 14:45

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

I made a "Main Menu" today, finally. It runs as part of the main game loop so the game just keeps running in the background in a kind of screensaver mode. If you're in your "home" area, the camera zooms in a bit and shows you random stuff that's happening about the place. If you're in a mission, the camera zooms in a bit and just cycles between your player characters.

Works good, feels good. I've made a logo for the game now, too. It's the first time I've ever actually written down the game's actual name anywhere. Hoping to go into alpha sometime soon and actually announce a "game" to the world.

I'm not sure if you came up with that idea on your own but it actually matches a nice bit of advice I'd read in a "Learning game design in C#" book a while ago. Essentially it recommends having your different modes (like menus, tactical view, etc.) loaded into a stack in your main game loop. The main loop then always processes the topmost item in the stack, and pops it off when you leave that state, letting you pick up from the previous one exactly where you left off.

I guess since what you described keeps the main game running it's slightly different, but it's a similar idea - with yours it's just processing the whole stack instead of the topmost item.

# ¿ Oct 6, 2012 17:51

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

Haha, creating a window and button based interface is some of the ugliest code in EVERY project I've worked on.

It always is. There's just no way for it be elegant. It's all just boring "initialize this element with these properties, put it at X and Y" repeated over and over several dozen times.

# ¿ Oct 11, 2012 04:33

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Another thing to consider is that you can convey information through sound as well. You could use generic "Powering up" and "Powering down" sounds when those switches are activated to make their functionality more obvious. Of course since we're talking about accessibility here, this naturally doesn't help deaf people, but they should still be okay with the visual interface; sound is just one more aspect of the design, not the whole thing.

Orzo posted:

The way for it to be elegant is to have it be data driven. Of course, writing the (ugly) code manually is fine if you only have a couple screens, but some kind of designer is probably desirable for large projects.

That gives me an idea--instead of writing a designer, you could probably do something neat by using the WinForms designer and then exporting the control locations/images/anchors etc to your own custom data format. Then you don't have to write all of the tedious aspects of a designer (dragging/resizing/etc).

It's funny, while typing that post I actually had the exact same idea. I just didn't post it because I wasn't sure it'd actually work, having never tried it myself. What I was thinking was that you'd set up your UI classes to mimic the WinForms API, so you can just design your UI in Visual Studio, then just search and replace with your own class names and you'll have everything set up for you without having to type a single line of UI code.

The main place I saw this falling apart was that if you're using something like Unity I'm assuming they probably already have their own UI classes that may not exactly match the WinForms stuff so the constructors would all be wrong. Although, you could just extend the Unity classes and set up the constructors the way you need them as a kind of interface between the WinForms designer and Unity, or whatever engine you're actually using.

The Cheshire Cat fucked around with this message at 15:26 on Oct 11, 2012

# ¿ Oct 11, 2012 15:24

The Cheshire Cat: Jun 10, 2008; Fun Shoe

floofyscorp posted:

I thought this was a flying book at first... But computer chip thingy definitely makes more sense

See I thought "Metal death football". But in my defense I'm on my work laptop which has both a high resolution and small screen, so it's kind of hard to make out small images like that.

# ¿ Oct 15, 2012 19:18

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Lord Humongus posted:

Does this look better?

Ah drat, I need to do a replay of RE and play Silent Hill now. RE isn't as dark as I remember it.

Thanks for the help dudes! Hopefully I can keep my motivation going instead of just shelving it like the rest of my games.

One thing to note about Silent Hill: It's only dark half the time. The other half is the iconic fog, which of course makes it impossible to see anything too far away but the stuff you can see is well lit.

The other half of the time it's quite dark, but the flashlight is very bright. One clever thing they did in the game though is that turning the flashlight off makes it possible to sneak up to/around enemies, which gives you incentive to turn it off if there's monsters around even though it's VERY hard to see without it.

# ¿ Oct 18, 2012 18:43

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

The correct phrase should be for game dev "If it works, ship it (to the QA dept)".

I have the craziest amount of backups. I have my dev folder saved every day from day 1, I can just download and run my engine from the 4th day of development. It's just a bunch of arrows and red lines flashing.

edit:
Here's a video you guys might like. This is how I make levels for my game. You can see the Isometric Tile Editor, the Map Editor, and the Campaign Editor all used and then the level running in the game. I made all the tools myself.
https://www.youtube.com/watch?v=azG3XDUFHmI

edit 2: Oh man that video quality is loving CRAP. Let me fix that.
edit 3: Oh, it came out of handbrake that way. gently caress it, it's good enough. Ship it.

I noticed that when you're placing walls you have to keep going back up to the menu to "grab" another one. It seems like it might save you a lot of mousing back and forth if you put in a hotkey to just automatically grab a copy of the last used block type, or do something like shift+clicking would let you drag a line of them.

# ¿ Oct 19, 2012 15:36

The Cheshire Cat: Jun 10, 2008; Fun Shoe

seiken posted:

Actually I already said this was awesome but it struck me right now that it'd be even more awesome if you could draw the static main body part another couple of times or so and loop it (like just draw exactly the same thing so that the slight inconsistencies cause it to flicker in a nice way. That'd be great and also help it pop out from the background more which you were worried about)

I couldn't quite put my finger on why it looked "wrong" to me, but this is exactly it. I think it would look better if the whole dragon was redrawn/recoloured for each frame, even if it doesn't actually move. It would give it a more "doodled" look. With just the moving parts being redrawn, it looks like they're somehow disconnected from his body.

It doesn't have to be full-on squigglevision, but like Seiken said, just a little bit of variation in the main body on each frame would help make it look more animated and consistent with the moving parts.

# ¿ Oct 22, 2012 16:43

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Shalinor posted:

For whatever it's worth, I can tell the difference, and this looks much better. Your old view cones always looked somehow out of sync with the character position. I'd just assumed it was some artifact of your grid based world.

It really does look better. Although I'm not sure if that's a result of the fix you did or just the smoother movement from the earlier change you mentioned.

One question: will the view cones be visible in the finished game, or are they just like that for testing purposes?

# ¿ Oct 24, 2012 16:31

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Lord Humongus posted:

Another room finished, I need another set of opinions.

Here it is, I need to know if this camera angle and tiles on the open side looks awkward:

also a second close camera shot with uneven tile spacing. And fog.

all the textures are just temps.

The tiles on the open side look a little weird. The room floating in space also looks a bit weird - it can work in games but the issue is that it makes it more obvious that the game is an abstraction*, which can draw the player out of the setting. It's not a big deal in some genres because immersion isn't important, but for horror it can be a mood killer. I have to say the lighting level is a lot better though.

One thing that you might try is a camera angle from the corner of the room - it gives you a nice wide view of the area without having to artificially cut away walls like in the first image, while also serving as an unusual looking angle to create a disorienting feeling which helps the horror aspect.

*(unless the setting literally has the player in a room floating in an endless void, in which case I'd guess you'd want to highlight that fact)

# ¿ Oct 25, 2012 18:51

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Mug posted:

Making pathfinding deal with "I bumped into another creature" had taken my whole day away from me today.

I've decided on a flow thats something like: Bump into another creature; move to the next best tile; mark the previous tile as slightly shitter incase you were thinking about ever going back to it; try going from there.

Then theres a bunch of counters for "how many times have I bumped into another creature today", "how many times have I jammed myself into a corner today", etc. Based on those numbers the creature will either switch to "straight line" pathing and then recalculate when it hits a wall - or randomly take a step left/right and try pathfinding again from there.

I test it by putting together a squad of 5 creatures and making them frantically run through doorways and up and down coridoors. I'm *almost* totally happy with it.

Pathfinding is one of those things I always have trouble wrapping my head around. It seems so simple on paper, just because there are so many well known algorithms for it... until you try to implement one of those algorithms and the whole thing runs at 10 FPS.

A thought about creatures bumping into each other though - maybe if two creatures are within a certain tile distance of each other, they would be able to see the path laid out for the other one, and would intentionally avoid stepping into tiles that are "claimed" by the other one? It would probably take a bit of tweaking to get it just right, but it might look nicer to have two entities seem to be coordinating and walking around each other rather than bumping into each other and pausing for a second to try to figure out how to go around.

It might be tricky to deal with the case where both entities have paths that overlap where they meet, since you'd have to figure out a rule to give one of them priority when it comes to who actually "claimed" a tile that both of them are pathing through. It would probably be simple enough to just set it up so whoever processes their next move first is the one that has to pick a new path, and then the later one just passes into the tile they've already used. Or if you wanted to get fancy, if your units have in-game ranks, higher ranking units would get priority on claiming tiles. That might have a nice little visual effect of making it so that officers always walk directly where they're going while other entities scramble out of their way.

The Cheshire Cat fucked around with this message at 17:16 on Oct 28, 2012

# ¿ Oct 28, 2012 17:12

The Cheshire Cat: Jun 10, 2008; Fun Shoe

SlightlyMadman posted:

The way I deal with the creature in the way problem is to add a quick check to my edge cost calculation that checks every tile adjacent to the actor for other actors, and considers those tiles to have double cost. When an actor following a path bumps into another actor, they recalculate their path, and since they just bumped into the actor they'll now be adjacent to them, and will route around them.

So far the only problem with it is that if two actors meet in one-cell hallway, and have no other path around, they'll block each other indefinitely. I haven't seen it happen yet except when specifically testing yet for it, but if it becomes an issue I'll just add a check to only allow a certain number of path recalculations without any successful moves, before abandoning the destination and resetting the actor's state.

Since the latter is a specific edge-case, could you just test for it directly? i.e. if they bump into another actor and they have no other free tiles around them except the one they just came from, then you know they're in this situation, and you could have it recalculate their path treating the other actor as an impassible barrier. Of course the disadvantage of that is that both your actors will now path out of the hallway and take the long route around, assuming there even is another route for them to take, rather than one of them backing out and taking the long way while the other continues on its original path.

In that sort of situation it's probably better to just fix it with your game design rather than through code; just don't make any one-tile wide hallways, or allow actors to squeeze past each other (maybe at some sort of movement speed penalty) if they can't simply walk around, ala Dwarf Fortress (if the ability to block movement is important to the gameplay, you could set it so that actors can only squeeze past friendlies).

# ¿ Oct 29, 2012 15:21

The Cheshire Cat: Jun 10, 2008; Fun Shoe

HelixFox posted:

I don't even know what a quadtree is.

It's a way of organizing your space so that you can look at it more efficiently than just a huge 2D array of tiles.

Essentially, it divides up space in such a way that big open areas are only one "tile" as far as your pathfinding is concerned, regardless of how many actual tiles they contain. You can do this because if it's all empty space, then any entity can reach any point in that megatile from any other point in the megatile by just pathing a straight line, so doing pathfinding within that area is just wasted processing time since you know the simplest possible path is already correct.

The actual algorithm for dividing up the space is just dividing your space into four quadrants, and if a quadrant contains an obstacle, you divide it by four, and just continue that recursive pattern until you hit some minimum possible size (if you're using a tile-based grid for your game, the logical minimum would be one tile).

You basically trade some precomputing time for better runtime performance, and if your maps are all hand designed, the precomputing can be part of your process for compiling them so the user never has to wait for it. With random maps you'd have to run it on the fly, but so long as they aren't really huge or really complex, it shouldn't take too long. It gets kind of tricky if your maps are both random AND have dynamic obstacles, but you could probably modify it to update the relevant parts of the tree if an obstacle moves or is created/destroyed.

# ¿ Oct 30, 2012 15:33

The Cheshire Cat: Jun 10, 2008; Fun Shoe

There's another pathfinding method called Jump Point Search which I'll admit I don't fully understand yet, but it apparently has very good performance as well. It's also specifically designed for tile-based maps, as opposed to the quadtree method which can be implemented in tiles but is really meant for continuous space.

# ¿ Oct 30, 2012 16:41

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Abjad Soup posted:

Is it necessary to call out that Jones is the one who gets invulnerability, or could you reword it as something like "Become invulnerable for a bit"? (Eyeballing it, I'm pretty sure "Become invulnerable" would fit on a single line, too.) Or maybe try switching the effect and Next Rank descriptions around.

Probably depends on how the rest of them are worded - you want to keep the phrasing consistent in that sort of thing.

Second person vs. third person descriptions also subtly break down or reinforce the connection between the player and the player character. You see the former a lot in games with silent protagonists and such, where the character is really just a surrogate for the player. The latter is when you want the character to be their own thing with a more defined personality ("Personality" doesn't necessarily mean they have to talk, just that they're memorable. Mario has personality even though the games have no real plot or dialogue).

That said, I don't know how the game itself works - given the whole "fireman" theme, is fire the only source of damage? You could save some space while keeping the feel intact by replacing "invulnerable" with "fireproof". Of course that doesn't work if there's other things that can hurt you since it wouldn't be clear that it actually means "you take no damage".

Or hell that works. "Jones takes no damage for a period of time". It's a little bit longer but the individual words are much shorter so they'll fit into the lines better.

# ¿ Nov 3, 2012 05:45

The Cheshire Cat: Jun 10, 2008; Fun Shoe

RoboCicero posted:

Dude, if he has 4 to 8 gigabytes of text files that he's written himself holy god drat. I'm pretty sure at that point you either have enough raw data that it starts self-organizing on your hard drive or you can just convert it into a 10-volume book deal.

That's assuming he's actually written it already. He may just be estimating how big it will be when he's finished. Which I'm pretty confident is the case given the huge range between 4 and 8 gigs worth of text. I'm pretty sure if it was actually written he'd be able to estimate the size with a bit more precision than "give or take 2,147,000,000 letters"

# ¿ Nov 27, 2012 19:42

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Shalinor posted:

Edmund McMillen did a post-mortem on Isaac, and it is fantastic. Very worth reading, for anyone trying to push genre boundaries.

... I think if I had to pick one contemporary designer that inspired me most, it'd be Edmund. Dude is just awesome.

It's your first release as an indie studio right? I'd say that "risky" is a better SECOND game option. Unless you can afford to eat the losses if it flops.

Plus a big part of getting success with a riskier idea is name recognition. People are going to be more likely to give it a shot if they can remember playing something else of yours that they enjoyed. Binding of Isaac is pretty cool, but I bet it would have been just an obscure little Roguelike-like if it had been made by some nobody in their basement instead of Edmund McMillen.

# ¿ Nov 29, 2012 16:48

The Cheshire Cat: Jun 10, 2008; Fun Shoe

DeepQantas posted:

Hey guys. Since I managed to actually do something for a change, I figure I might as well post about it everywhere I can.

This is Footbrawl Quest...

*snip for space*

This is a wonderful thing you've made here.

Is there a way to have your guys pass the ball by throwing it? Or can they only drop it and have someone else pick it up?

# ¿ Dec 1, 2012 06:38

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Apple Jax posted:

That was our worry as well. We're putting in a few elements into the bridge itself to give a representation of what's going on outside which might help switching back and forth too much. The upper left of the bridge already shows where the ship is facing and we're thinking about putting in a few more details there. And, the ship diagrams on the right will show what the shields are set to along with Mark22's (the robot) console which will show what the weapons are set to.

I suppose it would probably be tricky to find the screen real-estate but maybe have a viewscreen of some kind right on the bridge, so you don't have to switch between screens at all? At the very least, you could probably set it up so that you've got a small viewscreen in the bridge view, and you can zoom in by clicking it to see more detail. That would probably help smooth out the transition and if the broad strokes are visible while zoomed out it would also help reduce the need to switch back and forth.

# ¿ Dec 3, 2012 21:09

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Vino posted:

Hello goons. Behold my weak attempt at a Minecraft clone!

https://www.youtube.com/watch?v=A3etgRY5D5k

I know it's just temporary programmer art, but that little robot is adorable.

What are your long term plans for the game? It seems like you could go in a lot of directions with what you have so far.

# ¿ Dec 6, 2012 17:02

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Hah I didn't even realize you were talking in the video; I'm at work so I just watched it with the sound off. I'll have to take another look when I get home.

I think you shouldn't let the similarities bother you to the point where you refuse to implement a feature because it might remind people too much of another game - if you feel that your game would benefit from that feature that's all that should matter. The key is really to narrow down your focus early on so you don't end up with crazy feature creep because unless you want to develop it incrementally over time forever Dwarf Fortress style (which is fine if that's what you really want to do! It requires crazy dedication though), having a huge list of things that would be cool will just make you feel that the project is insurmountable.

One thing that strikes me is that Infinity is being designed as an MMO, which means a lot of that space will be used up by players. Since you're just a lone developer an MMO is probably way too ambitious, but that also means you need to think about reasons why players might want to explore that infinite amount of space; one thing about Minecraft is that it generates a crazy amount of terrain, but you really don't NEED to use that much space at all. In single player you can basically just plop down right where the game spawns you and it's just as good as if you were to go wander for days off in some direction, because the thing about random/procedural generation is that it creates stuff that's all new, but also all more or less equally interesting, in the sense of once you've seen one area, you've seen everything.

Making exploration rewarding without pre-designed content is tricky - off the top of my head one thing you could do is set up your planets so that they can have radically different looks based on things like climate, atmosphere, etc. Even something as simple as "this planet is red with purple trees that look like giant mushrooms" would help make it feel like a different place than a basic Earth environment - although alien flora and fauna also means more work creating content (unless you can develop a system that can create unique looking stuff dynamically, which would be pretty cool but also probably pretty hard).

You might also be able to extend the existence of different environments to create natural gameplay elements - maybe to visit certain extremely hostile environments you need to first craft yourself a vessel and suit that will be able to withstand them - but you can find things in those environments that can only be found under those extreme conditions. Try not to fall into the "single biome planet" trap though; if the conditions planetwide are the same everywhere, then really the player is only going to ever bother to explore the first few acres they happened to land on. If they're currently in a desert but know that there are also tropical rainforests on the same planet, they're going to have more incentive to actually take a look at the whole thing.

# ¿ Dec 6, 2012 22:25

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Nition posted:

I just implemented rotating parts on the build screen, which means now I can build a car POWERED ONLY BY GUNS.

https://www.youtube.com/watch?v=5hcZxXP-UE4

Hah, it reminds me of GTA3 where I used to get the tank going about as fast as a sports car just by pointing the cannon backwards and holding down the trigger while accelerating.

Nthing that this idea is really cool. It seems like such an obviously good idea that it's amazing that nobody's really done it before. I guess it's one of those things that's more difficult in execution than conception, but hey it seems you've got that part going pretty well too.

# ¿ Dec 7, 2012 19:53

The Cheshire Cat: Jun 10, 2008; Fun Shoe

I like the idea of colour changes based on various events. It would be really easy to read visual feedback that's right there in the game world rather than on some UI element. You could also use different colour schemes to differentiate areas, but that might not be necessary if the player never really has to do any backtracking.

# ¿ Dec 16, 2012 17:45

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Spelunky was made with Game Maker as well (not the 360 version though). Unless you want to do some really weird and fancy graphical things, I don't think there's really any reason why a particular game concept wouldn't work in GM.

# ¿ Dec 21, 2012 00:22

The Cheshire Cat: Jun 10, 2008; Fun Shoe

DeepQantas posted:

The new GM versions are hideous and overpriced, tho.

Achievements? Green on black? Blergh...

e:
The only *real programming* thing I've really missed in GM is writing functions for objects.

The objects do have inheritable events, and you can even have custom events, but those events are pre-named and limited (User 0 to User 15, or so) so it's messy as hell.

You could use the scripts to keep your program in order, but those scripts aren't actually functions. They act as if you'd copy-pasted them into the code, so if you happen to use variable in the script that has the same name as a variable in your objects, you mess things up.

e2:
Also I'd like to have separate "dumb" objects for storing data without taking an FPS hit.

*edit* whoops, new page. Quoting to make it clearer what I'm replying to.

That's one reason to look at Stencyl over GM - it's got more or less the same kind of user friendly "I don't know poo poo about programming but I want to make a game!" interface, but when you do want to get in the code, it's all running on flixel so you can just dive right into the actionscript and code it like normal. The shortcomings of GML bug me too, but it's more of an academic thing since of the few games I've actually gotten around to making, GML has never actually been unable to do something I needed to make the game work.

# ¿ Dec 21, 2012 18:16

The Cheshire Cat: Jun 10, 2008; Fun Shoe

GI_Clutch posted:

I haven't worked on anything game related since I put together DYSH for one of the goon game jams earlier this year using GameMaker's HTML5 edition. I purchased the Android export module earlier this year because I've always liked the idea of being able to say, "Hey, try this mobile game I made!" The other day I decided I'd try making another adventure game along the lines of DYSH, only doing it properly as I have more than a week to do so.

I figured I'd make it a mobile game to kill two birds with one stone. The big thing I'm trying to figure out right now is exactly how I want to implement the interface for commands. I grew up playing Sierra adventure games, so my first instinct was to have a bar of commands as seen in this WIP shot.

I'm trying to figure out if this is the route to go down or maybe something else. Part of me feels like it's too much of an old school design choice for a mobile game. Another part of me says it is completely intuitive and reduces the number of clicks a user would need to perform (I'm used to users complaining if a process now takes an extra click to perform, but maybe gamers don't care about clicks as much as government employees). I realized I'm missing a talk command, but I could probably just integrate that into the interact command to keep the number of commands down to keep them large enough and easy to select.

Another idea I had was to display a context menu when an object was clicked with a list of applicable commands. I loved the smell and taste commands in Space Quest IV, so it would be nice to be able to fit in some extra fluff commands.

The correct answer is probably "do whatever you want to do", but I figured I'd see if anyone had any opinions or better ideas.

Personally I'd think a context menu would be the best approach for anything on a touchscreen. It's a lot easier to back out of accidentally touching the wrong thing by going noun -> verb instead of verb -> noun, since the latter involves the verb step before the mistake happens, which is one extra button press that is probably going to end up happening a lot of times (I don't think I've ever played a game on my iPhone where I never had the screen register something way off of where I actually pressed).

# ¿ Dec 29, 2012 04:31

The Cheshire Cat: Jun 10, 2008; Fun Shoe

HelixFox posted:

I don't have a problem with discussing board games here. There's a ton of cool design going down in the board game space that a lot of video game developers should take note of.

Not to mention that a lot of video game designers are big into board game design as well. The new X-Com was designed to play a lot like a board game, which is why a lot of the numbers involved are actually quite simple; all the math involved in calculating hit chances is basic addition and subtraction.

Personally I think that designing a PC game exactly like a board game is a bit of a waste of potential - the whole advantage of PC gaming is that computers can handle calculations that would be far too complicated to do by hand with dice, so you can use more varied statistical models beyond "60% chance of success". At the same time, there is a certain advantage to having mechanics that are simple enough that a player can work them out in their head, since it gives them a better idea of how strong their units are.

I think the key is that if you're going to go the "like a board game" route, you need to expose all your mechanics to the player in order to actually take advantage of that design choice. If you're going to conceal exactly how certain things are calculated, you might as well use more complex maths to better model what it is you're trying to accomplish, since if the player can't see it, it doesn't matter whether or not they can understand it.

# ¿ Jan 29, 2013 06:34

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Osmosisch posted:

*Board game stuff*

I like the idea of simultaneous move planning as a substitution for fog of war (which honestly is pretty much impossible for a board game, unless you have the players each set up with their own boards Battleship style and that would just get really confusing with the number of players your game would have). It's very rare that board games force players to act entirely proactively - turn-based systems tend to encourage one player to lead and others to react to that player's moves (to be a good player means being able to take the leader position the most often and dictate the flow of play). Chess is a pretty classic example of what I mean here; it involves a lot of thinking ahead, but any game that's not purely reflex based requires some level of planning. The main flow is instead one player leading with their chosen strategy and the other playing trying to make the best moves to counter that strategy. Since Chess is such an old game, this has been examined to the point that a lot of moves have designated counter-moves, so that at the highest level of play a lot of the game is almost automatic.

Your biggest challenge will probably be in making a simultaneous system like that really work, but I think the action cards idea is the right track - you should probably stick with a fairly simple set of verbs in order to keep players from having to root around too much in the deck just to pick out what they want to do. Alternatively you could just have players write down their actions behind screens and place them face down by the board when they're done - but I like cards better since it allows for misdirection with those blank "bluff" cards. You can't see what moves an opponent is making but you can see how many cards they've played - that could be an interesting psychological aspect of the game.

You mention jungling and such, but I think those are features that would probably be best to just leave cut. With a board game you really want to cut the gameplay down to its barest essentials - this is another reason why board game design is interesting to think about even for video game designers. A lot of PC games end up being pretty bloated because the PC does all the heavy lifting so you can just throw more features in there because why not? With a board game nobody wants to spend an hour resolving each turn, so you absolutely need every gameplay element to be a meaningful contribution to the primary playstyle or else it only serves to make the game take longer and be less fun. The main thrust of the action in a DOTA style game is pushing lanes, and if you're converting it to a board game, every action taken by the player should be related to doing that. You level up and buy items because it makes you better at pushing lanes. You fight enemy heroes because it prevents them from pushing your lanes. That's where your game should focus, which also means cutting any heroes whose strengths aren't related to pushing or defending lanes in some fashion.

# ¿ Jan 29, 2013 16:55

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 10:57

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Shalinor posted:

"Too many concepts to explain" almost always means you've got a game that no one will play. You can do a very complicated game and still explain things one at a time. Look at X-Com for inspiration.

Honestly, I kind of hated X-Com's tutorial (you're talking about the new one, right?) because of how slowly they introduced new stuff. I do understand what you mean though and it is important not to inundate the player with options right at the start (this is the main reason why it's really hard to get into Dwarf Fortress or X3 - they're pretty easy to play once you know what you're doing but the amount of stuff that's available from the start can intimidate people into not even trying). It's a bit of a balancing act.

Honestly, if you feel your game is pretty simple, it might be better to eschew a tutorial entirely and just stick a "How to Play" option in the main menu. If the stuff you described in the previous post is the entire game, it seems like it would be simple enough for a player to pick up even without reading the rules. You can also set it up so that every time the player has to do something, there's an instruction written somewhere on the screen of what they need to do. A lot of games do this and it's very non-intrusive; you just have a designated spot on the UI that says "Place a tile" when it's the players turn. You could use the same spot for other gameplay related messages so players would be naturally inclined to read it.

# ¿ Feb 1, 2013 16:41

The Something Awful Forums > Discussion > Video Games > Making Games Megathread: Congratulations on releasing the horniest game of 2022

«‹›9 »