• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Indy Game Development: any GAF'er ever make their own game, or even make money on it?

I've begun working on several game ideas. I got gameplay and story figured out, and kind of know how to accomplish them.

Problem is, I don't know ANYTHING about coding or modelling and stuff. So, I figured, to learn shit it would be good to start with something easy.

My plan is to do a full-conversion mod for Amnesia, just to learn a bit of basics and make it easier. On me. Is that a good plan? Just kind of half-worried. Since I am bursting with inspiration and stuff I need to get it out.

But yeah, is doing something like that good for learning?
 
Raide - I'd love to take a look at your design and give you some feedback.

Thank you for the offer. I will post something up shortly that gives a summary of what the main idea is, some of the current thoughts I have and also what I am trying to get done.

I have done some GAF research on part of the idea last year and that has been helpful but I really need to think about how to get the project moving beyond some work doc. :D
 
I've begun working on several game ideas. I got gameplay and story figured out, and kind of know how to accomplish them.

Problem is, I don't know ANYTHING about coding or modelling and stuff. So, I figured, to learn shit it would be good to start with something easy.

My plan is to do a full-conversion mod for Amnesia, just to learn a bit of basics and make it easier. On me. Is that a good plan? Just kind of half-worried. Since I am bursting with inspiration and stuff I need to get it out.

But yeah, is doing something like that good for learning?
I'm not familiar with the tools for the Amnesia engine. Why have you chosen this specifically?

Also it sounds like an extremely ambitious project to me if you really have zero experience. Making a game is very difficult and very time consuming. I would recommend doing some smaller projects, e.g. modelling and texturing one object/making a level for an existing game/prototyping a simple game using gamemaker/unity/xna etc before diving in at the deep end.
 
I'm not familiar with the tools for the Amnesia engine. Why have you chosen this specifically?

Also it sounds like an extremely ambitious project to me if you really have zero experience. Making a game is very difficult and very time consuming. I would recommend doing some smaller projects, e.g. modelling and texturing one object/making a level for an existing game/prototyping a simple game using gamemaker/unity/xna etc before diving in at the deep end.

Well, because they got alot of great tools. It's easy to make the levels, and seems not too complicated to code for it. It seems simple in some ways. Simpler than beginning with a whole new game-engine where you have to do everything from scratch.

Here I can simply retexture and import stuff. It's mostly for learning how to code, and I will be handing off the more, custom stuff, like modelling and such to friends. Basically, it seems more user-friendly in some senses, and can make it a good option to just learn the ropes.
 
(sort of) quick test: Try an STL list to implement it. I think that allows adding and removing elements and might be implemented as a linked list (not sure). Then make a for loop to add like, 200-400 copies of the same entity. Make each one have a random direction and/or speed and "bounce" off the walls by changing the X and Y velocity when they hit the edges of the screen. If you have animation in your engine, make each one use like two frames of animation.
That's actually a really good idea. Might give that a whirl once I start to dig in! I'm on vacation from work next week, during which time I'm hoping to devote some time to a bunch of side projects I haven't had the time to work on. :)

I do think that having input handling separate is probably the best idea, so you can swap different input methods in and out, configure controls and so forth, and then individual button/mouse handler pieces of code could call methods on entities that need the information.
Yeah, that was more or less what I was thinking. I'd definitely like to allow the users to configure the controls to their liking if the default setup doesn't tickle their fancy. It would also let me not have to modify the handlers in more than one place, too. I'll probably go that route. I did it to some degree in the prototype game I made a few months back. I wasn't completely happy with how it worked, though. I'll have a chance to change things around a bit and clean it up.

