Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 27 Aug 2003
Offline Last Active Today, 01:34 PM

#5227143 Business Sim Game How to simulate the Market

Posted by Luckless on 04 May 2015 - 09:05 AM

Wait, are you going to model each customer, and calculate stats based on how they liked each product in the market on the fly? Because that sounds like it would be a lot of number crunching and data storage that really isn't needed. 


Look at it from a 'market trend/desire' stand point, and grow or shrink them over time. So you have an overall desire for Product Type X, which then has market desires for various features. From that you compare the various products of Type X on the market, and calculate its market share. You can achieve a market simulation using just dozens of values, rather than millions.

#5226741 Copying a scene from a movie?

Posted by Luckless on 01 May 2015 - 12:52 PM

I think Tom Sloper's reply really should have been a "No.*" 


* The general idea of a team dropping cards from a plane onto a mountain and chasing bad guys in and of itself is not readily something you can claim copyright over. You could probably try claiming ownership over something like that, but it is unlikely to go over well in court for whoever tries to push such a vague claim. However, if you're actually copying elements of the scene, then you're getting out on thin ice.


Taking the line "Dropping cars out of an airplane onto a mountain and racing/chasing bad guys", and then running with it to design a scene for your game: That's good.

But taking the actual scene itself, and trying to run with it? That's not so good. Don't hold up screen capture or clips of the movie and try to recreate that in your game, because that IS stepping on their copyright. (And potentially trademark if you model real world stuff too closely.)

#5225340 Steam's compensated modding policy

Posted by Luckless on 24 April 2015 - 04:26 PM


When fallout 4 comes out, I begin porting the mod to fallout 4, and release small patches every few hours, until it's done. Would valve allow that kind of early-access style stuff to occur? Would the potential hit to their reputation justify this model? I could see them stepping in to prevent cases like this.


If I was a developer, and I didn't like it, I'd disable Steam Workshop for 45-90 days until after release. And for the next game I release, I just wouldn't enable Steam Workshop until I wanted to.


But I don't see it being a problem... especially if you're basically selling day-one DLC that the developer gets a significant cut of, without the developer doing any production work. And I seriously doubt it'd detract from official DLC sales, unless the official DLC is crap, or unless official DLC shows up alongside 3rd-party DLC (currently it does not).


Plus, many games sell their official DLC from within their own game (though it requires Steam-overlay or the program minimizes and poping up the Steam client for you), whereas very few games have built-in Steam Workshop support within the game's interface.



Paid mods made by third party developers who hand over a cut of their sales, and who can be kept at arms length from the publisher and developer? How is that remotely a bad thing from the stand point of the dev/publisher? 


"Hey look at our awesome game with its great core game play, expansive official DLCs, And beyond that there is even more large scale quality polished mods! Oh, that mod was a flop and sucked? Yeah, we heard about that, but the only thing we can do is suggest that customers avoid stuff from those guys. Oh hey, speaking of avoiding stuff from those guys, have you seen our latest DLC?"


Don't want to pay for mods? Don't click on the paid mods filter.

Don't want to make people pay for your mods? Don't release them as paid mods

#5223488 When you realize how dumb a bug is...

Posted by Luckless on 15 April 2015 - 12:33 PM

My usual programming stance is to update comments to reflect that there is a change in progress, and describe what the change is, how it is supposed to work, etc, etc. Keep updating comments as I go along with code and section tests, and then when I'm done I go back and clean up the comments a little, moving outdated info into a module journal. It means I write two or three lines of comments for any given line of code, but it also means that when I get back to my code after a random break I'm able to not only read the code itself, but read the random little thoughts I had along the way and get back into the same mindset I was in when I first came up with it.


So far I haven't gotten myself into too much trouble when I put that much more time and effort into it, but rather often have problems when I get lazy and put it off till some time 'later'.



Also, my biggest headaches tend to come weeks or years after I came up with something 'really neat and clever'. So my general thought now is that if I think I was being clever when I wrote something, then I probably should rewrite it.

#5223481 When you realize how dumb a bug is...

Posted by Luckless on 15 April 2015 - 12:02 PM

Simple tool code being written more as a proof of concept/rapid functional prototype that I've been working with off and on for more than a year. There was some weird edge case that would break filling some data into a tree structure for display that was giving me issues because of how I had laid out the initial code for it, but I thought I had a solution to the problem while eating lunch. Quickly scribbled down pusdo-code on a pad before heading back to the office, and then really quickly wrote a new function to drop in place of the old one. It worked, covered all the edge cases, and I was able to fire the system up for a demo a few minutes later to show off a 'bug "free" version' of the program. 


