This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Managing complexity by delegating minigames

Managing complexity by delegating minigames
by on (#177103)
Six and a half years ago, when I released Concentration Room, we had a discussion about the limited complexity of 1- and 2-person homebrew games back then compared to later commercial NES games that had a full team behind them. Since then, I've been involved in such a team for Haunted: Halloween '85. But nowadays, games outgrow even a whole studio.

Via Slashdot I found an article on The Guardian about the rise in game complexity since the 8-bit era.

Today, creating the most advanced, triple-A games has become too big a task for a single developer leading to the rise of what is best described as a modular approach, where different developers work on different parts of a single game.


Video game publisher Ubisoft acquired Reflections, a studio known for driving games, and put it to work making driving sections of larger games. This financially shielded it somewhat from the success or failure of a particular game.

Is there a way for this sort of collaboration to work in the NES scene, apart from the obvious multicart approach? I can think of a couple NES games with gameplay that diverse. The first is Vice: Project Doom (aka Gun-Dec) had platforming, Spy Hunter-style driving, and Operation Wolf-style shooting. There's also Battletoads, which appears to use a largely separate engine per level. Or are there too few NES developers to make it practical to farm minigames out to other developers?
Re: Managing complexity by delegating minigames
by on (#177108)
Everything is possible with money ;) Trying to do anything bigger with entirely volunteers will crash and burn 99.98% of the time, as history has shown.

I'm not sure the lack of developers is a serious issue, though obviously I'm biased. A year ago I had never developed for the NES, and it didn't take long for me to get up to speed. A couple weeks to get familiar with the system quirks, a week practicing, then I needed to write some tools that took a couple days. Before this, I had a background of a Linux dev with various embedded platforms and random thingies.
Re: Managing complexity by delegating minigames
by on (#177112)
After my current projects are completed, I will be looking to work with a team on some kind of large project. NES or SNES.
I've had a few people contact me with offers to contribute music or graphics. I think a group project would be a good idea, and could greatly speed up production of what would otherwise be a year long project.
Re: Managing complexity by delegating minigames
by on (#177114)
Perhaps you could hire a bunch of Indian guys for very cheap. In that country there is a lot of coding geniuses and their country is very cheap.
Re: Managing complexity by delegating minigames
by on (#177116)
I've always wanted to know to main reason as to why there are so few homebrew games, or at least any beyond the complexity of an early 80's game. The worst has probably already past for me in regards to making a game engine and I already know I'm one of the least qualified people here (or at least I was). Because of this, I don't believe that coding is the issue, but creating content is like artwork and sound composition. I know game design would get me to, because it's hard to do anything that hasn't been done before, (I actually have a unique idea, but it wouldn't work on a 2D system) and if your game is story dependent driven, then you need to come up with that too.

What I plan to do is release my game engine and try to get people to use it so anyone who is interested in anything I'm doing could help me (or vice versa, but I imagine they'd want to use their own game engine for that then.) I think I'm a good artist so I could create good artwork, but I'm slow as molasses. I really wonder how many people have used 3D models and had them pre rendered for their games, (like DKC) but then went over them later to make them look more like traditional pixel art. You might have to kind of start over from scratch, but at least everything will be proportional across animation frames and will give you a sense of where everything is supposed to go, like arms and legs. Of course, creating 3D models for a game takes time also, but for things that have a ton of animation frames, I'd say it's worth it, especially if they're really big like in a fighting game.

Bregalad wrote:
their country is very cheap.

Can I buy their country? :lol:

One last thing though, I've heard many people say that collaborative projects mostly fail, but frankly, I haven't even seen anyone here try to do a collaborative project unless they're all PM each other. Why make it private anyway? It seems like you could have a thread about your game (which many people do) and just say what needs to be worked on and anyone can offer help, just put their name in the credits or something. I don't think any of us are doing this with intent to make money, so why not? If you don't like what someone is trying to do, just don't use it.
Re: Managing complexity by delegating minigames
by on (#177119)
Bregalad wrote:
Perhaps you could hire a bunch of Indian guys for very cheap. In that country there is a lot of coding geniuses and their country is very cheap.

There are risks that come with that cheapness, too.

I worked for a company that thought they could hire programmers remotely like that. They wrote a bunch of boilerplate kinda code when he started, and as soon as they perceived the code wasn't being reviewed they switched to doing nothing, just making tiny edits to comments etc. and checking them in once a day to make it look like they ware working. In regular phone calls they'd say they were working on this or that, were just trusted, I guess. It "sounded" like they were saying the right things, at least for a while. It was a few months of this before someone noticed they hadn't done any real work, but we'd already paid quite a bit by that point, and they basically just disappeared and were untouchable by us. Also for the project managers, suddenly realizing that a man-year or so of work you expected just doesn't exist, that was a huge setback. (This project eventually ended up failing, by the way. This was part of it.)

Not saying that fraud is normal for India's remote programming labour industry, I'm sure there's plenty of honest work being done, but there's a volatility in remote work that you have to manage, and finding workers you can trust is one of those factors. There's more time spent making sure they do the right thing, more time spent communicating ideas that a local team would understand quickly, more chances to make mistakes along the way, etc. Sometimes you end up paying the difference anyway just in lost efficiency.

Other times you might get lucky.
Re: Managing complexity by delegating minigames
by on (#177128)
The whole class of "track-and-field" games have multiple game modes that could be done mostly-independently.
Quote:
The first is Vice: Project Doom (aka Gun-Dec) had platforming, Spy Hunter-style driving, and Operation Wolf-style shooting.
Only can think of one with four modes:
Golgo 13: Top Secret Episode: flying shooter, sniping segment, 3d mazes, beat-em-up explorer

Three has a few, you mentioned, plus:
Bayou Billy (aka Mad City) likewise: beat-em-up, shooting gallery, Rad Racer-style driving.

Two, you get a significant chunk of games.

Air Fortress: side-scrolling shooter+ on the station
Blaster Master: platform shooter + overhead shooter
Captain Skyhawk: Isometric shooter + 3d shooter (+ dock with the space station as sub-mode)
(Famicom)Challenger kinda has two modes, sidescroller and overhead?
Contra: Run'n'gun + perspective shooting gallery (not sure what to call it. Wild Guns is mainly in this mode though.)
Darkman: Platforming beat-em-up + picture-taking shooting gallery
Dr. Chaos: Shadowgate-ish adventure + platformer
Fester's Quest: Overhead shooter run'n'gun + 3d mazes (which SNES? Jurassic Park later would also do)
The Guardian Legend: vertical shooters and Zelda-ish overhead.
(Famicom) Layla: run'n'gun + side-scrolling shooter
Nightshade: Point'n'click adventure + 2d fighter
Return of the Joker: beat-'em-up + side-scrolling shooter
Rygar: Overhead, sidescrolling.
Snake's Revenge: Overhead, sidescrolling.
Star Wars: driving mode + side-scrolling platformer
T&C II: Thrilla's Surfari: isometric 3d-stunt skating + sidescroller sharkriding
Ultima series: overhead RPG, 3d-maze segments (see also: Phantasy Star)

Weak 2-modes:
Silver Surfer, Lifeforce/Salamander: Vertical shooter, side-scrolling shooter.
StarTropics (I/II): Overhead RPG, Zelda dungeons.
Xexyz: side-scrolling shooter + platform explorer
Zelda II: Overhead RPG, side-scrolling combat scenes
The Koei strategy games (e.g. L'Empereur have the strategy level, and the tactical battle-level, which are different engines.

These are just the ones I know about.
Re: Managing complexity by delegating minigames
by on (#177133)
Most RPGs have at least 2 modes, overhead walking, and in battle mode.
Many also have mini-games.

One of my favorite parts of FF7 was the snowboarding game.
Ff8- card game.
Re: Managing complexity by delegating minigames
by on (#177134)
but FF7 isn't for NES (well, okay, there is that one FF3?derived HKO).
Oh, right.
Magic of Scheherezade: Zelda-style adventure + RPG battles. (Combat exists in Zelda-like mode, making it more a 2-type than a typical RPG)
Re: Managing complexity by delegating minigames
by on (#177147)
Many adventure games mix in a platform engine or other things.
Also there are many games like Akumajou Special: Boku Dracula-kun that has lots of different mini-games between levels.

Goonies II: platform segments + point and click adventure
Portopia: adventure + one RPG-style 3D-maze segment
Erika to Satoru no Yume Bouken: adventure + overhead walkabout mode
Turtles: platform action + overhead action + swimming level
Platoon: side-scrolling mode + first-person mode in mazes
Rescue - The Embassy Mission: side scrolling sneaking mode + sniping mode + rope climbing mode + first-person action mode
Galaxy Odyssey (FDS): scrolling shooter + overhead action
Kieta Princess (FDS): platform mode + overhead mode
Kid Icarus (NES version): scrolling platform action + platform dungeon exploration + scrolling shooter (in the Japanese version the final level is less like a shooter though and doesn't auto-scroll)
North and South: turn-based troop movement on map + real-time action battles + platform mode when capturing trains and fortresses
Super Mario Bros 3: stage select map, platform (auto-scrolling and non-auto-scrolling both in multiple directions), Mario Bros platform mini-game, lots of bonus mini-games.
Re: Managing complexity by delegating minigames
by on (#177165)
Every time I see this thread title I read for a moment:

"Managing complexity by deleting minigames"

...and it makes a lot of sense to me. Every game I've worked on has had lots of extra stuff in the original design plan; there are always pieces of that design that are supposed to be removable as the remaining resources inevitably shrink faster than expected. Theatre often works this way too, where whole scenes of dialogue might be cut to conserve time, sets, etc.

NES games are no exception, SMB3 has evidence of some cut minigames: https://www.youtube.com/watch?v=Ts-BYFKB7uc
Re: Managing complexity by delegating minigames
by on (#177237)
tepples wrote:
Today, creating the most advanced, triple-A games has become too big a task for a single developer leading to the rise of what is best described as a modular approach, where different developers work on different parts of a single game.

Unfortunately, the new Doom game suffered from this method. The single player campaign was great, while the multiplayer was very... lacking. The in-engine content was balanced for single player, and seemingly left alone for the multiplayer end of things, resulting in a severe gameplay imbalance.
Re: Managing complexity by delegating minigames
by on (#177261)
A counter-opinion though: I don't think it's actually complexity (ie different game modes or mini games) that makes most homebrew feel sub-par. I think it's lack of content and polish. More programmers doing different game modes won't necessarily fix that. It's taking the time to design more and better levels, a good difficulty curve, polished graphics and controls, etc, that will make a bigger difference in perceived homebrew quality.

A lot of old games with varied modes just stunk, really.
Re: Managing complexity by delegating minigames
by on (#177289)
gauauu wrote:
It's taking the time to design more and better levels, a good difficulty curve, polished graphics and controls, etc, that will make a bigger difference in perceived homebrew quality.

That's how I feel about the whole thing. Out of making a game, I feel coding is the least of anyone here's problem. If NES development is anything like SNES development here, than people have even gone above and beyond what has been done in just about any commercial game (or at least we're working on it. Psychopathicteen seems to be done though for the most part, just some improvements). In terms of graphics, sound, and content though, no. I really think people need to collaborate on just one main game and bounce ideas of each other and improve what the other has done. It seems 90% of homebrew here is just about done in secret, and more than likely, it seems to fail too.
Re: Managing complexity by delegating minigames
by on (#177290)
Espozo wrote:
I really think people need to collaborate on just one main game and bounce ideas of each other and improve what the other has done. It seems 90% of homebrew here is just about done in secret, and more than likely, it seems to fail too.

How much of the secrecy has to do with feeling that you won't be able to sell something on cartridge if the ROM image has already been distributed to the public without charge?
Re: Managing complexity by delegating minigames
by on (#177291)
People are trying to make money off this?
Re: Managing complexity by delegating minigames
by on (#177292)
Commercial homebrew has been around since at least the first Battle Kid (2010).
Re: Managing complexity by delegating minigames
by on (#177296)
Espozo wrote:
People are trying to make money off this?

Most people here are no longer 17 year olds living with their parents with a lot of spare time on their hands. A lot of us have homes and kids to support, and as much as we'd like to release stuff for free, we often can't justify taking time away from real life jobs to develop retro games unless said games can bring any sort of revenue to help break costs even.

There actually is a market for this, and while success isn't guaranteed, I think it's great that everyone is free to try to grab a slice of that market.
Re: Managing complexity by delegating minigames
by on (#177297)
tokumaru wrote:
Espozo wrote:
People are trying to make money off this?

Most people here are no longer 17 year olds living with their parents with a lot of spare time on their hands. A lot of us have homes and kids to support, and as much as we'd like to release stuff for free, we often can't justify taking time away from real life jobs to develop retro games unless said games can bring any sort of revenue to help break costs even.

There actually is a market for this, and while success isn't guaranteed, I think it's great that everyone is free to try to grab a slice of that market.


Can't emphasize this enough. A little extra cash to help with bills, payments and general living expenses is VERY helpful. And having a full-time job and a social life really makes a person realize just how valuable and limited their time is. This isn't to say that making homebrew isn't fun or anything like that, just that being rewarded for effort monetarily is helpful. I also second that it is great that everyone can compete and make profit in this, essentially, hombrew free market.
Re: Managing complexity by delegating minigames
by on (#177301)
tokumaru wrote:
Most people here are no longer 17 year olds living with their parents with a lot of spare time on their hands. A lot of us have homes and kids to support, and as much as we'd like to release stuff for free, we often can't justify taking time away from real life jobs to develop retro games unless said games can bring any sort of revenue to help break costs even.


I haven't really done much nes dev yet (maybe it pays out better) but from what I've done on other platforms: the money you make from homebrew is small enough that it's not worth chasing for me. I'd rather invest my hobby development time in whatever is most enjoyable for me instead of worrying about making a few bucks per hour. Maybe I'm just fortunate that my day job pays enough, though, that I can afford to not worry about it. But if the issue was money, I'd just take on some freelance work that pays real money.

So, for example, my last game (an Atari 2600 game) I'm releasing the source code for, because I want to. Will that cut down on what I make on cartridge sales? I dunno, probably a little. But it's not worth the difference to me in money. Of course, that's also why I tend to take 3 years to release a game :-/

(I'm not disagreeing with you, I don't mind if the money is a motivation for others. I'm just saying it's not always the case, even for other middle-age adults with a family to support)
Re: Managing complexity by delegating minigames
by on (#177302)
Espozo wrote:
Out of making a game, I feel coding is the least of anyone here's problem. If NES development is anything like SNES development here, than people have even gone above and beyond what has been done in just about any commercial game (or at least we're working on it. Psychopathicteen seems to be done though for the most part, just some improvements). In terms of graphics, sound, and content though, no. I really think people need to collaborate on just one main game and bounce ideas of each other and improve what the other has done.


The other issue is finding the different talents to build the right kind of team. I don't necessarily need more programmers to help me, I need artists and musicians. Where do they hang out? The other homebrew development forums I've hung out on tend to be programmer-heavy (I'm new here, maybe it's different here?)
Re: Managing complexity by delegating minigames
by on (#177304)
Music:
http://chipmusic.org/
http://forums.famitracker.com/
Pixel art:
http://pixelation.org/
http://pixeljoint.com/forum/
Re: Managing complexity by delegating minigames
by on (#177306)
Espozo wrote:
People are trying to make money off this?

Quote:
Commercial homebrew has been around since at least the first Battle Kid (2010).

I'll also add that this enormously pissed me off back then, for various reasons, but I really think it denatured what our community was about. For example I was almost hesitant to come up with my $4011 sine idea in the other thread, because I am afraid some jerk will make money off this (and pass him off as the inventor of the idea), but heh I would not have put this in use in any of my projects so I might as well not waste the idea and share it. My post also proves who had the idea, so it's no major issue.

Quote:
Most people here are no longer 17 year olds living with their parents with a lot of spare time on their hands. A lot of us have homes and kids to support, and as much as we'd like to release stuff for free, we often can't justify taking time away from real life jobs to develop retro games unless said games can bring any sort of revenue to help break costs even.

This is a rather poor excuse. If your goal is to feed your family, then you're not going to do that with NES homebrew period, even by swindling people and sell cartridges and goodies for awfully high prices. There is an infinite number of way you're going to gain infinitely more money for the same amount of worked hours (even if the jobs might not be as fun I agree).

My idea was that we're here for a hobby, and as such, we should not expect to be paid. If your hobby is hiking, cycling or playing music (heh I just cited my own other hobbies, but I could have cited anything) then you're not expected to get paid - you have a job for that, and you spend aprox. 40 hours for it already. 40 hours are dedicated for sleep, and the remaining 40 hours for free time. How much of that time to allocate family or nesdev is your own choice (kind of), and you shouldn't expect to be paid just because your time allocated to nesdev is decreasing - it's no excuse.
Re: Managing complexity by delegating minigames
by on (#177307)
To answer the original question (I make it a separate post to make a potential thread split easier), I think purely online collaborations fail because people doesn't really know each other personally, and it fails to create a real group of people motivated with the same goal.
Re: Managing complexity by delegating minigames
by on (#177309)
Bregalad has convinced me to give up NES development and go get a job in real estate. Lizard is cancelled. See you guys never.
Re: Managing complexity by delegating minigames
by on (#177311)
rainwarrior wrote:
Bregalad has convinced me to give up NES development and go get a job in real estate. Lizard is cancelled. See you guys never.

Why do you have to take my comment so negatively? (Even if this was supposed to be a joke).
Re: Managing complexity by delegating minigames
by on (#177312)
rainwarrior wrote:
Bregalad has convinced me to give up NES development and go get a job in real estate. Lizard is cancelled. See you guys never.

My lizard is the lizard of subordinate financing.
Re: Managing complexity by delegating minigames
by on (#177313)
Because what you said was extremely negative?

1. You said I should not expect to be paid for my work.

2. You called me a "swindler" for selling cartridges.

3. You said that what I am doing "denatures" our community (whatever that means).

4. I don't even know what you were suggesting about the "$4011 sine" idea. Which part of the idea do you want credit for, and how much money is it worth? What "jerk" is going to make money off it? Am I that jerk because I got interested in a similar idea because of your post and actually implemented it?

I'm not sure how you expected me not to read this negatively? It directly reflects on something which is very important to me.
Re: Managing complexity by delegating minigames
by on (#177314)
rainwarrior wrote:
1. You said I should not expect to be paid for my work.

I never said that. (*)

Quote:
2. You called me a "swindler" for selling cartridges.

I hadn't the slightest idea you were selling carts but I don't care since I'm not interest in buying them. I said "even by swindling" - that doesn't mention anyone's name.

Quote:
3. You said that what I am doing "denatures" our community (whatever that means).

Again, not targetted at you specifically, and I hold that statement. I have no idea whether you already were part of us before 2010, by the way (not that I care).

Quote:
4. I don't even know what you were suggesting about the "$4011 sine" idea. Which part of the idea do you want credit for, and how much money is it worth?

It's worth $0, it's free as in "free software", just like anything I say here. I am not like those people who are here to make profit.

Quote:
What "jerk" is going to make money off it?

The same kind of people as those who sells romhacks for $100+.

Quote:
Am I that jerk because I got interested in a similar idea because of your post and actually implemented it?

No.

Quote:
I'm not sure how you expected me not to read this negatively? It directly reflects on something which is very important to me.

Yet once more again, not targetted at your or anyone specifically, just stating my opinion.

(*) After reading the following, what you said made more sense. I do not consider Nedev to be "work", but this is going to turn into a war of definition.
Re: Managing complexity by delegating minigames
by on (#177322)
Well okay, Bregalad, you clarified that you weren't targetting me specifically, but from my view I can't really understand how what you're saying would apply to what Sivak / RetroUSB are doing but not to me?

If want to talk about yourself, that's fine. I don't mind if you don't want to buy cartridges. I don't mind if you don't want to be paid for work you do on your NESDev hobby projects. When you direct these statements outwardly at others, though, I find it very offensive.

The meaning of my sarcastic response was a direct rejection of this opinion. It was obliquely directed at Espozo's comment as well. It partly just meant: "I'm the one taking all the risk here, your opinions are irrelevant garbage."


I reject the idea that NES development work is exempt from monetary value. NES development isn't a special category of labour, neither is labour done on the weekends, or in the evenings, or at home, or on a boat. Unless you're violating a contract or copyright of some sort, you own your work, and you have the right to ask whatever you think it's worth for it.

It may not be worth what you ask, but that's your own problem to solve. It's not a "swindle" unless you're actually dishonest about what you're selling. (I don't like being called a liar.)


I can see that part of what I was reacting negatively was actually responding to tokumaru, and his appeal to the support of "homes and kids", etc. and really I agree with what I think you intended there. Selling a video game has nothing to do with being an adult with kids to feed. It's about having a game that people want to pay for. The kids are irrelevant to everyone but you. That's an appeal to charity, not a justification that someone should buy your game. Making a viable game takes risk; if you can't afford to do it because your kids are hungry, then you just shouldn't be doing it.


And finally, as always, this forum is quite possibly one of the worst places to have a discussion about whether a project has commercial viability. Partly because almost nobody here has ever run a commercial project. Partly because of people like Bregalad who would never buy an NES homebrew game anyway, and seem to resent others trying to earn money using the public wealth of knowledge that this community produced. Partly because of angry argumentative people like me. Every thread about this here turns into a trash fire.

I dunno, if you wanna argue about whether some hypothetical project that will never happen would be commercially viable, whatever. I got sucked in because I felt Bregalad's comments applied to me, in a way he didn't intend. Sorry for maybe flying off the handle, I should have just held my tongue.
Re: Managing complexity by delegating minigames
by on (#177323)
The rise in the willingness for people to buy new NES games in 2016 I think has led to a rise in the quality of NES homebrew work. In the past, many neat demos were made, and small miniature games, but there were not a ton of games that would have me sitting down playing it for a few hours. I had a good time playing Thwaite and actually went back to it for more later. Zooming Secretary and Alter Ego can absolutely pass as professional early NES titles, and I've played them a bunch as well. I've even gotten some good play out of just the demo roms for Super Bat Puncher, Battle Kid, and Lizard. I haven't played Haunted Halloween '85 yet, but I'm happy to see a full-length game completed, covering all the bases of what's expected from a proper commercial title.

This is not to bash on earlier works, but the things made in the last five years I think have had made leaps of progress over the smaller fragmented works from before. By being able to sell homebrew, its time is better justified - as we've touched upon in this thread - and for a working adult that's a very important motivator for what may otherwise look like a giant time-sink.
Re: Managing complexity by delegating minigames
by on (#177325)
I also really liked The Mad Wizard. I don't hear people talk about it much, but I thought it was a really solid little puzzle adventure.
Re: Managing complexity by delegating minigames
by on (#177338)
Bregalad and rainwarrior completely missed the point of what I said. I didn't say that making retro games is a great way to support kids, nor that players should buy games to help developers support their families. Money wise, you're lucky if you're able to break even, I'm aware of that. And gamers should definitely only buy products they think are worth the price being asked, regardless of how the game came to be.

But if you're an adult with nearly no free time, because of the responsibilities of adult life, and you still want to make a great NES game, you may need to cut back on some of your responsibilities. You definitely can't stop taking care of your home, or your kids, so the most likely candidate for sacrifice is the boring work you're forced to do in order to pay the bills. The problem is that this also means you'll be paid less, so if you don't make anything from the games you develop, there's no way this is going to work.

Game developers in this situation are taking a gamble, and testing the hypothesis that their time spent on making games will generate enough revenue to make this arrangement feasible. This may not always be the case, but the fact is that there's a market for these kinds of games, and if you're confident you can make a cool game, I don't see why you shouldn't try to sell it. Even if you fail to make money in the end, at least you're gonna have a product you can be proud of.
Re: Managing complexity by delegating minigames
by on (#177342)
rainwarrior wrote:
I can see that part of what I was reacting negatively was actually responding to tokumaru, and his appeal to the support of "homes and kids", etc. and really I agree with what I think you intended there. Selling a video game has nothing to do with being an adult with kids to feed. It's about having a game that people want to pay for. The kids are irrelevant to everyone but you. That's an appeal to charity, not a justification that someone should buy your game. Making a viable game takes risk; if you can't afford to do it because your kids are hungry, then you just shouldn't be doing it.

Double posting, because I just re-read this and I'm incredibly baffled at how you could get this impression from what I've said, like I was suggesting game developers trying to make a buck are like people selling candy in the bus telling sad stories (this might be a bad example, since I doubt this happens all around the world, but it does happen in Brazil, so whatever)... I wasn't saying why people should pay for games, I can't even understand how you'd get to that conclusion. Seriously, I have no words to describe how pointless and uncalled for this paragraph of yours was.

Your condescending tone towards nearly everyone in this forum has been bothering me for a while, but this paragraph really pissed me off. It's like you're looking for opportunities to act like this, because there was absolutely nothing about what I wrote that deserved this response.

I just erased the rest of this post, because I probably shouldn't be posting with a hot head, and I can't possibly see the words that were here before being of any use to anyone.
Re: Managing complexity by delegating minigames
by on (#177344)
I wasn't expecting that kind of response either, actually.

Maybe I've become a bit volatile. I'm sorry, I seem to have said something much more insulting than I intended. I might be reacting too quickly and too emotionally too often.

Have I really been condescending here for a while? I don't think I want to be that kind of person. I'm really sorry if I am. I know I was deliberately mean to DRW a few days ago, and I shouldn't have been. I'm a bit scared right now that I may have said other harmful things without realizing it. Maybe I should just leave the forums for a while.

If there's something specific I've done that you want to point out to me, please PM me, and let me think about making amends. Otherwise, I think I'll take a break from this place. I apologize for my behaviour.
Re: Managing complexity by delegating minigames
by on (#177345)
Don't take my word for the truth, this might be just me. We can talk in private once I cool off.
Re: Managing complexity by delegating minigames
by on (#177346)
Double posting again, because I also want to give a direct response to Bregalad. I know what your opinion on this is, since we've been in the same forum for years, and every once in a while this subject comes up, and I respect your opinion.

Unfortunately, your 40/40/40 math doesn't really work in real life, at least not for me. When you take into account the commute to/from work, the lunch hour, the (often unpaid) overtime that's inherent to many jobs, a lot more time is spent on work than you'd normally think.

Making a complex game takes a lot of dedication, and finishing big projects using only leftover time can be very challenging, I'm sure you know this.

I'm gonna talk about me now, this is not some generic example:

I honestly believe I can make a great NES game, and I'd like to test that hypothesis, but that's gonna be really hard considering I can barely find time to sleep because of the time I spend at work and taking care of my home and family. The ONLY way I can possibly consider seriously developing a full game is if I can make some money off of it, to compensate for the money I'll not be making from some random soul-sucking job that doesn't bring me any joy or sense of accomplishment.

I don't want to get rich with an NES game. I don't want money to buy more stuff, I don't want money to travel, I don't want money to party. What I want is to make a game. All I care about is bringing the game to existence. But that won't happen if I don't have the money to buy the time needed to make it. That's the only thing I expect to buy.

Look at me, speaking like I even have anything to sell! Well, that's something we're just gonna have to wait and see.

Once I have something to sell, people are gonna judge whether the asking price is fair or not. I'm not gonna force anyone to buy anything or tell sad stories to sell games based on pity. If I succeed, I'll keep doing it for as long as this process is feasible, if not, I'll probably learn something for a possible next attempt.
Re: Managing complexity by delegating minigames
by on (#177351)
rainwarrior wrote:
I don't mind if you don't want to buy cartridges.

Well, I spoke too quickly. My opinion is that the supperior model is having a ROM which is freely distributable and a cartridge as well - if I know it's going to be great because I played the ROM, I agree to pay for the cartridge (even expensive). In other words, if I can 1) play the rom of anyone's homebrew and 2) I enjoy and 3) I can order a physical cart, I will order it gladly. (This haven't happened yet, but I'm not against the idea).

If I can only play an incomplete demo or see video, then no thanks. What I am against is not releasing ROMs for free for everyone - but I'm not going to state why in order to not bring oil in the fire. If you're interested just use the search function to look at the old argument.

Quote:
When you direct these statements outwardly at others, though, I find it very offensive.

I'm sorry. We had all that argument back then, and in the meanwhile I accepted the new situation. I shouldn't have brought this old argument as this is pointless.

Quote:
I reject the idea that NES development work is exempt from monetary value. NES development isn't a special category of labour, neither is labour done on the weekends, or in the evenings, or at home, or on a boat. Unless you're violating a contract or copyright of some sort, you own your work, and you have the right to ask whatever you think it's worth for it.

I most certainly agree with all that.
Quote:
It may not be worth what you ask, but that's your own problem to solve. It's not a "swindle" unless you're actually dishonest about what you're selling. (I don't like being called a liar.)

I looked this word in a dictionary because I didn't know how to say that in english - so don't be picky on that work. What I attempted to say is that, if you're going to rentabilize selling NES games to the point of actually be rentable and feed a family from that activity, you'd have to "swindle" people your custommers. Note the "if" part.

Quote:
Partly because of angry argumentative people like me. Every thread about this here turns into a trash fire.

To my personal experience, other forums are much worse in average in this regards. Although it was, in my personal opinion, better here in the 2000-2010 time period, which probably was the golden age of Nesdev, it's still great today.

@Tokumaru : Basically, I fully agree with all what you said. Your previous post really maked it to sound like Nesdev was a rentable activity and an option for feeding a family, and I retorqued, perhaps clumsly, that it's not. We basically all agree on that.

Quote:
I honestly believe I can make a great NES game.

I honnestly believe you can, too.
Quote:
Unfortunately, your 40/40/40 math doesn't really work in real life, at least not for me. When you take into account the commute to/from work, the lunch hour, the (often unpaid) overtime that's inherent to many jobs, a lot more time is spent on work than you'd normally think.

Definitely, although in my opinion you shouldn't accept unpaid overtime exept in exeptional situations, but commuting and other obligatory duties such as eating, toilet, household, etc.., and socialising a little, easily reduces the 40 hours of free time to about 10-20.
Re: Managing complexity by delegating minigames
by on (#177366)
Bregalad wrote:
it was, in my personal opinion, better here in the 2000-2010 time period, which probably was the golden age of Nesdev

That's because I didn't show up yet, right? :lol:
Re: Managing complexity by delegating minigames
by on (#177568)
tokumaru wrote:
Unfortunately, your 40/40/40 math doesn't really work in real life, at least not for me. When you take into account the commute to/from work, the lunch hour, the (often unpaid) overtime that's inherent to many jobs, a lot more time is spent on work than you'd normally think.
Agreed, though more on the "third shift" of biological requirements being insufficient. (Though, the week being 144h instead of 120h helps mitigate this)
Sleep itself: 8 hours * 7 days/week (generally considered standard for health) = 56 hours
Hygiene: 1 hour/week if you're incredibly efficient with your time; more like 3.5-7 for those not on a military-grade hygiene habit.
Food I'd not add to work; it's not technically work. but, 1.5-3 hours/d * 7 d = 10.5-21 hours
---
so, 70 hours for bodily integrity, leaving 74; that gives you 40 for "standard" work. I don't have a commute average, but i'd guess one hour. Tokyo commutes are said to be in the vicinity of four each way, if I remember my hearsay. (That makes for 40 work + 40 commute = 80 hours, cutting into bio-maintenance, with no free time. No wonder coffin hotels became a thing.)
70+40+5*2h = 120 hours, 24 hours a week of "free" time, before ANY social activity is included.

Looks like bregalad already touched on this, but yeah. And in my experience, coding is not lke reading a book where one may easily start and stop; laying out your mise and getting thoughts in order on what to do next, and loading/bringing up your tool suite…it's overhead and being the least-prioritized scheduler item means that starting and stopping is happening a lot.

---

The worktime stuff really should be split.
Re: Managing complexity by delegating minigames
by on (#177583)
I thought the rule put in place after a previous discussion about my flawed moderation habits was not to split any topic in which rainwarrior had posted.
Re: Managing complexity by delegating minigames
by on (#177588)
I agree with tepples and rainwarrior. Don't split topics unnecessarily.

Work/Free time is somewhat related to managing complexity...time management being a factor.
Re: Managing complexity by delegating minigames
by on (#177639)
Speaking seriously for a moment, when is Lizard expected to be released? Will regular copies be available? I'm in Canada so it's really tough trying to use kickstarter up here.

Also, your avatar is better without the darkening. I dunno why but I can't help but smile when I see it.
Re: Managing complexity by delegating minigames
by on (#177656)
The darkening of his avatar is symbolism of his withdrawal, or rather to his distance in regard to this forum. Note that since his last post to this thread, he posts only about once per day, whereas just before that moment he was much more active; the darkening happened around that time, too. He is still around fortunately.

Many people feel the need to signal their leave, for example by altering their avatar in a rather symbolic way. For example, tepples cycled his avatar during one of his (short) hiatus, when he questioned the pertinence of his presence on this forum (tepples, whatever what others say, we want you over here!). Once things sorts out, rainwarrior will probably revert back to its original avatar, confirming he's back and kicking.

People should learn to take anything, and people, especially from the Internet, with a (big) grain of salt. Text never was a good medium to convey feelings in general. It's better not to assume offense from someone's writing. At other times, though, people do really hurtful things. Bregalad is opinionated and is prone to do ad hominem attacks toward others, more so when talking about making money from things apparently. For instance, his attitude once drove blargg, one of the most valuable nesdev member, away (blargg came back only 2 years after). It's worth noting however that blargg is known to be short-tempered, too, but that's beside the point. Anyways, even when faced with direct attacks, we should act civilized, recognize that the interlocutor is in fault in doing personal attacks and try to reason him, cool-headed. Try hard to break the heat/hate cycle.

I won't go as far as saying that rainwarrior was condescending, but I sure saw that lately, he had a bitter, angrier tone, which I find surprising because he used to be rather calm and cool. Guess that he's having not so great days these times...
Re: Managing complexity by delegating minigames
by on (#177676)
You would think after being a user here since 2004, everyone else here would recognize the antics of Bregalad (and also 3gengames). The latter in particular was also at NintendoAge, he was smart but had a short fuse, his angry tangents and attacks on other users got him banned.

Can't we all just kiss and make up? It seems like every new development that trickles down into the non-techy NES communities starts here. It's like stepping through the looking glass here at NesDev. I'm not overtly knowledgeable on the hardware of the NES, much less the software, but I do love to read about it. Thanks NesDev!

While we're on the subject, who founded NesDev? Was it Tepples? Memblers?
Re: Managing complexity by delegating minigames
by on (#177680)
HVC-Man wrote:
While we're on the subject, who founded NesDev?

AFAIK, Memblers started the forums. Before that we had the mailing list (back then I didn't even post as tokumaru!), but I have no idea who created that.
Re: Managing complexity by delegating minigames
by on (#177700)
dougeff wrote:
I agree with […] rainwarrior. Don't split topics unnecessarily.

But that's not what rainwarrior's position is.
I'm categorically object to all splits.

HVC-Man wrote:
You would think after being a user here since 2004, everyone else here would recognize the antics of Bregalad (and also 3gengames).

Can't we all just kiss and make up?

It takes a while for "antics" to sink in for new users, unless they're in the habit of looking at old threads. (Usually, derailed threads are not ones that users* are going to want to go back to.)
Re: Managing complexity by delegating minigames
by on (#177701)
Double-posting for ease of the split I think should happen.
dougeff wrote:
Most RPGs have at least 2 modes, overhead walking, and in battle mode.
Many also have mini-games.

I was going to rebut this by pointing out that usually, loss could not happen in overhead-walking-mode (making it technically not a "game" mode on its own), but that's just not true; Dragon Warrior's swamp/barrier tiles are a loss opportunity, for instance.
Re: Managing complexity by delegating minigames
by on (#177718)
tokumaru wrote:
HVC-Man wrote:
While we're on the subject, who founded NesDev?

AFAIK, Memblers started the forums. Before that we had the mailing list (back then I didn't even post as tokumaru!), but I have no idea who created that.


I think it was Mark Knibbs who started the mailing list, maybe?

Technically, the forums were started by koitsu and wouldn't have existed so soon otherwise, but I guess I can take credit for asking him to set it up, heheh. I knew (roughly) how to edit an .htm file and upload stuff via FTP, and that was the extent of my capabilities as a "webmaster".

I did start the NESdev site itself back in 1996 or so, it lived on Geocities for maybe a couple years before koitsu offered to host it. I still remember the URL, Athens/Olympus/2077/nes/nes.htm, which is too old to be on archive.org (they only saved the "we've moved" message).

edit: If you want to see an example of how it looked (those link colors!), at least this portion of the site remains online: http://wayback.archive.org/web/20091022232321/http://geocities.com/Athens/Olympus/2077/nes/nesm/nesm.htm
Re: Managing complexity by delegating minigames
by on (#177720)
Wow, that is quite a trip back. I didn't realize NesDev reach so far back. Then again there was Nesticle and it was a DOS program. Thing is almost nothing related to ROMs and homebrew from the 90s still exists today, it's hard for us new guys to understand.

Was anybody actually coding demos and stuff for the NES while new games were still being released? I mean in the NesDev sense, not pirate groups.
Re: Managing complexity by delegating minigames
by on (#177721)
HVC-Man wrote:
Wow, that is quite a trip back. I didn't realize NesDev reach so far back. Then again there was Nesticle and it was a DOS program. Thing is almost nothing related to ROMs and homebrew from the 90s still exists today, it's hard for us new guys to understand.

What would you like to understand? I was around for all of this (since 1991 onward), in both the snesdev and nesdev scenes. snesdev came first (early 90s, 1991 or thereabouts), nesdev came later with the introduction of emulation really gaining traction (roughly late 1996). SNES console copiers becoming available in the States through grey-market means was the main reason snesdev came first -- despite being expensive, they were some of the the first mainstream ways to get code you wrote running on the console.

Almost all first tools and things for nesdev-related (including emulators) were MS-DOS. The only thing I knew of at the time which was Windows-based was the Japanese shareware Famicom/NES emulator called PasoWing or PasoFami (the "Wing" part refers to WinG) -- the emulator which would delete your entire C:\WINDOWS directory if it found you had a pirated copy (or maybe that was Super PasoFami (same author to my knowledge, and was for SFC/SNES)). NESticle was one of the first "revolutionary" NES emulators because it offered a friendly GUI and had several games working on it that other emulators didn't, including things like Gravis joypad support, and it also worked within Windows 9x (and would in later Windows releases sans the sound, due to the sound code interfacing with Soundblaster cards directly (there was no real API, you talked to it directly via I/O ports through in and out x86 opcodes; Windows NT and later blocked direct I/O access)); the first emulator which I saw that contained amazing NES accuracy was loopynes (loopy's NES emulator), circa super late 1997 or early 1998 I think.

Not bragging or tooting my own horn, but Parodius Networking was an extremely important service provider during all of that (we hosted large numbers of emulation sites, including official homepages for NESticle and Genecyst, NESWorld, the nesdev site and later forum per Memblers, Archaic Ruins, Donut/The Whirlpool (more romhacking-oriented but still important), and several others). The late 90s were a very pivotal time for nesdev in general.

HVC-Man wrote:
Was anybody actually coding demos and stuff for the NES while new games were still being released? I mean in the NesDev sense, not pirate groups.

Not that I know of, at least in the United States. It wasn't until emulation really took off that it began; Alex Krasivsky (Landy) and Marat Fayzullin (RST38h) were two of the first people I know of to ever talk to me about NES/Famicom stuff, esp. Alex (who I still talk to today!).

I suspect FamicomDev was going on in Japan during the very early 90s, as they had Family BASIC (which I do consider a valid form of homebrew), and I remember at least one person showing me old issues of Famitsu where there were some weird homebrew efforts shown (my memory here is sketchy though). I imagine there must have been some kind of floppy-based copier at that point; I never quite figured out what the "original" Wild Card copier was; the Super Wild Card series were all for SNES, implying there might have been a Famicom copier in Asia that could've been used for early development. This is speculation on my part though.

I would strongly suggest picking up a copy of Nathan Altice's "I AM ERROR", which is a wonderful book which goes into the history of the NES/Famicom in general, including touching base on early emulation days (which is not directly the focus of the book, but it's an important aspect). Many of the people cited as references in the book are here on the forum.

An entire separate book or documentary could be done just about emulation, but it would be impossible to do for "all" emulation history. Each one would have to be about a specific console or genre; NES/Famicom vs. SNES/SFC vs. TG16/PCE vs. SMS vs. Playstation etc.. All the scenes were separate and independent from one another. There are several of us "historians" left; most of us are in our super late 30s or early-to-mid 40s (I'm 39).

If you have emulation history questions, I'd like to ask that a separate thread be created for that, as it truly does warrant its own discussion.
Re: Managing complexity by delegating minigames
by on (#177722)
As far as I know, the first NESdev-style demo (ROM with source) was junkdemo and later Mouser by Tony Young. Those were the files that got me interested in trying some NES programming and realizing that it was actual possibility. I remember I found it on some site called Game Builders, after that site disappeared I started making the NESdev webpage (can't bring myself to call it a 'site' at that point, heh).

I still have my own personal hack of Mouser that I did called Satanizer, I changed the music and graphics. What's funny is that I actually lost all the files on my old computer, but I still have that because I posted it on usenet. Later on I requested it there, and someone actually had it. :lol: Speaking of usenet, that was how I found out about emulation in the first place, from viewing the list of usenet groups.
Re: Managing complexity by delegating minigames
by on (#177723)
Very interesting history lesson. I got the impression that copiers for Famicom was mostly those FDS copiers that converts mapper 0 games to FDS disks. And the Fami-Corder that takes EPROM-based carts, and is also able to copy some mapper 0 games.

Myask wrote:
dougeff wrote:
Most RPGs have at least 2 modes, overhead walking, and in battle mode.
Many also have mini-games.

I was going to rebut this by pointing out that usually, loss could not happen in overhead-walking-mode (making it technically not a "game" mode on its own), but that's just not true; Dragon Warrior's swamp/barrier tiles are a loss opportunity, for instance.

The overhead walkabout mode in those RPGs is not only required to advance the plot or trigger events, besides possible loss from poison swamps and traps, it also forces the player to take decisions that may indirectly result in loss. For example risking more random encounters by grabbing treasure chests, using healing and other spells (direct loss of MP) and deciding when to go back to rest in an inn and so on.

But if loss is a requirement for a definition of "game", then many adventure games wouldn't be games. Many adventures doesn't even have a Game Over (e.g. Portopia if I remember correctly), the only possible loss in those games would be that the player fails to realize what to do to advance in the game. But I think most people would still consider them to be games.

I'd agree that those Visual Novels that all you do is press a button to advance the text aren't really games though, except for the few interactive parts, SRPG modes or other such things that they may or may not have. But the main part of those adventures are really electronic novels.
Re: Managing complexity by delegating minigames
by on (#177742)
Quote:
But if loss is a requirement for a definition of "game", then many adventure games wouldn't be games. Many adventures doesn't even have a Game Over (e.g. Portopia if I remember correctly), the only possible loss in those games would be that the player fails to realize what to do to advance in the game. But I think most people would still consider them to be games.

I don't know so many different video games overall, but I think unloosable games aren't all that uncommon. Mist and Riven (both Mac/PC platform) comes to mind, as well as Wario World II and III on the Game Boy Color. Actually I never completed any stage in Wario III, I never figured what I was supposed to do. I was also stuck at some point in Wario II, and bosses are extremely though/frustrating, any tiny error, and you'll have to start them all over again.

Indeed Portopia cannot be lost against, but you can get stuck, just like in all the other mentionned games.

I'll also mention that many games, such as Tetris, are loosable, but are unwinnable. I personally don't like the concept, because it's really un-rewarding.
Re: Managing complexity by delegating minigames
by on (#177743)
Yeah there are lots non-loosable games like this (Wario looses coins when hit though). And non-winnable (I like to play B-Type so I can win :)).
Re: Managing complexity by delegating minigames
by on (#177746)
B-Type is winnable. Since then, it's evolved into "speedrunning 40 lines," a common challenge among fans of modern Tetris.

A-Type is winnable too in a sense: speedrun 100,000 points (first rocket), 200,000 points (second rocket), or 999,999 points (the cap).
Re: Managing complexity by delegating minigames
by on (#177747)
Bregalad wrote:
Mist and Riven (both Mac/PC platform) comes to mind, as well as Wario World II and III on the Game Boy Color. Actually I never completed any stage in Wario III, I never figured what I was supposed to do. I was also stuck at some point in Wario II, and bosses are extremely though/frustrating, any tiny error, and you'll have to start them all over again.

I love Wario Land 2 and 3, they're among my favorite games of all time. I was quite surprised when I realized they were platformers with no health or lives, and I really enjoyed the different approach.
Re: Managing complexity by delegating minigames
by on (#177772)
You can get killed in Riven. And there are two 'bad ends' in Myst as well. Pretty sure they both just blank the screen until you start a new game, but that's a game over, right?
Re: Managing complexity by delegating minigames
by on (#177791)
Screw the "win/loss is mandatory for it to be a game". I'm with Molydeux, it's not a game unless it makes you cry.
Re: Managing complexity by delegating minigames
by on (#177797)
Rahsennor wrote:
You can get killed in Riven. And there are two 'bad ends' in Myst as well. Pretty sure they both just blank the screen until you start a new game, but that's a game over, right?

Myst have to bad endings, but you can restart just before and get the good ending by giving the white book to neither of the two bad guys. Riven you cannot get killed, but you can be trapped in an empty room. It's however clearly stated in the game that this is a trap book and that you have to use it against a vilain - so it's not a "trap" like the bad endings of Myst. However, if I remember well, you *can* save after being trapped in the empty room, and if you do so, well too bad, you have to resort to a backup save, potentially loosing progress.

I find many exampes of either unwinnable or unloosable games, but I wonder wether there is a game which is neither winnable nor loosable, but is still unambigiously a video game.
Re: Managing complexity by delegating minigames
by on (#177836)
Bregalad wrote:
Riven you cannot get killed, but you can be trapped in an empty room.

Gehn will shoot you under certain conditions. IIRC you have to be pretty dumb (like me) to get that particular ending, so I wouldn't be surprised if you haven't seen it, but even Wikipedia mentions it.
Re: Managing complexity by delegating minigames
by on (#177842)
Wouldn't want to say that loss and victory are necessary conditions for a game to be a game [Tetris A], but I do think "victory and loss states are both possible, and player input influences which may be reached" is sufficient to call something a game.

"A victory state exists, and player input influences when it is reached" would be Portopia.
"A loss state exists, and player input influences when it is reached" would be Tetris.

One may note that in both cases, a lack of input guarantees the loss or that victory is never reached.
Re: Managing complexity by delegating minigames
by on (#177879)
Myask wrote:
One may note that in both cases, a lack of input guarantees the loss or that victory is never reached.

By that measure, Mario Party series isn't a game. I seem to remember watching videos of someone playing its minigames without any input and winning.
Re: Managing complexity by delegating minigames
by on (#177904)
Wasn't including that as part of the definition, just a typical feature of "PnC adventure" and "endurance"-type games which may lack loss and victory states, respectively. [Besides, without input in Mario Party, you never roll a die, never START the minigame, etc. etc.]

Also, those are still unlikely outcomes (taking many retries to get the "null input beats AI" footage)…and, as a competitive game, win AND loss states exist. So it fits the less-complicated first definition I put.

One could imagine a Dr. Mario level and pill sequence that can be won with null-input. After a certain virus count, this becomes impossible, simply because the virii can no longer all fit in monocolor pairs/triples alongside the drop path. However, 1. it is exceedingly unlikely and 2. the progression of levels (ignoring for the moment the menu-type input needed to progress levels) will eventually lead to a state where P(loss|∄input) = 1.

Nor am I stipulating either as necessary nor sufficient conditions for a game, merely supporting arguments therefor.
Re: Managing complexity by delegating minigames
by on (#177955)
It really depends on what you mean by "winning" and "losing"

For example, games that require you to do things in a time limit may be considered "unwinnable" and "unlosable"
Like Fruit Ninja where you have to slice fruit, but if you choose not to, it isn't really a problem. You could argue, though, that the fact that the game "ends", in neither a victory or a loss, means it still has "win conditions", but at this point, we're arguing in pedantry, not in actual game design.
Re: Managing complexity by delegating minigames
by on (#177960)
Or to put it more succinctly: Can you "win" golf? Whether so or not, you can "win" speedrunning B-type Tetris to the same extent.
Re: Managing complexity by delegating minigames
by on (#178029)
tepples wrote:
Or to put it more succinctly: Can you "win" golf? Whether so or not, you can "win" speedrunning B-type Tetris to the same extent.

True! These are in "competitive score*-based", which have a very simple definition of winning; who has the better score wins. Golf has an insuperable score at strokes = holes.

*let time be a score
Re: Managing complexity by delegating minigames
by on (#178068)
tepples wrote:
Myask wrote:
One may note that in both cases, a lack of input guarantees the loss or that victory is never reached.

By that measure, Mario Party series isn't a game. I seem to remember watching videos of someone playing its minigames without any input and winning.

Haha I love that clip. Then again no input could also be considered a kind of input. Like the low block in Super Punch Out is only done by not pressing any buttons. But in this case it's really just that the random factor in Mario Party is very high.
Re: Managing complexity by delegating minigames
by on (#178442)
Going back to the original post... I feel this "modular" approach to game design and implementation often leads to a game that feels like different games bolted together. That's generally not a good thing, if you ask me. I think games should feel like a sort of unified whole as much as possible.

I don't like "modes" in games in general. A classic example and major offender is the JRPG. The typical JRPG has two primary modes: an overworld mode where you walk around, talk to people, open chests, etc.; and a battle mode where you fight monsters. Have you noticed, though, that the overworld mode is almost completely lacking in gameplay? You're making very few interesting decisions while in overworld mode; you're mostly just going through the motions. And you spend hours and hours doing that! No wonder I don't play many JRPGs these days.

Now take an action RPG (or action-adventure or whatever you want to call it) like The Legend of Zelda. There's still a little too much walking and talking for my taste, but y'know what? The monsters don't really interrupt you the way they do in a JRPG. They don't yank you out of your overworld exploring and go, "And now for something completely different!" You just take care of the monster then and there, and then you're on your way. If that's not a seamless, well integrated experience, what is?
Re: Managing complexity by delegating minigames
by on (#178477)
furrykef wrote:
I don't like "modes" in games in general. A classic example and major offender is the JRPG. The typical JRPG has two primary modes: an overworld mode where you walk around, talk to people, open chests, etc.; and a battle mode where you fight monsters. Have you noticed, though, that the overworld mode is almost completely lacking in gameplay? You're making very few interesting decisions while in overworld mode; you're mostly just going through the motions. And you spend hours and hours doing that! No wonder I don't play many JRPGs these days.

Now take an action RPG (or action-adventure or whatever you want to call it) like The Legend of Zelda. There's still a little too much walking and talking for my taste, but y'know what? The monsters don't really interrupt you the way they do in a JRPG. They don't yank you out of your overworld exploring and go, "And now for something completely different!" You just take care of the monster then and there, and then you're on your way. If that's not a seamless, well integrated experience, what is?


Many modern JRPGs have you fight in the overworld, you can escape behind terrain features and even run away. Xenoblade is a good example.

Also, I disagree that exploring is not gameplay. About Zelda, in some Zeldas, in places I get this feeling "oh just quit with the #¤#% monsters and let me solve the damn puzzle in peace", haha.
Re: Managing complexity by delegating minigames
by on (#178559)
Yeah exploring is definitely a big part of the gameplay in those games. As I said the exploring mode is a place where you take important strategical decisions (something I'd consider game defining) just like in battles. The importance of these decisions varies between games though. In your avarage DQ or FF game it's mostly about healing, treasure collection and the occasional puzzle, while Lufia II for instance have tons of quite challenging puzzles in each dungeon. Also the random encounters are strictly limited to the world map, while in dungeons monsters move in a rogue-like turn-based fashion so you can still not easily avoid them.

The nature of the JRPG battles is like it is, of course, due to the fact that the genre originates in paper and pen RPGs. How much the battle mode is integrated in the exploration mode also varies greatly between games as Calima said.

Personally I greatly enjoy games that mixes several game modes as long as they are all done well and fit into the situation.