bumpkin - the game runs great on 3GS (I have one myself) and doesn't drop below 60fps. Keep up the good work with the coding. If you need any specific help regarding what you're working on I can point you in the direction of our coder who'll be able to answer some questions for you - although there seems to be some good advice already being posted. If you need us, drop a mail to info@mojobones.co.uk and I'll hook you up. Also, we do all our audio in-house too, so if you need any advice there we can try and help.
Ah, awesome! And thanks for the offer on coding advice if I get stuck and am looking for some help. It's funny, I know people who are in the industry and are game programmers, but they're always too busy or just plain disinterested in helping me. :(

Neither for me, my entities have separate methods for touch(), drag() and untouch(). These get fired before the update() methods. I'd never actually had things set up like this before but it works amazingly well for my game and menus.
It sounds like a solid and flexible approach, for sure. I'm actually going to be building this engine on a Mac - using SDL & OpenGL - but I have tinkered with iOS development a bit and at least looked at some Android tutorials. I've designed, developed and published one iOS App so far, but it's just an informational sort of deal; not a game.
 
Thanks Limanima. I'll pass on your compliments to our resident artist: that should inflate his head for the next day or two ;)

We used an SDK called Marmalade, which allows us to deploy on multiple platforms from a single code-base. It's worked well for us, alongside using Box2D for our physics engine.

The compliments goes to all the team, because the gameplay seems to be very good too.
I can't believe you guys did that in 3 months.
Our team (read me and a friend of mine) is currently working on a project that started 1 and a half years ago and it doesn't look half as good as your game.

I'm going to check that SDK, because I want to leave XNA the next time around and develop for iOS/Android.
Thanks
 
Limanima - yeah, it was a hectic few months for sure. Lots of twists and turns, as is normally the case with game dev. For example, we actually changed the game from being an endless runner to being level based after working on it for 2 months :)

TBH, a lot of it is down to experience though. If most people had the experience of making games then I believe they'd be able to turn around projects in a quick time-frame. Luckily we come from a dev background so we know what to avoid and keep our game's scope to a managable level - which is a 'must do' IMO. I've had my fair share of getting carried away when it comes to scope/ideas and it's a harsh lesson to learn. Start small and build upwards.

On a side note - loving the fact that Tim and Double Fine managed to get their funding! I've seen a couple of posts regarding the issue and I wouldn't underestimate how important their track record is. Yes they've got a huge fan-base and lots of PR outlets, but the truth is, those guys are known for creating some of the funniest, well-written, cinematic games ever made and that's why their Kickstarter total is going ballistic. They deserve it.
 
Hi all, just going to post down my brief idea and see what people think. I have the design doc floating for a few years, along with other ideas but never really get around to working on them.



*****

The basic outline is a puzzle based side-scrolling shooter with more advanced Ikuruga bullet matching elements. The game is also a co-op focused game, since the main part of the game revolves around the players getting together to perform tasks.

Originally a XBLA idea, since the colour of the controller buttons played into the main idea. It was a 3 player game, with each player controlling a lovable blob on train carts, coloured like the 360 controller buttons. Blue, Yellow and Red. Green being reserved for something else. Like Ikaruga, the blobs can absorb the same colour bullets in order to spit out a stronger attack. Also, players of the various colours can combine to make a larger blob and absorb alternate colour attacks.

Each level will be split into 2 parts. The Cracking Phase and then the Destruction Phase.

The Cracking Phase is a single screen phase, where the players rotate around a circular track on the edges of the screen. In the middle is the boss encased in an egg/protective shell. The boss will shoot out coloured bullets and the players absorb them so they can fire back to crack the shell. Occasionally part of the boss shell will flash a different colour, which will be a combination of the players colour. So it might flash Orange, so Red and Yellow player have to head to each other and then button mash A to absorb each-other. Then they can absorb the large attack and do massive damage to the enemy crab...um, boss.

Once the Cracking Phase ends, the boss will explode out and run off. Then the Destruction Phase starts. This phase turns into a old-school side-scrolling shooter where you chase the boss down and kill it. The absorbing is still in there, as you try and slow the boss down. Other boss minions will appear, giving you chance to absorb lots of power. This phase will introduce inventive boss attacks and other set-pieces.

****

I could not decide if I wanted a cute 2D anime style to the game, which I think would look utterly awesome, especially for the bosses or if it should go a 3D style so the bosses and levels can be more detailed and complex.

If you have any questions, let me know. Feedback is most welcome and if you want to help out, that would be awesome. At this point all I do it write things and come up with ideas. :D
 
Definitely go with 2D to prototype it. If you wanted to prototype it for say, two players on computer, I think it would be quite feasible for Game Maker.

Personally I don't like the idea of mashing buttons (e.g. the A-mashing mechanic), but that's your call.
 
Definitely go with 2D to prototype it. If you wanted to prototype it for say, two players on computer, I think it would be quite feasible for Game Maker.

Personally I don't like the idea of mashing buttons (e.g. the A-mashing mechanic), but that's your call.

Now I wonder how easy it will be to get a prototype done...hmmm.

