|
Mug posted:How often do you guys have an idea for something to put in your game, but you have to create a little prototype of the idea working stand-alone before trying to put it into your game? That is actually how I program all of my projects, and not just for game ideas, but for the framework stuff as well. I find it's a lot easier to reason about and test an idea in isolation. And since you can tests things in isolation, if it doesn't work when you add it to the game, you know (to a reasonable degree of certainty) the problem is in the intergration somewhere. I guess what I'm really doing is writing small, very specific libraries. It forces you to write the game in a modular way, which is A Good Thing. Because I thouroughly test each idea, I write it in the game language so I know I can just drop it in without having to re-write anything.
|
#
¿
Sep 22, 2012 09:14
|
|
|
|
| # ¿ Apr 28, 2024 15:13 |
|
|
Senso posted:Which IDE do you use and how do you deal with having separate smallish projects? Let's say I'm using Visual Studio, it would be a pain to setup a new project with all the particular bindings and settings, just for a prototype. I wonder if there is an easy way to do that. I do this in VS. Personally, I just set up a new solution for each prototype. By using property sheets, and a pretty simple main loop I can get a new idea set up in a matter of minutes.
|
|
#
¿
Sep 25, 2012 08:01
|
|
|
Mug posted:Can I get some opinions on how I plan to handle save/resume in my game and if anyone thinks this is good/bad ideas? Personally, I would let players save when they want, as often as they want, in as many slots as they want. Players who want to be challenged will impose their own artificial constraits, whilst players who aren't very good won't become frustrated by a 20 year old mechanic. Players WANT to play your game, don't give them a non-game-related reason to quit. If, however, you want to make saving a part of the game difficulty, why not just record the amount of times they save, and award accordingly? Again, players who want the challange and the accolade will try to save as little as possible, while people who just want to play can do so. Regalia fucked around with this message at 08:28 on Sep 29, 2012 |
|
#
¿
Sep 29, 2012 08:25
|
|
|
ichibanMuffin posted:Does anyone have any advice about what to read about ways to put together a game engine from scratch? I'm probably going to be in the minority, but for me, writing your own engine is not that difficult as long as you're disciplined. Firstly, you MUST write a design document. If you don't know your game inside-out before you begin coding, you're going to give yourself a lot of headaches. If you're a CS major you've probably already been taught this and promptly disregarded it because it's not cool. You're right, it's not cool, but it is vital. Writing a design document takes time, but to my mind, is one of those things where the rewards are equal to the effort you put in. When writing it, you'll invariably change parts of your game when you start to see the bigger picture and how things interact, and you'll have to re-write large chunks of the document several times. These are the same changes you'd have to make if you started coding blindly. The difference is it's hell of a lot easier to re-write a document than it is to re-write code. Once you've finished the design document comes the hard part and the discipline. You must not change the design! Seriously, you have to have a point where you say "that's it. That's the game I'm going to make and nothing more". Of course you'll have to make minor changes because of unforeseen things, and probably changes to balance the game when it’s playable, but these are small things that your engine should be able to cope with easily. If, however, mid-way through development you come up with some awesome game-changing idea DO NOT IMPLEMENT IT NOW. Write it down, leave it mature and if it's still as good as you thought, congratulations, you've got an update/expansion/sequel. The point is, you don't add it now or you'll never ship. So now you know what you're writing an engine for, do just that. Write an engine exactly for your design. Do not try to write some reusable, general game engine that you can use for future games; write an engine for your exact requirements. Use magic numbers, take shortcuts, don't try to guard against things that can't happen in your game (but may happen in the general case). Optimize for productivity. When you write your next game, you start again. Now to the crux of your problem - designing the architecture. It has been alluded to already, but there is no catch all game engine design. And this is particularly true if you follow my suggestion above of writing the engine for your specific game design. My guess is what you really need, is to learn a couple of useful ideas for designing software in general. There's an almost infinite amount of literature on the subject of designing software, but I've found there are a few core ideas that I always fall back on, and things I use all the time in my own programs. For me, the following are priceless and used comprehensively throughout my own engine and every commercial program I've worked on: Interfaces/Protocols Double dispatch Strategy design pattern Template design pattern Factory design pattern Abstract design pattern seiken mentioned that you should start with an engine of size N, and use the experience and knowledge gained on your next project. Ultimately, this is the only way to do things. Experience is the key ingredient to making anything and it's no different for programming. I suggest reading the Quake, Quake II, Quake III, and Doom 3 code reviews and see how id Software evolved each engine based on the experience of the previous one. If you understand C, you can even get the source code from github and take a look yourself. Many people will disagree with what I've written, and that's fine. These are just the things I've found in my years as a software engineer that help ease programming complicated software. tl;dr You need a solid game design, discipline, knowledge of software design, and experience to write a scalable game engine.
|
|
#
¿
Oct 5, 2012 09:09
|
|
|
Juc66 posted:Who really cares what the exact definition of an engine is. I don't think it's a good idea for someone who has clearly never written a game engine, or even knows what one is, to bestow upon us the virtues of not writing one. It seems your commentary is based entirely on some fictional idea of what an engine, and indeed, what programming is.
|
|
#
¿
Oct 5, 2012 20:25
|
|
|
Juc66 posted:the part I'm taking issue with is partway down regalia's pretty good post Ok, that's fair enough but we same to be arguing about the same thing. We're both trying to save time and boost productivity. You're arguing for reusable generic code, which (possibly) saves you time in the future, and I'm arguing for taking shortcuts and coding only for your requirements, which saves you time now. You may not have checked out the two links that are embedded in the quoted statement, but they're there to clarify the point I was trying to make. The first link, a xkcd comic, which meant to point out that making something generic does not necessarily save you time because you have to spend a lot more time developing it in the first place. You have to make sure it works for all the corner cases and possibilities that may not even be possible in your game. I'm not saying its a wasted effort all the time, but it can be. The second link is a talk by Jonathan Blow (of Braid fame), in which he speaks about optimizing for developer productivity. The talk is too long for me to repeat here, but its worth a listen and may clarify my point. In my opinion, indie games in general are too small to gain much from making code generic as it is often far quicker to write for your specific needs, rather than for every game you might make sometime in the future, maybe. Code for what you need now, not for something that may never happen. In my experience, it's usually a waste of time.
|
|
#
¿
Oct 6, 2012 08:44
|
|
|
Orzo posted:Hey, just wanted to let everyone know that Indie Game: The Movie is now available on Netflix instant. Seems like something a lot of people here would enjoy. I thought this was a great film. It really captured the struggle and stress of making a game; especially if you're betting your livelihood on it like those guys were. Even my girlfriend enjoyed it and she's never played a game in her life.
|
|
#
¿
Oct 9, 2012 07:53
|
|
|
Serenade posted:One of the most notable characteristics of indie games are smaller player bases, which could lead to a game dying quicker. This should have said "One of the most notable characteristics of weaker games are smaller player bases". The key word here is weaker (I tried to find a work that didn't offend), not indie. Poor triple-A games have small player bases, too - because they're not good. Look at all of the major MMOs that have failed in recent years. They didn't fail because they had small player bases. Rather, they had small player bases because they failed. A good game is a good game, whether it's indie or not. If you make a good multi-player game people will play it. Don't be put artificial constraints on yourself. Be confident and go for your idea. Serenade posted:It is hard to find good evidence of it, but it seems to vary from game to game. Yes, the variance is entirely dependent on whether the game is any good or not.
|
|
#
¿
Oct 12, 2012 10:16
|
|
|
Mug posted: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. Out of curiosity, why don't you just use version control?
|
|
#
¿
Oct 19, 2012 09:35
|
|
|
Mug posted:^I can't really factor one creature's pathfinding results into anothers because they all recalculate every time they hit a wall or their target goes out of their line-of-sight or if they just feel like it. A couple of ways to speed up path-finding (assuming A*, although these tips probably work for other algorithms) are:
|
|
#
¿
Oct 29, 2012 11:37
|
|
|
Mustach posted:I'm probably misunderstanding you, but if the heuristic is appropriate, A* shouldn't be searching every tile on the map (assuming it's not something like a 1x2 map, etc.). No, you're right; it was poorly written on my part. What I meant, was A* will still have to search at least every tile on its path. Even when going in a straight line, at the very least, A* will have to find the next tile, and the next tile, and the next tile, and so on. For example, in the paper Using Quadtrees for Realtime Pathfinding in Indoor Evironments, the authors state that on a regular grid with 60000 tiles, A* took 0.75s to calculate a path from one corner to the opposite corner (there are obstacles). Using a quadtree, A* took 0.00004s. This is because the quadtree reduced the search space from 60000 nodes, to 990 (which is also a pretty big saving on memory). This is not the whole story, however. When using a quadtree you'll most likely want to rebuild the tree every time something moves. According to the paper, a rebuild of the entire tree took 0.02s. Nevertheless, the total time to entirely rebuild the tree and complete the search took 0.02004s (a 97% improvement). To further build on this, you don't have to rebuild the entire tree. You may simply rebuild the parts that changed, which allows you to build the initial tree in a pre-process step, netting you an even bigger win.
|
|
#
¿
Oct 30, 2012 09:30
|
|
|
Has anyone got any ideas of what might cause a huge, sudden jump in fps? Usually, my game runs at around 4500fps, but every now and then, when it starts up it runs at about 1500 for a minute or so and then jumps back to it's usual 4500. The slow down is always when the game starts and never after it's been running for a while. I can verify that code-wise, nothing is changing. There's no extra allocations, or some AI or something I'm not aware of. It just happens. Obviously, game-wise it doesn't make any difference since it's still running stupidly fast, but it probably means there's something wrong somewhere and I'd rather have piece of mind. Here's an image of what I mean (the first number is the current fps, the second is the average, the red line is where the jump occurs).  If it makes any difference, I'm using an ATI Radeon HD 7870 and OpenGL/GLSL for the graphics.
|
|
#
¿
Nov 5, 2012 18:12
|
|
|
Polo-Rican posted:It could be a trillion things but it's probably the debugger itself causing the slowdown. You're gonna want to look into this issue ASAP because 1,500 frames per second is not acceptable. I think you're probably right. It doesn't seem to happen if I run the game without the debugger attached, but then, it is an intermittent "problem". And I know; how are people supposed to cope with 1500fps? In all seriousness though, there's nowhere near as much going on at this stage in development as I plan when it's done, so the fps is going to severely drop. And besides, my target spec is a lot lower than what I'm developing on. DeathBySpoon posted:What are you developing it in? If you mean language, C++. If you mean IDE, VS2012.
|
|
#
¿
Nov 5, 2012 19:23
|
|
|
DeathBySpoon posted:This is true, but when your target FPS is 60 and you're worried about it slowing down to 1500, I think you're in the green. I don't think I made myself clear enough in my original post. I wasn't concerned that my game dropped to 1500 fps per se. I was concerned because the problem was intermittent and only lasted for a minute or so. Regardless of the fact the game was still running at 1500fps, it was still a 70% drop in performance, which is a problem by anyone's standards. Anyway, it seems as though it was just the debugger slowing it up occasionally, as Polo-Rican suggested.
|
|
#
¿
Nov 7, 2012 14:07
|
|
|
Vino posted:Hello goons. Behold my weak attempt at a Minecraft clone! This is a great start with some real potential. Good job! It strikes me more of an Infinity clone than a Minecraft one, however.
|
|
#
¿
Dec 6, 2012 15:40
|
|
|
The White Dragon posted:Hey, tangentially related to the problem I was having earlier because my composer reminded me that this is a thing when his seven-year-old laptop refused to run my game: With OpenGL you can query the capabilities of the hardware, including the max texture size they can handle. I know you're using XNA/DirectX, but you should be able to do the same thing. Then, you can re-size or split your textures up as some kind of first-run-initialization so that it can work within the constraints. If you don't want to do that, I'd either list some generic term like "inexpensive, modern gfx card" as a requirement, create some kind of compatability program that prospective customers can run to see if their computer could run your game, or simply exit the game gracefully for unsupported hardware. Either way, the game should display a friendly message saying the computer doesn't meet the requirements and you'll give them a full refund if they return the game. As long as you're nice about it, most people won't have a problem. Some may even buy a new card! Personally, and especially considering the type of game you seem to be making, I'd make an extra special effort to get it working on older hardware.
|
|
#
¿
Aug 23, 2013 14:50
|
|
|
I have a question about 2D animation. Let's say I have a character with two states - idle and walking. How do you gracefully go from walking to idle without cutting the walk animation short? As an example, suppose my walk animation takes 2 seconds to run through one iteration before it loops again. If the player wanted to stop walking mid way through walking (and thus enter the idle animation), at worst, they could be waiting 2 seconds before the walk animation gets to a "nice" place to change into the idle animation. For more information, the player clicks on a destination to move to (think something similar to Diablo or X-Com). I was thinking that because I know the distance to the destination and the speed a character can travel, I could change the speed the walk animation is played at so that it is always in a nice state to change to idle. The problem here is that it may look like the walking speed changes all the time (although I guess this is how real life works). Anyway, that's my best solution so far. I just wondered if anyone here has a better way of doing this before I put the leg-work in. Pun intended.
|
|
#
¿
Dec 13, 2013 16:42
|
|
|
Thanks for the advice everyone. In the end, I decided that just cutting straight to idle isn't so bad. Although, I might have to make a new animation for very short distances, but I'll cross that bridge when I get to it.
|
|
#
¿
Dec 14, 2013 10:30
|
|
|
TooMuchAbstraction posted:Engines take a gently caress-ton of work to implement, as I'm sure you're aware. You can spend years working on one without anything really visible to show for it. Or you can download someone else's engine and start working on your game immediately, with something to show off in 2 weeks if you plan your milestones well. That's quite the exaggeration. For the vast majority of Indy games, the engine need not be very complicated, and in fact that is where a lot of people go wrong (writing an engine that is way more complicated than is required). Perhaps people can spend years on it (although I've never heard of such a thing), but those people are almost certainly writing more than they need. As for your remark about being able to immediately start working on a game by using someone else's engine; that's another exaggeration. People aren't born with knowledge of unity or unreal engine or whatever. You're completely neglecting the fact that you have to learn how to use these things. As an example, I've been a professional C++ programmer for over ten years and I would say I spend about 8 hours a day, 7 days a week programming in that language. I've never use unity or anything like it, and to say that I could write a game quicker in unity than in C++ is ridiculous. You're also neglecting the fact that the majority of time spent developing a game is on content creation and not programming. All that being said, I agree that if you're asking the question in the first place, or you're not an experienced developer, it's likely that writing your own engine will suck up more time than its worth and using a tool would probably benefit you.
|
|
#
¿
May 13, 2014 20:59
|
|
|
|
| # ¿ Apr 28, 2024 15:13 |
|
|
baby puzzle posted:I had thought to have an "unlock everything" option in the configuration menus... but I didn't include it in the final game.. yet. I'm trying to understand the mentality, I guess. I haven't played your game so forgive me if I'm off base, but as a hardcore Guitar Hero player it used to drive me nuts to have to unlock songs. If the game had an unlock everything code, it's the first thing I would do (and if it didn't I may never even play the game) and I wouldn't even touch the story mode. The reasoning is simply that I had no interest in the game's "progression" or any of the RPG elements, and I had no interest in playing all of the songs, especially the easy ones or the ones that weren't fun to play. I wanted to play the songs I liked, and I wanted to play them over and over and over again until they were mastered. That's where the enjoyment was for me. For other people, the enjoyment is going to be mastering the toughest songs, whether they like them or not. I would seriously consider adding the ability to unlock everything because someone like me would probably drop the game after a couple of levels. This is especially true if you game is similar to other rhythm games. I.E. It's not something completely new and I'll be able to pick it up pretty quickly.
|
|
#
¿
Jan 18, 2019 14:06
|
|