WHAT PARTS OF GAME DESIGN MAKES YOU INTERESTED TO KNOW MORE ABOUT OTHER PEOPLE'S PROJECTS?
Posts
Pages:
1
Hello all,
I am making a dungeon-style game that is coming towards the end of the development for the fundamental part of the game. There will still be lots to do graphic/story/audio wise, but for the moment the game is coming along well.
I am very new to game development and this is my first game (just picked up iOS programming this summer)...
I wanted to start a blog for people to follow along with my journey to creating this game. It can be a great bit of information for anyone looking to get into game dev.
What I want to know is what has you interested in game dev that you would like to know more about other people's projects?
It can be anything from what platform the game is being created on, what kind of ideas will be implemented, etc. I will use this blog to share ideas as well as receive feedback from those who are interested. What would you like to know more about?
I am making a dungeon-style game that is coming towards the end of the development for the fundamental part of the game. There will still be lots to do graphic/story/audio wise, but for the moment the game is coming along well.
I am very new to game development and this is my first game (just picked up iOS programming this summer)...
I wanted to start a blog for people to follow along with my journey to creating this game. It can be a great bit of information for anyone looking to get into game dev.
What I want to know is what has you interested in game dev that you would like to know more about other people's projects?
It can be anything from what platform the game is being created on, what kind of ideas will be implemented, etc. I will use this blog to share ideas as well as receive feedback from those who are interested. What would you like to know more about?
Why not create a game page here on RMN? ;)
You can upload screenshots and information about the game and use the blog function.
Your project will benefit from instant visibility once the game page is accepted and the visitors will be able to follow your game and comment on your blogs.
This link can help you get started: http://rpgmaker.net/submission_rules/
You can upload screenshots and information about the game and use the blog function.
Your project will benefit from instant visibility once the game page is accepted and the visitors will be able to follow your game and comment on your blogs.
This link can help you get started: http://rpgmaker.net/submission_rules/
It's the problem-solving aspect that makes game development interesting. With a firm knowledge and philosophy of programming, any game can be made. I recently completed the engine for a 3D maze game in RPG Maker XP. "How can this be done? The developer has a goal. How can he achieve those goals using these tools?"
I'm generally not too interested in following game design blogs unless the game is something that I have a longstanding fandom of. And even then it's kind of iffy. I find that I far prefer the round table discussions/bullshit sessions that we have about various game design topics here on the forums to any ongoing narrative of the design of one particular game.
That's just me, though.
That's just me, though.
Art direction and gameplay, style and substance, respectively. If it looks good and plays good, that's something I'd be interesting in following.
Just show promising screenshots, an interesting array of features and gameplay elements and a good story; you'll have me hooked in no time.
If it is clear that a lot of thought has been put into the project in more ways than just mapping and font choices, I am more likely to subscribe. If it's just somebody trying to piece together a mish-mash of ideas and pretty locations they made, then I'm not going to bother.
It also helps if the blog posts are more casual than clinical, but that is just personal preference. There nothing objectively wrong with being formal in a game design blog post.
It also helps if the blog posts are more casual than clinical, but that is just personal preference. There nothing objectively wrong with being formal in a game design blog post.
I page through most of the stuff that looks interesting on the front page, and mostly I'm interested in just two things:
1. Mapping and sprites.
2. Battles.
Some games have other gameplay mechanics I'd be interested in reading about, but few do outside of battles. But that's just me. Stories are cool too, don't get me wrong, but I don't read up on a game because it hooks me with a story. I mean, if it was that good I wouldn't want to read about anyway because it would ruin the surprise for the game.
1. Mapping and sprites.
2. Battles.
Some games have other gameplay mechanics I'd be interested in reading about, but few do outside of battles. But that's just me. Stories are cool too, don't get me wrong, but I don't read up on a game because it hooks me with a story. I mean, if it was that good I wouldn't want to read about anyway because it would ruin the surprise for the game.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
To keep me reading a blog, I like hearing the nitty-gritty details about design. But to get me reading in the first place, I have to see something big-picture that is seriously impressive. So my advice, I guess, is to post lots of stuff about whatever you're doing, but keep the good stuff stickied somehow.
For me personally I'm talking about gameplay, though of course the same thing would apply to art, writing, or whatever you thing your game's biggest strength is.
Posting a bunch of trivial details also has the nice side-benefit of keeping you accountable as a developer. You are less likely to go a few weeks without doing anything because you know it'll be noticable if you do.
For me personally I'm talking about gameplay, though of course the same thing would apply to art, writing, or whatever you thing your game's biggest strength is.
Posting a bunch of trivial details also has the nice side-benefit of keeping you accountable as a developer. You are less likely to go a few weeks without doing anything because you know it'll be noticable if you do.
Pages:
1


