As for the mashing A, it could just be a simple button press to join and once the attack has finished, it auto ejects you. :D I wanted it to be a little more complex to absorb each-other but then thought that would be a little frustrating to do it all the time.
 
I'm not sure I follow all of the game ideas for the initial phase, but I would use the simplest graphics possible and the simplest configuration (two players on one keyboard, if you have someone to help playtest)...and then think about what it would take to script up in Game Maker.

Actually for GameMaker, one thing you will run into is that the free version (Lite) doesn't support sprite location if I recall correctly...so moving the carts in a circle would look silly. BUT, you could just not rotate the blobs and move them in a circle, and the gameplay would be the same.

You could have an object for each blob, and an object for the boss. The boss object would have a script in the Step event, and at random intervals or whatever (every so many steps, or each step has some set % chance), you could spawn a new bullet with a random direct. A bullet could be an object type, maybe with different sprites for the different colors. You can randomly pick which sprite shows up when you spawn the bullet. In a collision event handler for each blob, you could do some math to make the bullet reflect back towards the blob, and have a collision handler in the blob make the bullets do damage (also destroy the bullets).

It may happen automatically, but to be safe I would add code in the Step handler for the bullets to (besides moving them in their current direction) destroy them if they go offscreen. Or you could work out some sort of collision when they hit a wall.

I hope some of that made sense. If you start prototyping something, feel free to post screenshots or ask suggestions about scripting, since a lot of it can be much simpler than it sounds. :)
 

Thanks for that. I really have to sit down and go through some more tutorials for game maker. As for the sprites, I am sure circles and squares will do for the meantime. :D

Just wondering how the best way would be to makes them rotate in a circular path. Or at least how to get them to follow a defined path, since it might add more variety if each start was not just a perfect circle. Actually, just thought of another idea. Maybe mix in some platforming sections during the Cracking Phase.

As for scripting, I have no idea where to even start. So I will just have to try and get teh basic sprite layouts and go from there.
 
Make sure you are in advanced mode (in the file menu) if you are not already.

Go through some basic Game Maker Lite tutorials, for sure, and then try to find a basic scripting tutorial. What you want is to make an object (for instance oRedBlob with sprite sRedBlobSprite) and place that in your level. Then open the object properties, add a Step event, and either dig through the blocks on the right-hand side or try some scripting. Scripting isn't that bad. ALTERNATIVELY, you can try looking for a tutorial that uses timelines, and maybe not as much scripting. I just looked at an old test game and apparently I made a bat fly up and down using a timeline, even though I didn't seem to remember doing that. XD

Super silly script example if you want to try it: Open your blob object properties, add a Create event, go to the control tab on the right, drag the "Execute Code" block into the "Actions" column of your Step event, open the code block, and type the following:

Code:
hspeed = 4;

Then add another event called Step, do the same thing to get a code block, and type the following in that code block:

Code:
if(x > 400)
{
    hspeed = -4;
}

if(x < 0)
{
    hspeed = 4;
}

If you save it and run things, your blob should now run left and right. hspeed is a variable for an object that controls what its current horizontal speed is, and you can see a list of built-in/default variables here: http://gamemaker.wikia.com/wiki/List_of_variables

If the logic is not clear, here's how it works:
  1. When the object is created, set the horizontal speed to 4.
  2. Each step (frame) of animation, check whether the X (horizontal) position of the object is greater than 400. If it is, the object is too far right, so we change the speed to -4 to start moving left.
  3. If the X position is less than 0, the object is too far left, so we change the speed to start moving right again.

It's a silly example and not how you would do your circle, but hopefully it gives you an idea of what scripting would be. To do a circle, one way to do it would be to add code in the step function of the blob that says, if button (whatever) is down, move counterclockwise around a path.

You would actually have to use math to determine what the X and Y positions would be for that path, though. :) If you need math functions besides basic stuff, you can look here for a list: http://wiki.yoyogames.com/index.php?title=Category:Game_Maker_Functions Trigonometric funcitons should be in there like sin and cos, and if those work in Game Maker Lite, you could be set. You will probably want to create a new variable in your blob's Create event though, called maybe curPathAngle, and set that to 0.0 (code would read "curPathAngle = 0.0;"). Then you could increase the angle while moving counterclockwise, and use sin and cos to get the X and Y coordinates.

If this is all super confusing, then your next step would be to read up on some basic X, Y, sin and cos trig information. Let us know if you have questions!
 