The tool worked, did what we needed it to, so 'good enough', and Surprise! All my attention is now needed elsewhere, the tool was considered 'done' as it met all our needs for internal use, and we would worry about any bugs in it if and when they popped up. We expected that I would have a few hours later that week to go back and tidy things up a little before actually parking all the code, but the days of that week turned into weeks of that month, then months of that year. When we finally DID have to go back and make some updates to account for a slight change in process... Well, Surprise, I had never actually gotten around to writing comments for the new code. And I had stupidly copy/pasted some of the old code in rather than taking the time to rewrite all the variables and internal stuff that I still needed. So a coworker ended up trying to sort out what was going on with my 'graceful and clever' bit of code based on comments for code that did things in an entirely different manner.




Another fun and memorable mistake was one I ran into early in my career when I was doing more testing than code. I was working on a mobile game as a new guy, and since I was never working on anything critical I would often get tasked with sitting down and running through the entire game on an end-user testing check to make sure bug fixes were, you know, actually fixing things. There was a fairly minor bug in the alignment of some graphics at the very end of the game, but it was rather critical because you couldn't actually finish it. Ran through the game the first time, reopened the ticket because there was no change. Few days later the new build is ready, and the bug is flagged as fixed. Nope, reopen. Comes back a few days later, same thing. This repeats a dozen or more times, and we eventually realize that the guy who was fixing it kept forgetting to roll his branch of the code into the main trunk line, so he never actually deployed his fix on to the general build server, only his personal builds.


So remember to check your build and version handling.

#5220793 Unloved colonization

Posted by Luckless on 01 April 2015 - 02:54 PM

maybe look at it as populations/control, and loyalties/resistance.


So Population would add to a faction/players control over a planet and its resources, but there can be modifications to the control level based on military power and such. Throw in loyalties within a population, so that a given player can work to not just try and rule by force and suppress the existing populations when they try and take over, but they can actually lure them over to their side. 


Having a battle fleet in orbit of a peaceful agrarian culture who has no military power might mean that you have no population there, but effective control. If you have no loyalty points within the population, then you could face stiff production penalties if the population has any kind of resistance traits.


This lets you craft different kinds of populations, such as a highly passive species who is happy to work, but really doesn't care WHO they work for. They'll have no loyalty to you, but at the same time offer no resistance to your control. As long as you stay 'in power' then you get the full benefit of them as if they were your own population. But if someone kicks you out, then they will face no penalties from that population, they'll just switch over without a fight.

#5207962 Roguelikes and "dice"-based combat

Posted by Luckless on 31 January 2015 - 05:25 PM

In traditional styles the 'skill' is in decisions and thinking several moves ahead. Yes, it is highly random, and you can get sessions where you get a series of really bad rolls which lead to situations where you can't see a way out, but that is part of the game. Often if you die it was because you over extended yourself, moved too deep and let yourself get caught fighting too much too close together and couldn't make use of healing methods. It Is a risk and gamble when you move to 'the next square', but you're not really meant to just keep moving forward blindly. Careful thinking with regards to the mechanics is where the skill lies in many of these games, and making decisions like taking several steps back before moving forward to make sure the combat happens when and where it is most favourable. (Usually very applicable to ones that implement some kind of character collision detection, and forcing combat into bottle necks where you aren't as easily flanked for example.)

#5201950 Is it a good idea to block android phones that cause lots of trouble?

Posted by Luckless on 05 January 2015 - 08:35 AM

In general you should avoid having your app trying to run on devices that Can't support it, and do your best to sort out what is causing problems on various devices before you declare that the device can't actually support it. Digging into the problems can help you find some rather critical errors and design flaws, and can greatly improve how the app is running on other devices that run correctly most of the time.


Out sourcing a limited bit of testing to a larger testing house may be worth it for your app. Some testing houses will take small scale contracts for device sweeps and such, and since they're supporting dozens of clients they can have hundreds of models of Androids to test against. For the cost of a few dozen devices you would add to your library you can instead gets days of dedicated professional testing against a far wider range of devices.

#5200322 When is it okay for a player to get "stuck"?

Posted by Luckless on 27 December 2014 - 03:43 PM

I don't think that players strictly need a big flashing red sign saying "YOU LOSE!" when they have failed the puzzle, but rather the mechanics should allow them to gracefully revert and move forward again.


Take a look at how portal (Probably one of the most commonly known puzzle games that is so well executed) handles things:


