DROCTOPUS'S PROFILE
Wasting time on 24 bit platforms
Search
Filter
Advice on Making a First Game
Thanks guys,
I knew I was forgetting something, and putting something into the dialogues and storyline was that, even if the game is short. I especially like the idea of one theme to tie it all together. That will give me a good deal of focus.
I knew I was forgetting something, and putting something into the dialogues and storyline was that, even if the game is short. I especially like the idea of one theme to tie it all together. That will give me a good deal of focus.
Advice on Making a First Game
So, hi again,
I was here something like a year ago talking about a game project I was doing for school. Towards the end, I noticed it wouldn't really be feasible to share it since it required some not so typical tools. (Anyone doing work with FPGAs that may be interested, feel free to contact me since I have it and it's well documented, albeit, a little messy).
Well, now I want to make a game that is actually portable; it's more fun. As I was organizing myself, I noticed that I've pickled myself a little bit. Namely, I need some perspective on how to organize a simple game. I've made some small ones like Pong and Break Out before, but, organizing for an RPG is definitely a new ball game for me.
I'm going to keep my goals small for trying a first RPG. I'm thinking of the following, and hoping this is a good starting point:
- Two heroes, otherwise I might as well go Zelda style
- One Town with the heroes' home, One Forge for battle Items, One Vendor for other Items, and an entrance to
- One Dungeon, probably 5 floors
- Three Weapon & Armor types
- Three or so other Items
- Five or Six basic enemies
- One Boss
- One Ending
I plan to keep the stats simple, probably just Life, Attack, Defense, Speed, and Luck. I don't feel like doing any magic/PSI/whatever.
The reason I like this is because I should be able to easily extrapolate from this point into more elaborate games since the basics will be laid and created here.
If this seems like I'm missing something, let me know, or if I'm going too strong, again let me know please. Since I don't plan on being overly creative, more of an exercize here, I'll probably steal your usernames for use in the game. If you'd rather not, don't worry about offending; it's your name after all. Also, I'm looking for resources aside from MS paint to make simple graphics and music, etc, so anything there.
Sorry if this repeats a bunch of older thing, I'm just looking here to make sure my skeleton has all its bones.
I was here something like a year ago talking about a game project I was doing for school. Towards the end, I noticed it wouldn't really be feasible to share it since it required some not so typical tools. (Anyone doing work with FPGAs that may be interested, feel free to contact me since I have it and it's well documented, albeit, a little messy).
Well, now I want to make a game that is actually portable; it's more fun. As I was organizing myself, I noticed that I've pickled myself a little bit. Namely, I need some perspective on how to organize a simple game. I've made some small ones like Pong and Break Out before, but, organizing for an RPG is definitely a new ball game for me.
I'm going to keep my goals small for trying a first RPG. I'm thinking of the following, and hoping this is a good starting point:
- Two heroes, otherwise I might as well go Zelda style
- One Town with the heroes' home, One Forge for battle Items, One Vendor for other Items, and an entrance to
- One Dungeon, probably 5 floors
- Three Weapon & Armor types
- Three or so other Items
- Five or Six basic enemies
- One Boss
- One Ending
I plan to keep the stats simple, probably just Life, Attack, Defense, Speed, and Luck. I don't feel like doing any magic/PSI/whatever.
The reason I like this is because I should be able to easily extrapolate from this point into more elaborate games since the basics will be laid and created here.
If this seems like I'm missing something, let me know, or if I'm going too strong, again let me know please. Since I don't plan on being overly creative, more of an exercize here, I'll probably steal your usernames for use in the game. If you'd rather not, don't worry about offending; it's your name after all. Also, I'm looking for resources aside from MS paint to make simple graphics and music, etc, so anything there.
Sorry if this repeats a bunch of older thing, I'm just looking here to make sure my skeleton has all its bones.
What to do if your Game Submission is denied/pending
author=Marrend
I assume a game that requires external software...
And hardware...
I should probably just hold out till the semester is over, take a big nap, and then develop when I'm not sleep deprived. Normally not a good situation to work under...
That said,I should be able to make a C version that is one download/install for any OS. Make the end users life easy.
Thanks for the help.
What to do if your Game Submission is denied/pending
So I hate to bump this, but I don't know where I should post this question, but here seems appropriate.
I've been in and out around here, posting scarcely due to school time. I'm working on a recreation of the original Space Invaders, designing it from the hardware up. Here's where the question comes in. We need 3 images for a game to be submitted, but they have to be three different locations, not counting the main page. As you may know, that is a bit tricky for Space Invaders since the whole game takes place on a single screen.
So this is where I need help. If I do submit this, how does this images thing work out, since there is so little variety? Also, since this whole thing will be hardware, it will require certain not-so-common tools to actually run; I would expect that few people here actually have access to it (an FPGA) let alone own one. Is it worth my time submitting it? I was planning on redoing the whole thing in C (not going to simulate hardware in C; I'm not that much of a masochist) when the semester is over so that people could download it to actually run on a computer, which I expect you all have. But I thought some folks might like a look at a hardware level implementation of a game. Thoughts? Concerns? Just submit the C version?
I've been in and out around here, posting scarcely due to school time. I'm working on a recreation of the original Space Invaders, designing it from the hardware up. Here's where the question comes in. We need 3 images for a game to be submitted, but they have to be three different locations, not counting the main page. As you may know, that is a bit tricky for Space Invaders since the whole game takes place on a single screen.
So this is where I need help. If I do submit this, how does this images thing work out, since there is so little variety? Also, since this whole thing will be hardware, it will require certain not-so-common tools to actually run; I would expect that few people here actually have access to it (an FPGA) let alone own one. Is it worth my time submitting it? I was planning on redoing the whole thing in C (not going to simulate hardware in C; I'm not that much of a masochist) when the semester is over so that people could download it to actually run on a computer, which I expect you all have. But I thought some folks might like a look at a hardware level implementation of a game. Thoughts? Concerns? Just submit the C version?
Original twist for Space Invaders, Maybe?
Sorry about being MIA for a month.
Updates:
-Will have the processor designed by the end of the week! Thank God
-Can talk about the instruction set. We have maybe 25 instructions I think, nothing fancy so there is no floating point or vector junk.
-working on the first subroutines to place in the ROM
Hoping to update this between Sunday and Next wednesday.
In other news, I think after the semester I will post a version of Space invaders in good old C/C++ so that everyone can get access to it.
And ShortStar, I will still shoot down the reclaimers indiscriminately. We won this planet, we keeping the sucker.
Updates:
-Will have the processor designed by the end of the week! Thank God
-Can talk about the instruction set. We have maybe 25 instructions I think, nothing fancy so there is no floating point or vector junk.
-working on the first subroutines to place in the ROM
Hoping to update this between Sunday and Next wednesday.
In other news, I think after the semester I will post a version of Space invaders in good old C/C++ so that everyone can get access to it.
And ShortStar, I will still shoot down the reclaimers indiscriminately. We won this planet, we keeping the sucker.
Original twist for Space Invaders, Maybe?
Hi everyone,
I'm trying to reacclimate myself here. I'm pretty sure this is the right place to post such a question or idea.
I'm currently taking a digital design class at school, and our group has decided for our semester project to replicate the original Space Invaders, but maybe with a couple twists to be decided. Our goal is to produce a working model of the game to be run on an FPGA (essentially a nifty little thing that lets us model and "program" hardware). We will be leveraging Verilog.
Since this goes beyond what seems to be the norm of RPGMaker or C or Java in that we will be designing the hardware too, I thought some of you might like to follow on this project. It is something I don't see around all that much either. For those who do know programming, this could be a way to look a little deeper into what a computer does running your code; it could help remove some of the aspects of what you might regard as a "black-box." For people who are beginning to learn to program, it might be useful to you to see because it might illuminate why programing languages have what appear to be funky features, maybe something like pointers or the stack. For those who don't touch computers for reasons like that, maybe it will seem like less of a magic box and more of a logic box.
I'm hoping to document many things in this project, including:
Our high-level modules
Designs within each of those modules
Verilog Code for those modules
Our Instruction Set
The assembly on our ROM, including some how-tos on asm (this is where the "code" be)
thinking behind other modules driving graphics and sound, etc
I faintly remember some blogging like feature here for games, and I'll use that too, but my gut says a thread here might be more open. How do I do those things too?
The toughest thing about this is that it will not be easy to get access to play. You would need an FPGA, and even then, the pinnings we would make might not be any good for someone else who picks up the code.
So, you have feed back for this? I thought since it is unique in a way here for games, it might catch some interest. Is this something you'd like to learn about? Is there anything I should elaborate maybe?
I'm trying to reacclimate myself here. I'm pretty sure this is the right place to post such a question or idea.
I'm currently taking a digital design class at school, and our group has decided for our semester project to replicate the original Space Invaders, but maybe with a couple twists to be decided. Our goal is to produce a working model of the game to be run on an FPGA (essentially a nifty little thing that lets us model and "program" hardware). We will be leveraging Verilog.
Since this goes beyond what seems to be the norm of RPGMaker or C or Java in that we will be designing the hardware too, I thought some of you might like to follow on this project. It is something I don't see around all that much either. For those who do know programming, this could be a way to look a little deeper into what a computer does running your code; it could help remove some of the aspects of what you might regard as a "black-box." For people who are beginning to learn to program, it might be useful to you to see because it might illuminate why programing languages have what appear to be funky features, maybe something like pointers or the stack. For those who don't touch computers for reasons like that, maybe it will seem like less of a magic box and more of a logic box.
I'm hoping to document many things in this project, including:
Our high-level modules
Designs within each of those modules
Verilog Code for those modules
Our Instruction Set
The assembly on our ROM, including some how-tos on asm (this is where the "code" be)
thinking behind other modules driving graphics and sound, etc
I faintly remember some blogging like feature here for games, and I'll use that too, but my gut says a thread here might be more open. How do I do those things too?
The toughest thing about this is that it will not be easy to get access to play. You would need an FPGA, and even then, the pinnings we would make might not be any good for someone else who picks up the code.
So, you have feed back for this? I thought since it is unique in a way here for games, it might catch some interest. Is this something you'd like to learn about? Is there anything I should elaborate maybe?
Hi, I'm re-new
Well, there goes my fishing game idea, unless we are fishing for dragons or something.
I'm hoping to have a basic dumb shoot some aliens game up by the end of the week. If I can get the basics rolling then I'll be able to push fancy paths and stuffs in for enemies to follow.
I'm hoping to have a basic dumb shoot some aliens game up by the end of the week. If I can get the basics rolling then I'll be able to push fancy paths and stuffs in for enemies to follow.
Hi, I'm re-new
Hey RMN folks,
I was on here derping aroung a long time ago, went inactive, and decided to give this a shot again. I sort of regret the name I selected 3 years ago, but whatever, I don't care that much.
About me, I'm a Hardware/Software engineering kind and currently in Grad school because I needed to stay out of a life of crime. I work mainly in C/C++ and have a good bit of experience with it, and when I finally get a game up here it will probably be in C leveraging SDL or Allegro (OpenGL still scares me because I'm lazy to it). I've written a few games in the past, the most recent one being a crappy rendition of Duck Hunt to run on Gumstix and it successfully burnt the crap out of that thing's memory. Probably should have spent more than 3 weeks on the project, might touch it up in the future for fun.
Aside from that, I help out at the parish, like going fishing because it is quiet and the food is cheap, unsurprisingly like cooking, build conlangs, and have a funny puppy. I like keeping quiet and will probably avoid things that look like trouble.
If anyone wants to do tool development for gamedev, needs more technical advice or help, or just wants to chat fishing, I'm here (again).
Keep well
I was on here derping aroung a long time ago, went inactive, and decided to give this a shot again. I sort of regret the name I selected 3 years ago, but whatever, I don't care that much.
About me, I'm a Hardware/Software engineering kind and currently in Grad school because I needed to stay out of a life of crime. I work mainly in C/C++ and have a good bit of experience with it, and when I finally get a game up here it will probably be in C leveraging SDL or Allegro (OpenGL still scares me because I'm lazy to it). I've written a few games in the past, the most recent one being a crappy rendition of Duck Hunt to run on Gumstix and it successfully burnt the crap out of that thing's memory. Probably should have spent more than 3 weeks on the project, might touch it up in the future for fun.
Aside from that, I help out at the parish, like going fishing because it is quiet and the food is cheap, unsurprisingly like cooking, build conlangs, and have a funny puppy. I like keeping quiet and will probably avoid things that look like trouble.
If anyone wants to do tool development for gamedev, needs more technical advice or help, or just wants to chat fishing, I'm here (again).
Keep well
Hello!
author=crazyexplorer
You say stuff a lot, man. Where did you get that habit? And where is stuffland? Is there some good stuff in there?
Yeah you know it! Get some, boy.
And just because nobody cares about the place, I can say stuffland is in Nebraska and nobody would bother to check because Nebraska.