@ Blizzard

Thanks again! Just working through the tutorials and it seems pretty simple so far. Again, I have no programming knowledge but things are very slowly working. Most of it feels like a jigsaw and I am puts parts together before it makes sense. :D
 
@ Blizzard

Thanks again! Just working through the tutorials and it seems pretty simple so far. Again, I have no programming knowledge but things are very slowly working. Most of it feels like a jigsaw and I am puts parts together before it makes sense. :D
Programming is not some mystical act, it's mostly just logic, getting used to things, thinking in certain ways, and learning the syntax. :)

This algorithm is killing me.

Fuck you, vague research paper.
What algorithm are you trying to do? I got on Steam to fix it for you about it but you're not online. =P
 
To those of you who have or are planning to release games that costs money; what are your thoughts about playtime/amount of content/number of levels for your targetted pricetag?

I don't play a lot iOS/mobile games and am probably hopelesly behind the times. I see a lot of trailers bragging about 50 or 100 levels, which seems a bit excessive. I'm assuming that the levels are pretty short and there's lots of repetition in a lot of of those cases, but even still it's quite a lot. When you're working alone or in a small team it just takes so much time to make lots of levels while still trying too keep the gameplay fresh and varied.

For my last game, Helium Boy which is sold for 2$, I got a lot of flack for just having 8 levels by people who hadn't played it and I probably lost some sales because of it. The levels are fairly long though so I'm not sure it was much of an issue when people actually played it. I've had some customer reviews wishing for more levels, but not in a "this game is a rippoff"-kindof way from what I could tell. Helium Boy is obviously very heavily inspired by BalloonKid, which also have 8 levels of about the same length and even today that game costs more than twice as much on the eShop.

For my new game, I'm making the levels a bit shorter just to be able to state a higher number when asked about it.

Obviously there will always exist games that are longer and better than anything I could make and that still are cheaper, but it would be interesting to get a better idea about people's expectations and how other developers are reasoning about it.
 
Personally I would prefer to make less content but make sure it was finely crafted, bug free and also had replayability built in. If many players are not going to work through all of those levels, then you have wasted content. That even happens on huge budget games.
 
I got a lot of flack for just having 8 levels by people who hadn't played it and I probably lost some sales because of it. The levels are fairly long though so I'm not sure it was much of an issue when people actually played it

I think for iPhone games people play in shorts bursts and expect many short levels than can be completed quickly. So I'd go for lots of shorter levels vs a few longer ones. I'd even go as far as to take a level with checkpoints and split it into multiple levels.
 
To those of you who have or are planning to release games that costs money; what are your thoughts about playtime/amount of content/number of levels for your targetted pricetag?

I don't play a lot iOS/mobile games and am probably hopelesly behind the times. I see a lot of trailers bragging about 50 or 100 levels, which seems a bit excessive. I'm assuming that the levels are pretty short and there's lots of repetition in a lot of of those cases, but even still it's quite a lot. When you're working alone or in a small team it just takes so much time to make lots of levels while still trying too keep the gameplay fresh and varied.

For my last game, Helium Boy which is sold for 2$, I got a lot of flack for just having 8 levels by people who hadn't played it and I probably lost some sales because of it. The levels are fairly long though so I'm not sure it was much of an issue when people actually played it. I've had some customer reviews wishing for more levels, but not in a "this game is a rippoff"-kindof way from what I could tell. Helium Boy is obviously very heavily inspired by BalloonKid, which also have 8 levels of about the same length and even today that game costs more than twice as much on the eShop.

For my new game, I'm making the levels a bit shorter just to be able to state a higher number when asked about it.

Obviously there will always exist games that are longer and better than anything I could make and that still are cheaper, but it would be interesting to get a better idea about people's expectations and how other developers are reasoning about it.

Good fun level are better then weak levels that looks and play most the same, try and add something new or deeper gameplay then the last
 
beril - great work with Helium Boy!

In regards to level time, amount of levels etc. Naturally, people will always be attracted to 100's of levels rather than 10's. It's fickle, but it's a trait that the industry has had for years that extends beyond smartphone games (50 exciting fighters! 40 amazing weapons! Millions of combinations etc.)

