A Game I Had In Mind...


Kordman916

Still Fresh
Joined
Jul 6, 2010
Messages
72
Hi peoples,

Let's get straight down to business here shall we?

I'm pretty sure a great number of people have played the 1940 series of WWII shoot-'em-ups. (The arcade one that is.)
(If you haven't Watch this video but skip ahead to about half to see gameplay. )

Well I had an idea for a game that uses that same style of gameplay but with added features.

Features such as:

Leaderboards

Online cross-platform multiplayer

Custom planes

Etc.

So by now you're probably thinking that I'm just some newbie to the forums with no talent asking other people to make a game for me.
Well if you were thinking that then you're wrong. :)

I'm able to model and program and I've even uploaded some of my models to the 256x256X256 thread.

I'm not even limited to modeling planes I can also model buildings and other scenery. (Excluding terrain.)

But the only things stopping me from attempting this project are:

I'm not good with networking at all. So there would be no way for me to setup the online feature.

My art skills are good enough to texture the models I create but I can't figure out how to unwrap the damn things.

I tend to work better in a team. ( Because with other people I don't tend to get off track.)

Luckily I'm confident enough in myself that I think that I could program a single player story mode in a couple weeks but I would still like to have all of these other features included at some point.

So now comes the question.

Would anyone be willing to help me with this project?

I'd probably only need help with:

Networking

Sound

Menus ( Maybe I have an idea on how to accomplish this.)

Unwrapping & texturing models ( I can do this myself but I need to know the most efficient way to unwrap these planes.)

If you're interested just reply to this message.

Now I'm gonna show you guys two of my most recent planes also seen in the 256X256X256 thread.

he162a2lowpoly.png

Poly count - 572

arsenalvb10lowpoly.png

Poly count - 450

This one is brand new modeled at 4:00 Am
lewisvoughtve8.png

Poly count - 341
 
Last edited by a moderator:
I'm assuming your using Blender? Here, check out this nice tutorial on UV unwrapping. It used to be called LSCM Unwrap, but now it's just normal unwrap.
http://bgdm.katorlegaz.com/lscm_tute/lscm_tute.htm

I'm sure a lot of people would love to see some gameplay demos as well ... maybe in a couple weeks? That might get people more excited about your project.
 
Tyrian, basically. Which is freeware, shoot-em-up, open-graphics, and had modem-based multiplayer (and therefore DOSBox-based Internet TCP/IP multiplayer).

I'm not sure what the leaderboards, etc. would add to such a game, and just about any game can have such "features" added. Personally, I don't class them as features - they are just a tiny little script / ten lines of code that uploads a score to a leaderboard and a server that receives them and stores them. Usually the problem with such systems is that they are easily subverted (because it's impossible to stop people reading the code and then just sending a packet that tells the server that their score was 9,999,999,999), generate an online vulnerability mess and require a hefty, always-on server somewhere to handle the connection.

Custom planes? Just a matter of different graphics files and/or XML datafiles for them. Don't even need to code a single line of program if you program it properly anyway, just replace the images / edit the datafiles.

Online multiplayer is, indeed, a feature. But again, you're looking at always-on matchmaking services or purely a P2P connection and all sorts of networking vulnerabilities, not to mention weeks of tweaking for things like latency-compensation and other problems. To do what? Have two or three people on the screen shooting at the same time. Much more and the screen would be too crowded, I think. Even Tyrian got too busy, and that was on a relatively high-res screen for the time.

Don't get me wrong, the models are good. If you can get anything working, then even a decent modern clone shoot-em-up would be worth it. But I think it's another case of it being easier to think up ideas and slap modes that you want onto existing games than to start a game from scratch with the idea of doing everything all at once.

Basically, I'd leave networking, sound, leaderboards and menus until you have even the basics of a game going. Menus are usually nothing more than an afternoon's work with a graphic artist at most. Sound is just a matter of finding sound triggers (explosions etc.) and passing off a sound chunk to an audio library. Rarely is there much code or many problems with those. Networking is a bigger job and will cause no-end of problems but requires a lot of testing and gameplay - that's hard without a game to play. It's not something you can knock up in an afternoon. And all of those things tend to naturally fold into the game at a later stage anyway, once it's playable and fun to play. Even such simple games can be fabulous fun (Take Altitude as an example - I've wasted hundreds of hours on that on my full Steam version) but also a huge project to code from scratch.

Personally, gameplay-mechanics and graphics are the 99% limiting factor in most game-programming projects. Programming a simple shooter game mechanic is relatively easy, even coding a display engine is relatively easy (not quick, but easy), but without half-way decent graphics to plug in it or a well-thought out mechanic, it rarely gets to the "fun game" stage. The other "features" (networking, etc.) are relatively easy to bolt on afterwards once the game has more than one person who wants to play it.

I'd continue with your graphics. Make mock-ups. Get full-screens of the action including backgrounds, borders, spritesheets etc. at least enough for a demo level.
Get coding - the game mechanic comes from the coding and you either end up with boring and common, or tricky to program correctly with a thousand caveats to take care of. If you can get a fun movement of some mock-up sprites going, you have an infinitely better chance of people jumping on the project. But as it is, everyone wants to write their own game, usually to counter the weaknesses or add features to their old favourites, and just saying "slap on multiplayer" is an AWFUL lot easier said than done. When you have a base game that can be networked, though, then someone who knows about socket programming can come along and start network-ifying it. It'll probably be the LAST "big" feature that you code for the game. At the moment, there's nothing *to* network.

Get to the stage where you have visual mock-ups of the game, and you'll generate a lot more interest. Get to the stage where you're able to move basic sprites about on the screen, realistically and smoothly enough for a 1940-style game, and you'll have a lot more interest. That's the point at which I would personally go "Ooooh, that looks nice, I think I can knock up a function or two to do whatever". Programming teams operate on compartmentalisation - breaking things into bits and then tweaking those bits one at a time to make what you want, like tweaking the sprite routines to do alpha-blending, or tweaking the collision detection to be more accurate, or tweaking the big boss destruction mechanism to make him harder. Without something to compartmentalise, you'll find it hard to attract programmers. It doesn't matter what language. It doesn't matter what file formats. It doesn't matter at the moment because you don't have anything to build from, and outside programmers will want to come into a project, learn it's code and extend it, not start from an empty repository.

My post might sound harsh, but it's supposed to provide encouragement - get something, anything, working and you'll have a lot more interest from people. I have several pet projects in the pipeline at the moment, including the one huge project that I've always wanted to do since I was a kid. I've only ever worked alone on them but I know from previous history, and my own attitude to un-started projects (Un-finished is fine! That's what I want to hack on!), that without at least *something* to build on first, it's hard to recruit people. If you got something working, though, and posted your code and the problems you have with it, I'd probably be looking through your code even if only out of curiosity.

I've spent the last three months coding an isometric game that I've been planning for DECADES. I do it in my lunch-hour and spare time I get at home, so I often choose small tasks and small chunks to do each time. The menus took minutes, when I was frustrated with my path-finding algorithms and wanted something simple and fun to knock up. The sound took literally about 50 lines of C and a library (and can play hundreds of simultaneous OGG/MP3 sound bites with minimal latency direct from disk files, caching them as appropriate). The isometric engine took a day or two.

The rest has been getting graphics (even placeholder graphics) created and working, sorting out engine bugs and time spent on silly things (like creating a windowing system, dragging items from a side-menu and have them alpha-blended over the existing game-space so you can "see" where you'll be putting them into the game, etc.). Three months down the line, I still only have a very crappy protoype isometric game with no actual gameplay mechanics implemented (but lots of scraps of paper!). It looks really cool, to me, because I can imagine what it will be like when it's finished, but to anyone else, it's a couple of days work with SDL and some iso-tiles. I lobbed in an A* library at first, for convenience and to get things working quickly, and then went back and re-wrote the whole path-finding code when I needed something a bit more special. I lobbed in graphics chopped from a ZX Spectrum game at first, then replaced them with some sprites stripped out of Nethack tile-sheets, then replaced them with isometric sprites from an example image that I asked the author's permission for. The sounds I nicked from FreeSound and cover the actions I need them to well enough (I've actually turned off the whole sound system because it works perfectly but gets on my nerves... every 100 revisions or so, I turn it back on to check I haven't broken anything). They weren't "the game", which is the hardest bit to get working how I want. Until "the game" exists, it's just some sprites on a video surface that people could emulate in a matter of hours.

When I start getting it to be a *playable* game, even if that's with every character looking the same, limited interaction, only 1% of the actual *gameplay* finished, etc. then people might want to start helping me.

Keep at it. Knock up a prototype. Give us a glimpse of what it *could* be. Give us something to build from, some code to edit, and we'll be away. But the first steps are the hardest of all.
 
traylorpark said:
I'm assuming your using Blender? Here, check out this nice tutorial on UV unwrapping. It used to be called LSCM Unwrap, but now it's just normal unwrap.
http://bgdm.katorlegaz.com/lscm_tute/lscm_tute.htm

I'm sure a lot of people would love to see some gameplay demos as well ... maybe in a couple weeks? That might get people more excited about your project.

Thank you so much for the unwrapping tutorial. Now I can finally get some textures on these things. :)

If the only way to get more people on this project is to make a demo then be expecting one soon. ;)

Tyrian, basically. Which is freeware, shoot-em-up, open-graphics, and had modem-based multiplayer (and therefore DOSBox-based Internet TCP/IP multiplayer).

I'm not sure what the leaderboards, etc. would add to such a game, and just about any game can have such "features" added. Personally, I don't class them as features - they are just a tiny little script / ten lines of code that uploads a score to a leaderboard and a server that receives them and stores them. Usually the problem with such systems is that they are easily subverted (because it's impossible to stop people reading the code and then just sending a packet that tells the server that their score was 9,999,999,999), generate an online vulnerability mess and require a hefty, always-on server somewhere to handle the connection.

Custom planes? Just a matter of different graphics files and/or XML datafiles for them. Don't even need to code a single line of program if you program it properly anyway, just replace the images / edit the datafiles.

Online multiplayer is, indeed, a feature. But again, you're looking at always-on matchmaking services or purely a P2P connection and all sorts of networking vulnerabilities, not to mention weeks of tweaking for things like latency-compensation and other problems. To do what? Have two or three people on the screen shooting at the same time. Much more and the screen would be too crowded, I think. Even Tyrian got too busy, and that was on a relatively high-res screen for the time.

Don't get me wrong, the models are good. If you can get anything working, then even a decent modern clone shoot-em-up would be worth it. But I think it's another case of it being easier to think up ideas and slap modes that you want onto existing games than to start a game from scratch with the idea of doing everything all at once.

Basically, I'd leave networking, sound, leaderboards and menus until you have even the basics of a game going. Menus are usually nothing more than an afternoon's work with a graphic artist at most. Sound is just a matter of finding sound triggers (explosions etc.) and passing off a sound chunk to an audio library. Rarely is there much code or many problems with those. Networking is a bigger job and will cause no-end of problems but requires a lot of testing and gameplay - that's hard without a game to play. It's not something you can knock up in an afternoon. And all of those things tend to naturally fold into the game at a later stage anyway, once it's playable and fun to play. Even such simple games can be fabulous fun (Take Altitude as an example - I've wasted hundreds of hours on that on my full Steam version) but also a huge project to code from scratch.

Personally, gameplay-mechanics and graphics are the 99% limiting factor in most game-programming projects. Programming a simple shooter game mechanic is relatively easy, even coding a display engine is relatively easy (not quick, but easy), but without half-way decent graphics to plug in it or a well-thought out mechanic, it rarely gets to the "fun game" stage. The other "features" (networking, etc.) are relatively easy to bolt on afterwards once the game has more than one person who wants to play it.

I'd continue with your graphics. Make mock-ups. Get full-screens of the action including backgrounds, borders, spritesheets etc. at least enough for a demo level.
Get coding - the game mechanic comes from the coding and you either end up with boring and common, or tricky to program correctly with a thousand caveats to take care of. If you can get a fun movement of some mock-up sprites going, you have an infinitely better chance of people jumping on the project. But as it is, everyone wants to write their own game, usually to counter the weaknesses or add features to their old favourites, and just saying "slap on multiplayer" is an AWFUL lot easier said than done. When you have a base game that can be networked, though, then someone who knows about socket programming can come along and start network-ifying it. It'll probably be the LAST "big" feature that you code for the game. At the moment, there's nothing *to* network.

Get to the stage where you have visual mock-ups of the game, and you'll generate a lot more interest. Get to the stage where you're able to move basic sprites about on the screen, realistically and smoothly enough for a 1940-style game, and you'll have a lot more interest. That's the point at which I would personally go "Ooooh, that looks nice, I think I can knock up a function or two to do whatever". Programming teams operate on compartmentalisation - breaking things into bits and then tweaking those bits one at a time to make what you want, like tweaking the sprite routines to do alpha-blending, or tweaking the collision detection to be more accurate, or tweaking the big boss destruction mechanism to make him harder. Without something to compartmentalise, you'll find it hard to attract programmers. It doesn't matter what language. It doesn't matter what file formats. It doesn't matter at the moment because you don't have anything to build from, and outside programmers will want to come into a project, learn it's code and extend it, not start from an empty repository.

My post might sound harsh, but it's supposed to provide encouragement - get something, anything, working and you'll have a lot more interest from people. I have several pet projects in the pipeline at the moment, including the one huge project that I've always wanted to do since I was a kid. I've only ever worked alone on them but I know from previous history, and my own attitude to un-started projects (Un-finished is fine! That's what I want to hack on!), that without at least *something* to build on first, it's hard to recruit people. If you got something working, though, and posted your code and the problems you have with it, I'd probably be looking through your code even if only out of curiosity.

I've spent the last three months coding an isometric game that I've been planning for DECADES. I do it in my lunch-hour and spare time I get at home, so I often choose small tasks and small chunks to do each time. The menus took minutes, when I was frustrated with my path-finding algorithms and wanted something simple and fun to knock up. The sound took literally about 50 lines of C and a library (and can play hundreds of simultaneous OGG/MP3 sound bites with minimal latency direct from disk files, caching them as appropriate). The isometric engine took a day or two.

The rest has been getting graphics (even placeholder graphics) created and working, sorting out engine bugs and time spent on silly things (like creating a windowing system, dragging items from a side-menu and have them alpha-blended over the existing game-space so you can "see" where you'll be putting them into the game, etc.). Three months down the line, I still only have a very crappy protoype isometric game with no actual gameplay mechanics implemented (but lots of scraps of paper!). It looks really cool, to me, because I can imagine what it will be like when it's finished, but to anyone else, it's a couple of days work with SDL and some iso-tiles. I lobbed in an A* library at first, for convenience and to get things working quickly, and then went back and re-wrote the whole path-finding code when I needed something a bit more special. I lobbed in graphics chopped from a ZX Spectrum game at first, then replaced them with some sprites stripped out of Nethack tile-sheets, then replaced them with isometric sprites from an example image that I asked the author's permission for. The sounds I nicked from FreeSound and cover the actions I need them to well enough (I've actually turned off the whole sound system because it works perfectly but gets on my nerves... every 100 revisions or so, I turn it back on to check I haven't broken anything). They weren't "the game", which is the hardest bit to get working how I want. Until "the game" exists, it's just some sprites on a video surface that people could emulate in a matter of hours.

When I start getting it to be a *playable* game, even if that's with every character looking the same, limited interaction, only 1% of the actual *gameplay* finished, etc. then people might want to start helping me.

Keep at it. Knock up a prototype. Give us a glimpse of what it *could* be. Give us something to build from, some code to edit, and we'll be away. But the first steps are the hardest of all.

I completely understand what you're saying and now I realize that I should leave out all of the other features that aren't too important right now. I'm planning on having a demo or "Visual mock-ups" in the next 2 weeks so that people can see what I want the game to look like and maybe they'll want to help out.
 
Last edited by a moderator:
Back
Top