Development goals

[spenoza]

I'm sharing this so that hopefully I'll have proper motivation. I think I want to eventually get good enough at HuC that I can make a Rolling Thunder knock-off for PCE. It is a game I've always loved, isn't super demanding on hardware, but has a nice aesthetic and decent animation. So, after finishing the tutorials (I've been busy lately) and creating a few simpler style games, I would like to eventually work my way up to this.

What do you folks thing. Setting my sights a little too high?

[OldRover]

Nah, sounds like a decent maiden project. As soon as I get some more free time, I'll be able to continue on with the tutorial series. I have four more tutorials planned, and by the time they're done, a complete game engine will be up on obeybrew.com.

[_Paul]

Cool. I like Rolling Thunder!

[Arkhan Asylum]

As long as you don't get too fancy with the graphical shenanigans, it would be a pretty solid project. 

[OldRover]

...and don't get lost in the details. That's the #1 biggest project-killer... tacking on more and more stuff. Devise a plan, and stick with it... only add on to it if it becomes absolutely necessary. Don't be afraid to cut stuff from your design either... don't get married to your concepts... that's probably the most common rookie mistake.

[spenoza]

I AM a perfectionist at time. I can get really absorbed in reworking and reworking things.

But I'm SO not there, yet.

[OldRover]

That's a habit you will want to break... not now, but yesterday. In game design, there is no such thing as perfection, and the pursuit of the non-existent perfection will lead to vaporware... which is a great way to ruin your reputation before you've even started.

[_Paul]

...and NEVER make a role-playing game!

[OldRover]

...unless you REALLY know what you're doing...

[BigusSchmuck]

...unless you REALLY know what you're doing...

Or if its just text driven with still pictures like Wizardry Made a few of those in qbasic back in the day.

[spenoza]

I dunno, PCE memory limits could be a real bitch, even with a text RPG.

[Arkhan Asylum]

A text-RPG would be easy peasy. 

A JRPG has too many things to worry about.   

[spenoza]

What about a gold-box style RPG, eh? How hard would that be? I think the sprite and tile work would be pretty easy for battles, but I'm not sure about corridors.

[Arkhan Asylum]

it would be two punches in the dick.

those maps in battle are exact replicas of the first person view maps.

getting the visuals for the first person alone is enough of a PITA. 

this is compounded by all the other shit you have to deal with.

I strongly advise against that kind of project as a first.

[spenoza]

No, I would not be biting off that particular project for a long time, if ever. I'd rather stick to other stuff.

[Arkhan Asylum]

Yeah the Goldbox games are best done with a team.  That way programmers can take on different pieces.  Like, one for the exploring and one for the battles...

[soop]

If I made a game, I'm fairly certain I'd start with a shootemup - in fact I did make one in pascal once (with parallax scrolling!).  A run and gun would be different in that I just had to make attack patterns rather than design levels.  But I would, in order:

Start with the basic collision detection and movement
Attack patterns and scoring
Graphics
Music
Titles/gloss

[Arkhan Asylum]

depending on the complexity of the Shmup, they are often fairly easy to do. 

It gets hairy when you introduce fucking wack ass graphical trickery, and sprites as big as RoyVegas' mom.

[soop]

depending on the complexity of the Shmup, they are often fairly easy to do. 

It gets hairy when you introduce fucking wack ass graphical trickery, and sprites as big as RoyVegas' mom.

Hahah!  I had a good idea for a slightly more complex shooter - probably for xbox in an 8-bit style - where it features different weapons assigned to the different face buttons (a bit like the Soldier series weapons, but on tap) and a paper scissors stone mechanic where each enemy is particularly vulnerable to one colour and particularly resistant to another.

well one of the bosses features four smaller craft which have to be hit in a certain order to deactivate them - if you hit them out of turn, they reset and no damage is done until you get all four in the correct order, which would require precision and ideally, switching between weapons to speed it up.  A few rounds of that, getting faster and faster until they're done.

I figure that would be a nice mechanic, and still fucking easy to code.  I am, however, very lazy.

[Arkhan Asylum]

oh, for the xbox, this shits a cakewalk.

I was talking about for PCE.


On the sexbox, you have basically infinite resources for a 2D shewtar

[soop]

oh, for the xbox, this shits a cakewalk.

I was talking about for PCE.


On the sexbox, you have basically infinite resources for a 2D shewtar

Yeah, I was thinking of the PCE too, but the controller wouldn't fit as well.

[Arkhan Asylum]

listen, support 6 button.

in fact, force it!

[OldRover]

...for xbox in an 8-bit style...

As long as you don't plan to sell it, you're all good. No one would buy it, but a few people might download it for free. The Xbox crowd is... odd.

[OldRover]

A basic shooter is a weekend project on the PCE... use stock sprites and tiles, basic movement and collision detection, etc... easy peasy stuff. When you get into complex enemy patterns, AI, and all the fancy effects, development time increases exponentially.

[Arkhan Asylum]

...for xbox in an 8-bit style...

As long as you don't plan to sell it, you're all good. No one would buy it, but a few people might download it for free. The Xbox crowd is... odd.

its not the xbox crowd thats odd.

its the fact that they shove the indie shit in the ass-end of the menus, nowhere near anything, and its such a chore to find games that people aren't likely to give anything a shot... especially since the indie menu is flooded with awful games that pass the criteria, but aren't worth a damn.

UNLESS, it's one that Kotaku mentions.

If Kotaku mentions it, you are all set.  There is a kotaku button in the menus, so people just blindly go there.

[spenoza]

See, this is why I'm a little worried about working my way up to a platformer. In a shooter, movement is pretty free-form. In a platformer you have different platforms, jump physics, etc... HARD (in my brain).

[Arkhan Asylum]

but in a platformer, thats ALL you have to worry about.

The rest is just making levels that work with the physics.

Mario 1 is fucking balls simple as far as "stuff going on that you have to program"

the rest is just putting it in the right places so the levels are just the right amount of annoying.

Shooters have movement, collision, enemy patterns, bullet patterns, gang signs, parallax, bosses, and shit.

[spenoza]

Shooters have movement, collision, enemy patterns, bullet patterns, gang signs, parallax, bosses, and shit.

If I ever make a shooter, I promise it will not have gang signs or shit. Especially not shit. I am no fan of Toilet Kids.

[OldRover]

My tutorial series started out with a block platformer because it's generally the easiest type of action game to make. Master the block platformer and you can move on to bigger and better things... the block platformer model will get you accustomed to sprite movement technique and collision, plus enemy movement theory if you so desire. You can then take that experience into more complex game types, such as "pure" platformers (moving platforms and slopes), shooters (prepare to optimize the snot outta your code, and basic AI helps unless you wanna just do movement tables), or perhaps brawlers (Y-sorting, complex hitboxes, strong AI). Fighting games come off as simple at first, but are AI-heavy and you need a strong understanding of finite state machines to pull them off. They're way more advanced than they look. And RPGs... forget it... you pretty much have to be an expert at all of this before you attempt an RPG. Sure, you can scrape by with basic understanding of solid-block collision, and when planned carefully, you can avoid getting into Y-sorting... plus you can skip AI altogether if you want your enemies to be a band of blundering dumbasses who, one would wonder, ever got around to doing whatever foul deeds your story says they did. To make a masterpiece though, you'll need all the skills for that, plus some that are unique to RPGs, such as the ability to handle vast amounts of text (you'll have to use far storage, which requires some advanced techniques). You might even want to utilize subtile collision, which means you'll have to understand and effectively use subtile collision maps... which also means you'll need to understand granularity and lookup tables (this is helpful for pure platformers, though most times, you can just get away with a slope table as opposed to a subtile collision map). RPGs are a nightmare to do properly on the PCE.

A platformer is an awesome first project and is one of the most satisfying types of games to both make and play.

[Nando]

Some resources to hopefully help you out. 

http://bbrathwaite.wordpress.com/2008/11/30/creating-a-game-design-document/

http://www.significant-bits.com/what-made-those-old-2d-platformers-so-great

http://www.sokath.com/papers/smith-sandbox08.pdf

http://www.gamasutra.com/blogs/LarsDoucet/20100304/4562/Practical_Game_Design__The_Rule_of_Threes.php

http://supermeatboy.com/tag/game%20design/

http://petermcclory.com/2012/01/hand-drawn-2d-platform-game-level-design-process-tutorial/



Have a clear and defined goal.  Good luck!

[TailChao]

A platformer is an awesome first project and is one of the most satisfying types of games to both make and play.

It is an absolutely wonderful genre for learning and playing, absolutely. Plus, in addition to your tutorial there is the old MC-Kids guide which gives an overview of several good concepts: http://games.greggman.com/game/programming_m_c__kids/

[Arkhan Asylum]

http://bbrathwaite.wordpress.com/2008/11/30/creating-a-game-design-document/

Id just like to point out, that the lady who wrote this is responsible for alot of the design work in Wizardry.