Of course, the balance needs to be right though. You don't want 100 levels that leave the player bored. That's where Nintendo are masters. Those guys not only manage to give you hours of gameplay - which normally revolves around the same mechanic - but you're still left wanting more when it ends! Their games have the perfect balance of longevity/quality and it's a skill they have perfected.

And then of course you have gameplay to consider. If your core mechanic is fun then people are happy to play continuously and don't always want variation. FIFA will continue to be the same game for years to come, but it's the gameplay that keeps people coming back - not the new stadiums. And look at a classic game like pinball... 2 buttons, 2 flippers and a ball, but if you have a good table, you can stand there for hours without needing more.

All of this is easy to put on paper though, and a lot harder to execute :) I know that I'm still looking for that 'Holy Grail' moment when it comes to game design. It'll come... one day.
 
http://youtu.be/ehadGdxkzKE

Behold my janky helicopter, it moves smoothly in diagonals but then craps out with simple horizontals. :]
I'm guessing I need to SLERP with my quaternion or something... I really need a good unity / 3D math book! So much fun though. :D
 
http://youtu.be/ehadGdxkzKE

Behold my janky helicopter, it moves smoothly in diagonals but then craps out with simple horizontals. :]
I'm guessing I need to SLERP with my quaternion or something... I really need a good unity / 3D math book! So much fun though. :D
Good to hear you're having fun. Quaternions were a headache for me too on this project, and my background is in maths! If it helps here is a slerp in java (taken from libGDX and simplified by me).

Code:
public void slerp(Quaternion end, double alpha)
	{
		if(this.x == end.x && this.y == end.y && this.z == end.z && this.w == end.w)
		{
		}
		else
		{
			double result = x * end.x + y * end.y + z * end.z + w * end.w;

			if(result < 0.0)
			{
				// Negate the second quaternion and the result of the dot product
				this.x *= -1;
				this.y *= -1;
				this.z *= -1;
				this.w *= -1;
				result = -result;
			}

			// Set the first and second scale for the interpolation
			double scale0 = 1 - alpha;
			double scale1 = alpha;

			// Check if the angle between the 2 quaternions was big enough to
			// warrant such calculations
			if((1 - result) > 0.1)
			{// Get the angle between the 2 quaternions,
				// and then store the sin() of that angle
				final double theta = Math.acos(result);
				final double invSinTheta = 1f / Math.sin(theta);

				// Calculate the scale for q1 and q2, according to the angle and
				// it's sine value
				scale0 = (Math.sin((1 - alpha) * theta) * invSinTheta);
				scale1 = (Math.sin((alpha * theta)) * invSinTheta);
			}

			// Calculate the x, y, z and w values for the quaternion by using a
			// special form of linear interpolation for quaternions.
			this.x = (scale0 * this.x) + (scale1 * end.x);
			this.y = (scale0 * this.y) + (scale1 * end.y);
			this.z = (scale0 * this.z) + (scale1 * end.z);
			this.w = (scale0 * this.w) + (scale1 * end.w);
		}
	}

As for level design, there's definitely been a recent trend back towards procedural level design as opposed to intricately authored stuff, for good and bad.

My pool game will have a mix of specifically authored trick shots and more generic clear the table challenges (although still not actually randomly generated). There will be over 100 but they will be extremely short to play.

I do think it's a shame that people will say 8 3d levels is not enough for a 2 dollar game. It sounds like good value to me!
 
What algorithm are you trying to do? I got on Steam to fix it for you about it but you're not online. =P
If I told you, you would know something about my next game.

And I find that unacceptable. = D

Anyway, I got it mostly working. I could set things up in weird border cases that make it wonky, but I doubt any of those cases will appear in-game.
 
To those of you who have or are planning to release games that costs money; what are your thoughts about playtime/amount of content/number of levels for your targetted pricetag?

I don't play a lot iOS/mobile games and am probably hopelesly behind the times. I see a lot of trailers bragging about 50 or 100 levels, which seems a bit excessive. I'm assuming that the levels are pretty short and there's lots of repetition in a lot of of those cases, but even still it's quite a lot. When you're working alone or in a small team it just takes so much time to make lots of levels while still trying too keep the gameplay fresh and varied.

For my last game, Helium Boy which is sold for 2$, I got a lot of flack for just having 8 levels by people who hadn't played it and I probably lost some sales because of it. The levels are fairly long though so I'm not sure it was much of an issue when people actually played it. I've had some customer reviews wishing for more levels, but not in a "this game is a rippoff"-kindof way from what I could tell. Helium Boy is obviously very heavily inspired by BalloonKid, which also have 8 levels of about the same length and even today that game costs more than twice as much on the eShop.