The player either dies, and the level reloads for them (fell into fire, acid, allowed themselves to be shot too many times, or possibly crushed? I haven't played through in awhile and forget all the ways you can die), and this represents a 'hard failure'. This is opposed to a soft failure, such has dropping a block in acid, or passing it through the nullification field. You've screwed up, but it is fairly obvious that you probably weren't supposed to do that, and either they automatically give you a new tool piece to work with, or you have to manually go and press the button to get one yourself. (And if you try to request too many then it will very obviously destroy the previous one on you.)


Challenging is fun. Deciphering a complex system and working out a solution? That is interesting. Being frustrated is not fun. You don't want to simply hold the player's hand and make things a cake walk, but do make the process of moving through puzzle sections as streamlined as you can. Give them clear methods to reset or revert easily if they need it, and make cause and effect fairly obvious. (Don't have a button in a 3 stage puzzle that has a 'random' effect for example on the last room, but can only be pressed in the first.)



And avoid the 'false choice' effect in puzzles. If you have 3 'doors', two of which contain your death and one the solution, and zero information before hand about them, then you haven't actually given the player a choice. You're just slapping them in the face going "HAHAHA, I'm so much cooler than you because I'm the developer and I already know all the answers you stupid little twit" because they have zero useful knowledge to help them make a choice short of making a choice and then memorizing the outcome. If the only way I can pass a puzzle is by pure luck or having already failed in all the possible ways, then it is a bad puzzle because it is instead a memory/luck based obstacle that you grind your way through, not a puzzle which you actually devise a solution to.

#5200159 When is it okay for a player to get "stuck"?

Posted by Luckless on 26 December 2014 - 05:24 PM

Failure of a puzzle game really should either be effectively instant, such as falling into the acid in portal, or should allow the user to seamlessly return to the beginning if they feel they may have messed something up.


Add a 'teleport pad' or something beyond the 1 way door, which carries the user back to the initial part of the level, and clearly tells them that the task has been reset. 

#5198583 AI in 4X

Posted by Luckless on 16 December 2014 - 01:52 PM

Just trying to throw out a bunch of questions to hopefully drive some more conversation and input from others as well:


So will Tier 1 continue to demand a given planet, regardless of resource cost to get it? Can it decide that "Hey, attacking this planet from the large empire next to us is kind of a bad idea, lets go after some of their smaller enemies instead? The enemy of my enemy is my friend, and maybe they won't attack US instead if we're helping them?"

>Edit: How does the AI see things if they change, such as that small single planet opponent just got annexed by BIG_BAD_SCARY_EMPIRE_3?


How do the various levels of AI gain information to base their choices on? How do they calculate potential profit? Risk vs Reward?


How are the actions/threats of other "Players" accounted for, if at all? Does the AI have the ability to make educated guesses of what other Players or AIs are working towards, and decide if they pose a real threat? (ie, do they focus just on growing in a relative vacuum and expand by picking off the easiest targets nearest them, or do they evaluate everyone around them to prioritize where they attack/expand? A simple 'easiest growth path first', or would "Large Empire A" ever attack "Small Empire B" instead of the easier target "Small Empire C" just so as to deny "Large Empire D" from easily advancing into "B"'s planets?)

#5198534 AI in 4X

Posted by Luckless on 16 December 2014 - 08:14 AM


I like your idea! If I understand it correctly there will be set of "advisors" on many levels, that can deliver their requests to the higher level for consideration, right?
No... Not exactly. The order is given by high levels and executed by low levels. So it's the other way round (the high levels giving advices/guidelines/gloas for low levels).


The lower level could give the feedback of the orders received, but that's just an extra (probably not needed really).




Every turn your goal values would be updated to help decide the next move
No, no, no. That's the thing I want to break from. Thinking in terms of "where to move units", instead I want thinking in terms of "what the AI wants to archieve" (territory focused, not units focused). Where exactly move units is the last (lowest level) step and not that important.


I don't want it min-max algorithm driven, where the AI reevaluates the situation each turn. I want it data driven where the AI builds on already existing past orders.


"Next move" doesn't have to be as low level as an actual unit move, but can also be an update to your grand strategy target.


However, I think you're going to hit a rather awkward wall if you try to break away from weights and values map evaluations. What exactly is your AI going to use to make choices? Arbitrary dice roll? You need some means to map out data and come to conclusions. Humans do the same thing, but are far more arbitrary and imprecise in our evaluation of those numbers. 



So you have your highest level AI. Describe how it makes a decision. Break it down into pusdo-code level and explain [i]how[//i] it is deciding to attack planet A or B.

#5198416 AI in 4X

Posted by Luckless on 15 December 2014 - 03:10 PM

One thing to consider when looking at building a more rounded and human feeling AI is to consider adding 'momentum' and 'focus' into the equation, and build the system around the idea of goals.


At a given turn the AI will have a set of possible goals. "take this planet", "Defend area", "Address threat of planet/fleet/unit/whatever". And since they most likely have more possible goals than what they have units/pieces to go after them all then the AI will have to pick a subset of possible goals to be its target goals. (The ones it is actually going to work towards)


Every turn your goal values would be updated to help decide the next move, but any goal that IS set as a target is then given 'mass' over and above the base value of the goal itself. The more turns a given goal stays as a target then the more mass it accumulates. The AI then acts on goals with the highest mass first, and then falls back to goal value. 


In a given turn the mass of a target may be bumped or reduced based on the changes in relative base goal value. The idea is to build the system to gather momentum so it stays on target for more than a few turns, rather than suffering useless flip-flopping. (Errors like, move force towards Planet A to attack, which then reduces their defence at Planet B, and then next turn they abandon the attack on A to reinforce planet B, which is followed by a decision to attack Planet A again the next turn...) The game situation would have to change a lot more before the AI 'reacts' due to the value changes across the map than it often does with traditional styles. 



The concept of 'focus' can be worked in to help vary the difficulty and personality of an AI. Goals/targets in close proximity to where the AI is already working can get an artificial 'focus' boost in value. You can play with these settings for taste and flavour by small modifications to the rules and values. A heavy focused AI will grant a large weight around a small area of a single focus point, which can create a threatening AI, but which can also be defeated by spreading your own focus around them to attack from multiple angles. 

Compare that to a more loosely focused AI, which grants a smaller weight over a wider area around more than one focus point. They'll be more unpredictable, and faster to change targets. Add in a 'feint' goal/target type, and a bit of tuning, and you can have an AI style which becomes exceptionally devious on a fairly regular basis.

#5194176 Multi-path story/simulation game with anonymized multiplayer feedback - has t...

Posted by Luckless on 22 November 2014 - 04:17 PM

I think you may have to expand a little more on how the players would interact with each other's worlds, and how you plan to actually generate those worlds in the first place.


But related to what you're talking about, and an idea that may be useful to you; I have long been thinking of an idea based on community 'script' development and a loose AI director. 


The point would be in a procedurally generated RPG would be able to string together 'scripts' or 'plot lines'. The game could either be run in 'strict' mode that follows a detailed long plot line from start to finish that would be written in the style of traditional cRPGs, or in a 'string' mode, that will tie shorter scripts together for a more Rogue like feel. 


Scripts would belong to various levels of a hierarchy, and use standardized tags to identify things. So at the top level someone could write a script about the interactions of two "Big Bad Gangs", and how "Character A" is a triple agent, betraying first one gang, then the other, and coming out as a mastermind. But the script itself doesn't need to define much of anything about either gang, or Character A. Low level scripts would define details about character, stats, precomposed lines of dialogue script, etc. And then a few layers in between based on how complex your system is. 


So when running in loose mode the game would start pulling together scripts from various sources and using them to guide a player through a game.



The elements that I see making such a system work well (And it is an insanely complex one that I haven't devoted serious time to developing due to its scope) would be community management methods. You ideally would have a detailed ranking system for the value of the scripts, as well as metadata describing what kind of script it is and what kind of stories it is suitable for. An automated blind peer-review system would be idea, having players score and provide feedback to authors, but not be able to see any consistent identifiers. (This is to help avoid trolling. Trolls can't work together as easily to push through deliberately 'bad' content, nor focus attacks on other people's good content because they will have no control over which user's content they're rating. And then automated ranking systems should help bring vetted authors up to the top of the list.)


Players then would configure their game generation through filters based on community standardized key-wording. So they have a loose control over what kind of plot lines and scripts the system will select to throw at them. (Or could choose to select from the hard written modules instead.) You can also include a feedback system from the players as well, having them score their enjoyment of the game when they finish. That info could be tied back into future game generation in some way, or spread points around the scripts the game used. After awhile you could build up a system and core dataset that can generate a huge range of really compelling games that combine good elements from hand crafted game worlds with the unpredictability and replayability of procedural content. 


In theory you could also extend such a system to game assets, and add additional elements to your visual or audio aspects of your game.

#5191150 Where to find test players?

Posted by Luckless on 04 November 2014 - 11:34 AM

Ask friends. Join a community of some kind, spend time being part of it, and then ask if anyone there wants to give you a hand. (Generally signing up on forums just to look for help gets considered as spam, but if you actually play the game or genuinely take part in the community in question then requests for help after the fact are better received.)


However, random help like that can be unreliable. Friends often don't want to be too harsh, or will look at everything with the friendly rose coloured glasses. Random people online are likely to give poor and unfocused feedback, and getting real testing on features or concepts out of them can be similar to herding cats. 


Depending on your project then you may want to look into hiring dedicated testers. (Bias warning, I'm actually employed as a professional software end-use tester, but I've had the 'pleasure' of dealing with community feedback for projects we've tested, and it can be painful compared to the structured, detailed, and targeted reports actual professionals tend to generate.) Also pay extra for a company with testers in a country that speaks your native language and is well aligned culturally. Sure you can 'save' money and pay a fraction for something overseas, but it is very easy to lose all those savings in frustration and inefficiencies that grow out of language or cultural barriers. 


Good luck with your project.