Page 4 of 5
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 11 May 2013, 17:12
by smoth
knorke wrote:In spring many nice things are made. But many stay out of reach for players because something else is blocking.
Cool stuff dies as techdemo because of some small problem, so much lost potential.
examples:
-maps with mapoptions. springie hosts do not support them: so why would anyone want to code mapoptions into their map if half the autohosts will not be able to use them?
-missions. there are/were several editors and systems to make and play missions. But starting the missions is difficult because not all lobbies support missions. (or not all types of missions)
-ingame menus for singleplayer, campaign and such.
technically possible and done but useless since getting into these menus is so hard. Previous two I dont know how to fix, but this one might be doable:
http://springrts.com/phpbb/viewtopic.php?f=64&t=30376
A good few of those issues would be resolved if spring didn't have to restart in order to load a new map. This would allow people to develop the entire user experience in the game and thus support whatever they need but at the moment to load a level means to have to restart spring, this is ugly and while some OLDER games do it, most modern games do not.
Sure we could do the whole, auto reconnect to the lobby once they are back in game but there is no protocol that I am aware of to handle a players is "joining" instead of in a battle or out. Furthermore because hosting is so iffy, people frequently fail to join and are greeted by spring just exiting.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 03:42
by Forboding Angel
knorke wrote:
-missions. there are/were several editors and systems to make and play missions. But starting the missions is difficult because not all lobbies support missions. (or not all types of missions)
Nah, this isn't that debilitating and missions hasn't died because of it.
No one seriously bothers with missions because if you use a mutator for the mission, that mutator MUST target a specific game version. This is fail for so many reasons. Abma is already aware of this and afaik, working on a solution.
If mutators could simply target games, regardless of the version, that would solve nearly all the issues with missions. Lobby support... does anyone really take SL seriously anymore when you look at the alternatives?
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 03:52
by smoth
Z's mission code does not require a mutator
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 11:08
by KDR_11k
My main gripe with Lua is the dynamic typing, while that makes it easier to write code it also makes bugs much harder to trace (especially when nils end up where they don't belong and you have to trace how they got there). But maybe there's a way to get strict typing that I just don't know about.
One of these days I should get used to OO Lua as well, would probably have helped a lot with Fibre.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 13:19
by knorke
A good few of those issues would be resolved if spring didn't have to restart in order to load a new map.
restart is not so bad.
That is only polish for next or second-next step, the bigger problem is that players can not easily go into the ingame menus
at all. Which is solveable relatively simple imo, see linked thread.
"Not having to restart" on other hand is probally big change that it is not worth to talk about. Without the other thing it is also quite useless..
---
Not all missions use mutators. You can edit the mission to point to newest mod version.
Many players still use springlobby (including me) or even TASClient so of course it has to be taken serious...
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 13:28
by Silentwings
Yeah, I agree that lobbies not being able to access the various mission systems from lobbies is a problem.
It would be good if missions could be accessed and count towards server ingame time.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 14:48
by smoth
knorke wrote:A good few of those issues would be resolved if spring didn't have to restart in order to load a new map.
restart is not so bad.
That is only polish for next or second-next step, the bigger problem is that players can not easily go into the ingame menus
at all. Which is solveable relatively simple imo, see linked thread.
It is kind of annoying that you are reminding me of a menu system that was part of gundam and is part of my next project(although I am chilifying it eventually). Yes I am aware of it.
knorke wrote:"Not having to restart" on other hand is probally big change that it is not worth to talk about. Without the other thing it is also quite useless..
---
Problem is if I want to have them login to the lobby server to see games people will see them in the lobby, try to pm them etc and that is a problem. so not having them stay in lobby or dropping out to join games becomes a problem. Again, there are changes that need to eventually happen, if they are even possible at this point.
knorke wrote:Not all missions use mutators. You can edit the mission to point to newest mod version.
Many players still use springlobby (including me) or even TASClient so of course it has to be taken serious...
yes and I am saying that eventually some games may move away from it entirely. I think expecting everyone to use the lobby approach is wrong. I still don't know why the zk mission system requires mutators, it always seemed like a bad design decision to me.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 15:42
by knorke
I still don't know why the zk mission system requires mutators, it always seemed like a bad design decision to me.
So that players can make missions, publish them and they are instantly available for playing. If the missions are included in mod you have to wait until next mod release to play them. The mod can also stay free from all the extra files of each mission: pictures,lua,audio,extra units,...
So it has some good points.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 12 May 2013, 22:24
by Forboding Angel
smoth wrote:Z's mission code does not require a mutator
It's also not really a mission editor. About the best it comes close to is "Scenario" editor. There is no comparison to the zk mission editor. It's like using MSPaint vs Photoshop.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 00:01
by zwzsg
Ideally, I would have wanted the mission data to be all contained within the startscript. Sadly, the startscript are limited in filesize to something like 32k, which is easily reached just by describing a bunch of units and order list, so I had to jump through hoops to make Spring load them.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 00:13
by gajop
Forboding Angel wrote:
It's also not really a mission editor. About the best it comes close to is "Scenario" editor. There is no comparison to the zk mission editor. It's like using MSPaint vs Photoshop.
So it's better than ZK's mission editor? Since as far as I see it scenario editor is more general than a mission editor :).
Just think about WC3's Scenario Editor for a moment here.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 04:06
by smoth
knorke wrote:I still don't know why the zk mission system requires mutators, it always seemed like a bad design decision to me.
So that players can make missions, publish them and they are instantly available for playing. If the missions are included in mod you have to wait until next mod release to play them. The mod can also stay free from all the extra files of each mission: pictures,lua,audio,extra units,...
So it has some good points.
OR, people could make a mission then make it a mutator for the game. Then the game could have use of the mission system as well. it is nice and all for people to be able to make missions but the requirement that they are a mutator is bad imo.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 09:43
by PicassoCT
Lets define a abstract interface for the mission editors:
"weak Air Harrasment Unit" is used in the editor and the game has to provide a xml document that declares what unit actually is currently the weak Air Harrasment Unit.
If not declared, everyone with a texteditor and basic knowledge over units can fill in the file - and suddenly its moddevs job to get stuff working. If not defined, you end up with a mission were nothing is happening, and information how to change that.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 15:57
by smoth
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 16:38
by knorke
smoth wrote:knorke wrote:I still don't know why the zk mission system requires mutators, it always seemed like a bad design decision to me.
So that players can make missions, publish them and they are instantly available for playing. If the missions are included in mod you have to wait until next mod release to play them. The mod can also stay free from all the extra files of each mission: pictures,lua,audio,extra units,...
So it has some good points.
OR, people could make a mission then make it a mutator for the game. Then the game could have use of the mission system as well. it is nice and all for people to be able to make missions but the requirement that they are a mutator is bad imo.
I have no idea what you mean.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 17:16
by smoth
Zk's missions require them to be a mutator. Meaning if I wanted to use it to create any sort of story mode, I would have to run each mission through a mutator, which is TERRIBLE.
if the mission's didn't require a mutator, I would have adopted them years ago.
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 17:18
by Anarchid
What's so horrible about a mutator?
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 17:21
by smoth
Anarchid wrote:What's so horrible about a mutator?
are you joking or really wanted to understand?
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 21:36
by gajop
Anarchid wrote:What's so horrible about a mutator?
Indeed.
How else would you do it?
Re: Game Dev Obstacles (split from Spring developer crisis)
Posted: 13 May 2013, 21:53
by smoth
gajop wrote:Anarchid wrote:What's so horrible about a mutator?
Indeed.
How else would you do it?
Z's missions play fine for mutators. I am mildly annoyed that you both skipped the SINGLEPLAYER idea and wanted to know why mutators being required is a bad idea.
if a person was going to add anything to a game they would require a mutator. If the DEVELOPER OF THAT GAME wanted to add a mission it should be able to be loaded from a menu in that game as part of that game. Not exit, go to lobby run mutator. Not exit, run startscript go to mutator, hope gamedev didn't forget to maintain mutator.