For my new game, I'm making the levels a bit shorter just to be able to state a higher number when asked about it.

Obviously there will always exist games that are longer and better than anything I could make and that still are cheaper, but it would be interesting to get a better idea about people's expectations and how other developers are reasoning about it.

Instead of pushing your game with "it has 8 levels" what about your turn it around and tell that you have X hours of gameplay?

I mean, its all about how you spin the words. Your games don't have to adjust to others in gameplay, it's you who needs to pitch catchy positive one liners.
 
Personally I would prefer to make less content but make sure it was finely crafted, bug free and also had replayability built in. If many players are not going to work through all of those levels, then you have wasted content. That even happens on huge budget games.

This is a good mentality imo. It's best to start small and make something that truly works. If you pile up a shitload of bad code, your mountain will blow up sooner or later or you will never get a truly polished product.

Oh and by the way, I can help you with learning some GML if you want. If you start on the right feet, you can get up to speed in some mere months.
 
This is a good mentality imo. It's best to start small and make something that truly works. If you pile up a shitload of bad code, your mountain will blow up sooner or later or you will never get a truly polished product.

Oh and by the way, I can help you with learning some GML if you want. If you start on the right feet, you can get up to speed in some mere months.

That would be awesome. I am currently working through the random tutorials around, just so I can get use to the basic framework of stuff. I am trying to make a list of things I need to learn in order to get my prototype running. Still early days yet but hopefully I can keep moving it forward.
 
Instead of pushing your game with "it has 8 levels" what about your turn it around and tell that you have X hours of gameplay?

I mean, its all about how you spin the words. Your games don't have to adjust to others in gameplay, it's you who needs to pitch catchy positive one liners.

Well I wasn't exactly using the number of levels to hype the game, but people asked about it on toucharcade forums and then started whining about it when I answered. The number of hours doesn't sound very impressive either; you can play through the game in less than 20 minutes, except of course for the fact that it's brutally difficult in some places. That sounds really short but is actually not much less than a lot of classic NES/gameboy platform games.

The problem is that I have a hard time judging what people feel is a decent amount of content for their 1-3 dollars. It seems to be fairly agreed upon for 60$ games and for 15$ xbla games, depending on genre and other things as well obviously, but I have no idea what people expect from a 1$ or 2$ game.
 
Well I wasn't exactly using the number of levels to hype the game, but people asked about it on toucharcade forums and then started whining about it when I answered. The number of hours doesn't sound very impressive either; you can play through the game in less than 20 minutes, except of course for the fact that it's brutally difficult in some places. That sounds really short but is actually not much less than a lot of classic NES/gameboy platform games.

The problem is that I have a hard time judging what people feel is a decent amount of content for their 1-3 dollars. It seems to be fairly agreed upon for 60$ games and for 15$ xbla games, depending on genre and other things as well obviously, but I have no idea what people expect from a 1$ or 2$ game.

I know what you mean. But I am not sure it is calculated like this. I mean, some console games are 5 hours and others are 20. I play IOS games that are 2 hours and others that are 20. It's all over the place really. You could totally gather up some gameplay lenght stats by playing similar games to yours on the service though. I suppose it would help your stuff reaching some "expected lenght".


That would be awesome. I am currently working through the random tutorials around, just so I can get use to the basic framework of stuff. I am trying to make a list of things I need to learn in order to get my prototype running. Still early days yet but hopefully I can keep moving it forward.

One of the first things you should do would be to flesh out your design and have a clear documentation of it. I mean, define the basic systems your game need in order to become a reality and with those system well detailed, you will then know your coding needs.
 
If I told you, you would know something about my next game.

And I find that unacceptable. = D

Anyway, I got it mostly working. I could set things up in weird border cases that make it wonky, but I doubt any of those cases will appear in-game.
I look forward to recreating those weird border cases in your game, and then making angry posts going "FEEEEEEEEP!" while shaking my fists at the sky. =D
 
Over the weekend and this coming week, I think I'll finally have time to break ground and get to working on my engine. I'm going to be on vacation - not traveling, just not working - so I'll have ample time and solitude to really put my nose to the grind-stone. So psyched; lots of cool ideas, some great insights thanks to folks in this thread, and a whole heap of ambition! :D

