Author Topic: Need help understanding the game  (Read 3637 times)

0 Members and 1 Guest are viewing this topic.

April 25, 2017, 08:09:25 PM
Read 3637 times

coldcell

  • *
  • Information
  • Newbie
  • Posts: 2
    • View Profile
If I'm getting this right, at the basic I should have:

1 team consists of Artists (A-team)
1 team consists of Programmers (P-team)
1 team consists of Designers (D-team)

When I develop something, I assign the D-team. When the green bar is full, I immediately assign A-team and P-team in, D-team out.

Is this the phase where I should try to review it? What kind of team (A/P/D) is best used to review it?
After the product is released, I should maintain Support team for its active users? What kind of team (A/P/D) should it consist of? Purely P-team or need A & D too?
What is the rule of thumb to know how many Markerter I should hire, how much marketing budget to assign, and how many copies to print?

When developing something, how do I identify which product require which specialization? Like for 2D tool, it's self-explanatory that I should have A/P/D with specialization in 2D. But the other projects aren't as clear cut.

What is the ideal length of working hours? Should I have 3 teams of Artists, 3 teams of Programmers, 3 teams of Designers that work 24/7? Currently everyone starts at 8 and leaves at 16 (default), and I don't know if this should be changed or not.

The tutorial in-game is basic and I'm trying things out, but it'll help to get answers from other experienced players to help speed the understanding process. Thanks for reading.


April 27, 2017, 03:12:40 PM
Reply #1

Ixby

  • *
  • Information
  • Member
  • Posts: 8
    • View Profile
Team setups like that work just fine, though you may run in to stress issues by having one team of artists/programmers/designers working on several projects at once. Some folks like to create a team specifically for a product chain, like having one team focused on 2D editors and just constantly pumping out sequels to that, while adding members as necessary when the software gets more features. Also, keep in mind that having too large of a team will actually be detrimental to your code/art output.

I'm not sure if you can review during the design phase, though I don't believe you can, nor can you review in Beta. I'd wait until the lines of code are in the tens of thousands before doing reviews, and unless you're strapped for cash or something, just outsource and don't bother using one of your own teams. Last few times I did internal reviews, the accuracy was around 20%, vs the 80% you get from outsourcing. Also, you don't have to let the outsourced review max out and cost you thousands, you can stop it at 10 reviews or so just to give you an idea of how your project is doing. For contracts, using client reviews are free and also typically quite accurate.

You should maintain support for your products with active users where possible. Cancelling support while people are still using the software will cause you to lose fans, and having a slack support team that can't keep up will cause support tickets to get 'missed' and..well I'm not sure exactly what the effect is, but I assume it's also going to hurt your fan base or market recognition. As far as I know, support teams can consist solely of programmers and they seem to get the job done like this.

Hire as many marketers as it takes you to complete press releases in a timely fashion, while also being able to hype and keep fans from dropping too fast (a marketing night shift helps with this) as well as living up to the marketing budget you've set for your on-the-market products. A team of 2 or 3 marketers might be able to fulfill a 10-20k marketing budget for a single piece of software while doing hyping and a press release on the side, but it's best if you play with it via trial-and-error to get something that works for you.

You can print software once you go into the beta phase, so I'd start as soon as that happens and get something like 100k copies of your software if you're just starting out with no recognition. The distribution window can show stock levels and printer outputs at a glance, and the marketing window for a piece of software will tell you how much it made in sales profit for that day/month minus the marketing budget you've assigned and spent. Typically 10-20k on newly released software should get you from Sparse to Prominent reach pretty quickly. If you're already known, or released with a ton of followers, you may even start higher than Sparse.

The only time you can see the detailed requirements of software is in the New Software window before you actually start the design phase. As you add features, the pie chart at the bottom will change based on the stuff you've selected, and that will tell you what kind of programmer and art skills are required for a quality release. It doesn't split Art from Code in the pie chart, but if you see Artists are in the recommended team composition, and you see stuff like 2D, Audio, and/or 3D in the pie chart, you can probably bet that it'll apply to both Code and Art. A month or two of education on the subject should fill out the specialization skill bar pretty quickly for any employee. I've noticed that I still get messages about X employee having no skill in some area while their character sheet definitely shows that they're qualified, but I think that's some buggery happening on some level.

Typically the 8 hour work day will fit most employees across the Lazy/Stress spectrum of personalities, though someone on the far end of Stress will probably be useless towards the end of the day. Personally, I keep it at 8 hours and end up adding a night shift at some point that comes in a couple hours afterwards. Some folks like to have 3 shifts so things are getting done all day. Having multiple shifts will get you around the team size limit and help you release software faster, but obviously it could double or triple your salary costs.

Vacations have gotten sort of weird now as well, at least while playing with more than 1 day per month, and the big thing with those is to make sure you don't get screwed out of a month of support or marketing active software while your employees disappear on vacation.

Hopefully some of that is helpful, good luck!