Something I'm really torn about is whether to formally plan out the engine structure before I get coding. How do you folks who have taken on such a task generally approach it? Do you take a program like Visio or Omnigraffle and visually diagram the components, classes, attributes, etc. upfront? Or do you make a basic checklist of what the pieces you need are - general stuff like "sprite", "tile", etc. - and worry about the details as you code?
 
Something I'm really torn about is whether to formally plan out the engine structure before I get coding. How do you folks who have taken on such a task generally approach it? Do you take a program like Visio or Omnigraffle and visually diagram the components, classes, attributes, etc. upfront? Or do you make a basic checklist of what the pieces you need are - general stuff like "sprite", "tile", etc. - and worry about the details as you code?

A. I'm not a coder
B. I am coding though

Trello: A great, simple idea/task management tool that is just a website
yEd: A good, free windows flowchart/mindgraph tool
Balsamiq: The king of interface mockup tools for when you want to be rough

When I need something heavy duty, I'm using some/all of this. But for general function building I just build on the fly. There are points where diagrams really help though.
 
The problem is that I have a hard time judging what people feel is a decent amount of content for their 1-3 dollars. It seems to be fairly agreed upon for 60$ games and for 15$ xbla games, depending on genre and other things as well obviously, but I have no idea what people expect from a 1$ or 2$ game.

Take $30 and buy as many of the top sellers on your platform of choice that you can, then spend a weekend or two playing them all and taking notes.

If you're really looking to sell a product $30 is a pittance for some research. You could probably make that back just on GAF sales once the game is done.
 
Thanks, I would hate to see that non simplified version! :o
Haha, it's not less complicated...just streamlined into one method to make things slightly faster, e.g. theirs used calls to "lengthSquared" and "isZero" methods, I rewrote it all explicitly as it is a performance critical bit of code in my game.

Actually thanks for bringing my attention to this method as I don't like that check which allows for a fudge factor. It may be useful for some applications but the speed benefits for me aren't worth the accuracy loss.
 
Is the guy who did Escape from Puppy Death Factory working on that game? OTS's teleport gun mechanic seems really similar.

No, the basic diference are that you don't need an object to teleport and there are barriers that change you projectile on this one.

Also, from what i know, the development of this game (wich is a "hobby" project since the studio is so indie that people need to work too xD) started before Escape from Puppy Death Factory appeared
 
Does anyone have any recommended reading, preferably in website form, about designing user interfaces? I have never really used the component method rather than inheritance, and I am considering how to handle mouse and keyboard input since I want general engine functionality that works for both user interfaces and ingame controls.

Model-view-controller, design patterns, whatever, I would just like to know if people have suggestions.
 
Does anyone have any recommended reading, preferably in website form, about designing user interfaces? I have never really used the component method rather than inheritance, and I am considering how to handle mouse and keyboard input since I want general engine functionality that works for both user interfaces and ingame controls.

Model-view-controller, design patterns, whatever, I would just like to know if people have suggestions.
I'm also interested in this. I've been basically making it up as I go, and it works fine but when I want to add functionality it means a lot of rewriting.
 
Does anyone have any recommended reading, preferably in website form, about designing user interfaces? I have never really used the component method rather than inheritance, and I am considering how to handle mouse and keyboard input since I want general engine functionality that works for both user interfaces and ingame controls.

Model-view-controller, design patterns, whatever, I would just like to know if people have suggestions.

Hmm, this is a good question, especially in a game development sense. I started doing MVC at work because of working with Rails and Django, and that translation into game development just clicked in my mind.

Any resources I have are related to web application development, unfortunately.

From my recent experiences with developing for iOS, using Xcode and Objective-C, is using an MVC pattern. All of Apple's documentation and tutorials encourage using an MVC structure, so those documents may help.

Edit: Did some Googling and found some good stuff I previously glossed over:

Why are MVC & TDD not employed more in game architecture?

How can you organize code for a game to fit the MVC pattern?

Both questions have some quality answers that are worth reading.

Really good TIGSource forum thread on MVC in game development.
 
Does anyone have any recommended reading, preferably in website form, about designing user interfaces? I have never really used the component method rather than inheritance, and I am considering how to handle mouse and keyboard input since I want general engine functionality that works for both user interfaces and ingame controls.

Model-view-controller, design patterns, whatever, I would just like to know if people have suggestions.
I happen to think user interfaces are incredibly important, and the number one thing indie devs don't seem to give a shit about.

I myself have a controller class. Whenever any input is registered, this controller is called by event and passed in whatever input has changed. The input then gets passed through to all registered UI elements (any of which can be individually enabled/disabled), which have bounding polygons for mouse input and/or specific keys associated. If any of those polygons/keys are hit, those registered UI elements then throw another event, which is taken up by some class or another to actually perform the necessary actions.

Like TFM, I'm just sort of making this up as I go, but it seems to work well enough. In options screens, I can programmatically generate the bounding polygons to easily add or remove a setting, for instance.
 
I happen to think user interfaces are incredibly important, and the number one thing indie devs don't seem to give a shit about.

I myself have a controller class. Whenever any input is registered, this controller is called by event and passed in whatever input has changed. The input then gets passed through to all registered UI elements (any of which can be individually enabled/disabled), which have bounding polygons for mouse input and/or specific keys associated. If any of those polygons/keys are hit, those registered UI elements then throw another event, which is taken up by some class or another to actually perform the necessary actions.

Like TFM, I'm just sort of making this up as I go, but it seems to work well enough. In options screens, I can programmatically generate the bounding polygons to easily add or remove a setting, for instance.
Thanks for the details. It sounds like I should at least read up on MVC before I dive into it.

When you say you pass the input to all the registered UI elements, are you calling an input-specific callback on each element, or are you first checking in your controller whether the element should get the event? Like, the controller would check if the mouse is in the bounding box, and make sure one element is on top of all the other elements before triggering it?

Or, does the code for each element itself handle that checking as part of the callback, and then you generate a second event/callback to do other stuff?
 
Thanks for the details. It sounds like I should at least read up on MVC before I dive into it.

When you say you pass the input to all the registered UI elements, are you calling an input-specific callback on each element, or are you first checking in your controller whether the element should get the event? Like, the controller would check if the mouse is in the bounding box, and make sure one element is on top of all the other elements before triggering it?

Or, does the code for each element itself handle that checking as part of the callback, and then you generate a second event/callback to do other stuff?
The controller has an entity list of all active UI elements. It just loops through that list, checking the key or mouse position/click, and if any match, it generates a separate event to make the appropriate stuff happen. The individual UI elements do not handle the checking process.
 
Cool, that sounds along the lines of what I was thinking. The top-level input handler (which could allow for configurable controls) could do the checking in case say, a popup menu appears above something else that would normally handle mouse input.
 
Well, I also use a stack-based screen manager, and each screen has its own input controller/handler. So if the user hits pause, the pause menu (which is translucent) is added to the stack and appears over the game screen. I consider all pop-up menus to be another "screen", so I just add that to the stack and that appears over everything else. Input is only sent to the top-most screen's input manager, so the pop-up would get priority.
 
Does anyone have any recommended reading, preferably in website form, about designing user interfaces? I have never really used the component method rather than inheritance, and I am considering how to handle mouse and keyboard input since I want general engine functionality that works for both user interfaces and ingame controls.

Model-view-controller, design patterns, whatever, I would just like to know if people have suggestions.

What has often worked well for me with games (I actually do the same basic thought pattern for my daily work programming as well) is to have the concept of substitutions always at the top of my mind. For instance I'm currently working on an indie action / fighting game. To make sure that I keep my boundaries well defined between engine / display / input (pretty much what I map MVC to for games) I have an imaginary version of my game that instead of being controlled with a fightstick in front of an HD display it's instead done with text only display and inputs done by e-mail. As I add the interfaces to connect my controller to my model or my model to my view I have to examine them to make sure that this imaginary version of my game would still work. If not I can usually assume, with a few exceptions for an indie game some cheating is allowed, that I should reexamine the connection that I'm making. This really helps out for testing as well for my fighting engine I can actually test it from a console application, just feed in a set of two text files that list the commands that each player hits on each frame and I can simulate a full match of my game to 100% accuracy without ever displaying anything on screen. Not sure if that will help you, but thinking that way has always done the trick for me.

If you want a basic MVC overview MSDN patterns and practices site is pretty good. There are more modern variants like MVP which basically squishes together the view and controller and tries to reduce the UI layer to the smallest possible size and complexity. Not sure if any of that helps, but figured that I would throw in my two cents.
 
Top Bottom